The W3C is still grappling with the issues around content transformation. As I wrote back in August, the Mobile Web Best Practices Working Group (BPWG) within the W3C is in the process of formulating a set of Content Transformation Guidelines, defining how web to mobile transcoders should work. The discussions have been extremely heated. Virtually everyone developing mobile web sites just wants transcoders to leave their content alone. There's considerable distrust in the developer community about the the BPWG, which many feel is stacked in favor of transcoder vendors. It doesn't help that at least 11 of the 35 BPWG members are employed by companies that build transcoders or carriers that have deployed them. Many also question whether the CTG is even needed as a similar document, Rules for Responsible Reformatting: A Developer Manifesto (The Manifesto) already exists, has received wide support in the developer community and been adopted by four transcoder vendors. The Manifesto was created by a group of mobile web developers on the wmlprogramming mailing list run by WURFL creator Luca Passani.
The latest issue that the BPWG is tackling is how transcoders should handle HTTPS. The problem is that in order to reformat HTTPS content transcoders must decrypt it, breaking end-to-end security.
This is a huge issue and one that is central to the future of mobile services like online banking, shopping, and payments on mobile devices.
On the web, HTTPS is used to provide encrypted end to end connections between the user's browser and a bank, social network, web-mail service or payment processor's server. HTTPS is not limited to PC browsers. Direct mobile browsers like Safari, S60Webkit, Android Chrome, Netfront, Opera Mobile or even legacy WAP2 browsers like Openwave and Motorola MIB also support end to end HTTPS connections.
Transcoding proxies like OpenWeb, Infogin and Novarra have to decrypt HTTPS traffic in order to transform it and then re-encrypt it. The single end to end connection becomes two separate secure sessions with a gap in the middle where supposedly encrpted data is in plain text and could theoretically be compromised by someone with malicious intent.
The problem isn't limited to transcoders like OpenWeb and Novarra either. The increasingly popular server based browsers like Opera Mini, UCWeb, Skyfire, Bolt and Teashark must also decrypt secure data in order to process it.
The core question is whether the two parties in a secure data exchange (you and your bank, for example) are aware of this potential security risk and agree to allow it.
The draft CTG currently say this about HTTPS:
"If the response contains links whose URIs have the scheme https proxies may only rewrite them so that they can transform the content of linked resources, if the following provision is met. If a proxy does rewrite such links, it must advise the user of the security implications of doing so and must provide the option to avoid decryption and transformation of the resources the links refer to.
If a proxy re-writes HTTPS links, replacement links
Pages: 1 2 3
posted by Dennis Bournique
January 23, 2009 @ 1:44 pm
7 View Comments
