- From: Julio Rabadán González <somms@somms.net>
- Date: Fri, 07 Nov 2008 17:22:03 +0100
- To: public-bpwg-comments@w3.org
- Message-ID: <49146B2B.2090502@somms.net>
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 Friday, 7 November 2008 16:52:44 UTC