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 must have the scheme https.
Note: For clarity it is emphasized that it is not possible for a transforming proxy to transform content accessed via an HTTPS link without breaking end to end security."
That statement does require the end user to be notified, but not the other party to the transaction - the operator of the site that mandated the use of HTTPS in the first place. There have been some critical public comments on the CTG mailing list that seemed to have prompted the BPWG to revisit the topic. In the latest round of public comments at least three approaches have been proposed:
1. Develop additional rules around how and when transcoders should be allowed to intercept HTTPS traffic. For example, only allowing transcoding of sites that have specifically granted permission for transcoders to alter their encrypted data.
2. Prohibit transcoding of HTTPS data streams altogether.
3. Removing all mention of HTTPS from the CTG on the grounds the topic is out of scope and/or too contentious to reach agreement on. This is the approach the Manifesto currently takes, although Luca has made it clear that he believes that transcoders should not touch HTTPS traffic without explicit permission from content providers.
Personally I think that the CTG appears too concerned with the needs of transcoder vendors and not enough with those of end users and content providers. Breaking end to end security is a big deal and should only be permitted with the explicit approval of both parties to the transaction. I feel that the W3c should be soliciting input from the financial industry, especially banks and payment processors. Security of transcoders and server based browsers is not only a technical problem, it's also social and business problem.
I wonder if there is a financial industry group willing to take on responsibility for auditing the security practices of transcoder and server based browser vendors. Such a group could approve browsers and transcoders and manage a central white-list where content providers could list the URLs of services that they authorize the approved services to transcode.
User permission is also necessary. I'd like to see a warning and prompt presented to the user when they first access an HTTPS site using a transcoder or server based browser. The wording needs to be clear, something like "Do you allow <Name of Proxy> to decrypt the information on <URL> in order to reformat it for you phone? The user should be able to grant blanket or one shot permission.
I trust the major transcoder and server based browser vendors like Opera, InfoGin, Skyfire, Openwave, Bitstream and Novarra. I believe that they are serious about security. However without the buy-in of users and especially financial service providers they are at risk of having their access to these services blocked. It is actually in the best interests of transcoder and browser vendors to be audited by and receive the approval from the secure sites that they are transforming. Doing this on a site by site basis is obviously not scalable but a centralized clearing house could be.
The BPWG is accepting public comments on this topic. If you have an opinion now is the time to be heard. There have been lots of comments from mobile developers and BPWG members but only a couple from anyone whose main interest is online security. It would be great to see more people with experience in online banking or payment processing weigh in on this issue. To be most effective comments should be made on the main topic thread by replying to the message: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.
Update: See Tom Godber's post on this issue. Tom works in the mobile security field and his post explains how https works in a clear and non-technical way and includes an example of how a thief could exploit a transcoded "secure" connection.