Re: About CTG, "Cache-control:" and <link>

Thanks for taking the time to comment on this list. In response to your 
conclusions, some observations:

 >     *4.- CONCLUSIONS
 > *
 >     User-agent header must remain intact for MWA and mobile Web services
 > when they are accessed using transcoders.

Understood. So far as MWA is concerned, they can additionally prevent 
alteration of request headers by adding Cache-Control: no-transform. But 
in any case CT proxies that conform to the guidelines should not offer 
altered headers ... see below.
 >
 >     Currently CTG does not offer any effective mechanism to protect MWA
 > and mobile Web services against user-agent spoofing/transformation,
 > because there is no way to identify a mobile web site BEFORE doing any
 > request to the application.

We say that the User Agent header should not be modified other than to 
avoid request unnacceptable responses (406 status and the like).

We also say that even when the request headers have been modified that 
the server must be able to reconstruct the original ones. Though that is 
not relevant to the use cases you describe, since we expect the original 
headers to be presented in those cases.

 >
 >     It is not intended to provide a solution in this document, but some
 > suggestions are evident: Not allowing user-agent header modification at
 > all, or offering a way to identify mobile web sites before any request
 > is done to the application, i.e.: Using exclusion protocols.

The idea of exclusion protocols is one that I am personally very 
interested in. I think there is good potential for work in that area. 
It's out of scope of the CT guidelines document, though not incompatible 
with it.

Jo

On 07/11/2008 16:22, Julio Rabadán González wrote:
>     My name is Julio Rabadán González, from Somms Multimedia Solutions SL.
>     E. Casais asked me to write my insights about proposed solutions in 
> CTG to avoid transformation of mobile sites, specially Mobile Web 
> Services and Applications. Here you have them.
> 
>     *1.- CONSIDERED CASES*
> 
>     In general, all mobile Web services based in mobile identification 
> are affected by transcoders. Mobile content delivery (games, 
> applications, QR-Codes, etc.), Mobile Web Applications (MWA) and many 
> other HTTP based services do not work properly, or at all, if they are 
> behind a transcoder.
> 
>     There are other mobile Web services affected, but I have no 
> experience with them.
>   
>     *1.1.- Content Delivery*
> 
>    Once a user has paid for a content, or has access to other service 
> not necessarily paid, he is sent to the "delivery service" to get the 
> content. Usually this delivery service is based on HTTP, a Web server 
> script that has some basic functions:
> 
>          - End-user identification.
>          - End-user's permissions verification
>          - Content selection or generation, adequate for the connecting 
> device.
>          - Content delivery in response.
> 
>     This is a basic 4 steps service, but usually more steps get involved.
> 
>     Note that there is no Web page in the response. The response is the 
> content.
> 
>   
>     *1.2.- Mobile Web Applications (MWA)*
> 
>     Like Desktop Web Applications, there are MWA. These applications 
> have a Web based GUI. Mobile Web Applications are not /defaced /Desktop 
> Web Applications so they fit in mobile devices, but applications 
> specially developed for them. A tool for remote monitoring and control 
> of industrial systems from mobile devices is an example, or mobile 
> database interfaces like Oracle MWAs.
> 
>     In MWA the response is adapted to device capabilities.
> 
>       You will have to follow at least these steps in your logic:
> 
>        - Identify connecting device
>        - Get input data from the user in the request.
>        - Do some business logic and obtain some response data
>        - Transform data to be sent to the device.
>        - Adapt GUI to be send to the device.
>        - Send the response
> 
> 
>     *2.- TRANSCODING EFFECTS*
> 
>     The main problem about transcoders is user-agent header spoofing. 
> All mobile Web services functionality depends on mobile device detection 
> in some way. Content delivery services can't be finished because 
> original user-agent headers are hidden or moved.
> 
>     *2.1 Real Example: Content Delivery*
> 
>     - A user has bought a Java game. When the user has finished the 
> buying process a WAP Push is sent to the mobile device, with a URL 
> pointing to the delivery system Web server, and some parameters to 
> identify the transaction.
>    
>             I.e.: 
> http://www.fooo.com/mobileDelivery/contentName.jad?Ticket=00000-00000-00000
> 
>     - Then the user activates the WAP Push, and his mobile Web browser 
> connects to the Web server.
> 
>     - Web server is Apache with PHP. It is configured with mod_rewrite 
> to rewrite the request to other one:
>            
>             I.e.: 
> http://www.fooo.com/mobileDelivery/send.php?Name=contentName.jad&Ticket=00000-00000-00000 
> <http://www.fooo.com/mobileDelivery/send.php?Name=contentName.jad&Ticket=00000-00000-00000>
> 
>     - "contentName.jad" is not a real file. It is only an alias to avoid 
> problem with some mobiles. In your server you have many versions of that 
> file, each one adapted to a specific device model. Before the Web 
> request, it is not possible to know the end-user mobile device model. 
> Then the Web script "send.php" identifies the mobile device, using the 
> user-agent header.
> 
>     - Once the mobile device is identified, the script reads the correct 
> file on the fly, and writes its content to the response output.
> 
>     - Inside downloaded contentName.jad (a Java descriptor file) there 
> is another URL, pointing to the real JAR file. This URL has the same 
> structure:
>          
>              
> http://www.fooo.com/mobileDelivery/contentName.jad?Ticket=00000-00000-00000
> 
>     - When the user accepts to install the application, the request is 
> done, the device is identified again, and the real JAR file is delivered.
> 
>     Without original user-agent header, pass 4 and 7 cannot be 
> completed. The user will get an error message, and get really angry.
> 
>     Another typical transcoder behaviour is double requests. Usually a 
> first request is done with one user-agent header, and then a second one 
> with another altered user-agent header. This will break not only 
> statistics, but billing systems.
> 
>     *2.2 Real Example: Application Delivery*
> 
>     I develop a widget for a company. To use this widget you need a 
> third party software tool. To install that tool you have to go to a 
> mobile Web page, and download it. My client was unable to install that 
> tool in his mobile, because he was behind a transcoder proxy, and the 
> delivery Web page was unable to identify his mobile.
> 
>     *2.3 Real Example: QR-Code Delivery
> *
>     This case is very similar to 2.1 but now other capabilities are 
> involved.
> 
>     QR-Codes are sent to mobiles using a delivery service, and then the 
> codes are read by another device directly from the mobile screen. For 
> this it is very important to know screen resolution and real size of the 
> mobile device screen, if not QR-Code may be unreadable. QR-Code are 
> generated on the fly by a Web server script, which is able to know what 
> mobile device is connecting using user-agent header only, and it decides 
> pixel resolution and other parameters of QR-Code (noise tolerance) based 
> on mobile device capabilities.
> 
>     *3.- ERRORS IN CTG PURPOSED SOLUTIONS
> *
>     CTG prohibit user-agent spoofing when accessing a mobile version, 
> but it doesn't offer a way to detect if a Web page is a mobile site or 
> not *BEFORE *sending a request to the site. <LINK> element and 
> "Control-cache:" headers are both at the server's response, where mobile 
> adapted content is supposed to go. This automatically discards 
> "Control-cache", because although the content is not going to be 
> transformed, user-agent has been broken yet.
> 
>     As it is seen in point 2, mobile Web services are not able to run 
> without the original user-agent header. Solutions offered by CTG are 
> adequate for mobile Web pages with no content adaptation, but not for 
> MWA or content delivery systems:
> 
>     For MWA there is no solution without modifying the application, 
> adding a fake home page with a <LINK> element pointing to the real 
> application. You will have the same problem again in following links 
> inside the MWA, and this will kill usability and development. In 
> addition it is not acceptable having to modify all MWA around the world 
> to add this trick.
> 
>     For Content Delivery services there is no solution because there is 
> only ONE request, and  it must be done with original user-agent header. 
> There is no place for <LINK> tags, nor previous requests.
> 
>     *4.- CONCLUSIONS
> *
>     User-agent header must remain intact for MWA and mobile Web services 
> when they are accessed using transcoders.
> 
>     Currently CTG does not offer any effective mechanism to protect MWA 
> and mobile Web services against user-agent spoofing/transformation, 
> because there is no way to identify a mobile web site BEFORE doing any 
> request to the application.
> 
>     It is not intended to provide a solution in this document, but some 
> suggestions are evident: Not allowing user-agent header modification at 
> all, or offering a way to identify mobile web sites before any request 
> is done to the application, i.e.: Using exclusion protocols.
> 
>    
> 
> -- 
> Julio Rabadán González
> * Somms.NET*

Received on Tuesday, 11 November 2008 08:00:35 UTC