29 Jan

The “WAP Gap” All Over Again – W3C, HTTPS and Transcoding

The other day Luca Passani sent me an email pointing me to a very important discussion that had been happening at the W3C Mobile Web Best Practices Working Group WG. The discussion is around Transcoding of web content and HTTPS -or- justifying breaking HTTPS in the name of transcoding.

That same week Dennis Bournique (WAP Review) wrote an excellent essay titled Transcoders and HTTPS where he describes the problem with this.

I’ve been wanting to write about this very, very important topic and today got the opportunity to write about this matter at ForumOxford; below is what I wrote:

I have been wanting to write about this for a while, but no time right now; my apologies.

I haven’t read the specs, but if the W3C is proposing to break HTTPS by introducing intermediary elements, such as a gateway, that is a major problem. And it is the WAP (Security) Gap all over again.

There are some basic principles, one being that HTTPS is secure end-to-end, that should remain always true, always. HTTPS is like an axiom — and building on top of HTTPS should always mean (it is accepted that it is) an end-to-end encrypted channel. If the W3C breaks that, it MUST NOT be called HTTPS.

It is Deja vu. And there will be proposed “solutions” such as operational safety of gateways to preclude unauthorized individuals from accessing the H/W, but that is not a true solution, and again, it is the WAP (Security) Gap all over again.

Either the folks proposing breaking HTTPS are a new generation and must be re-educated on WAP Gap and why it failed in favor of HTTPS, or they are just putting their business interests in favor of basic principles such as what is expected when HTTPS is discussed.

In addition to being respecful of “basic principles”, breaking HTTPS is a huge problem in practicality. Financial apps is one example — how can I guarantee to the end-users and banks that my mobile payment application is truely secure? Do I now have to implement my own encryption on top? And if somethig goes wrong due to the Gap, will the implementers of the broken gateways, and perhaps W3C will be responsible for this due to the irresponsibility/negligence, and are willing to take responsibility in courts?

It is disappointing to see this security gap coming up again. I thought that as a mobile/wireless community we had grown pass security gaps; but again, personal and/or business interests can always change the game.

So again, HTTPS should not be broken and thus HTTPS content shall not be transcodable. (Transcoding shall not take place anyhow, if the author of the content doesn’t wish it anyways; again, back to the importance of principles.) And if W3C continues pushing for the “transcoding of encrypted content”, it must not be done by breaking HTTPS and must not be called HTTPS, but by introducing a new thing, let’s call it WTLS 😉 and both protocols must be supported, and let the content owner decides which one to use.

Don’t break HTTPS.

Thanks to everyone who is creating awareness on this very important issue…

I would like to call the developer community to express their opinion on this matter…

Last but not least, The Transcoding Manifesto should be updated to include the above HTTPS concern, since as we can see, the end-to-end secure nature of HTTPS seems to be in jeopardy in mobile.


6 thoughts on “The “WAP Gap” All Over Again – W3C, HTTPS and Transcoding

  1. Pingback: McGuire’s Law » Blog Archive » Observations: Applications - January 30, 2009

  2. I was involved in the discussion also for copyright questions and transcoding and had some mail exchange with Luca Passani that he published without asking me (ok, I had expected that).
    I had a discussion back in 2000 with Johan Hjelm from Ericsson about location based services and privacy. I was arguing that only the user on the mobile should decide and Johan said, there is a trusted relationship between the mobile operator (think big telco) and the mobile user. So the mobile provider could do the expensive processing of policy languages. We went on discussing user interface issues..
    I’m sure you make the assumption that everybody has the latest smartphone with 1G RAM and a 3G connection. In this case, transcoding of HTTPS would not be understandable. But take GSM connections in less developed countries. Why should we cut the possibility to use secure transmission just until one step before the last link, knowing that GSM itself comes with encryption of the link. Renaming HTTPS or inventing a new protocol because the HTTPS link ends at a server that forwards content that was delivered to it via HTTPS does not convince me either.
    I do not say transcoding of HTTPS is right or wrong. I think we must have this debate and that we are far away from having touched on every aspect of it. Note that I do not actively follow the latest discussion in MWBP, so the aspect I’ve given may already have been used in the debate. If you have another aspect, I encourage you to contribute to the discussion. This will allow to achieve better results or decision on a broad information basis. Just saying it is wrong with some semantically overloaded end-to-end argument is not enough IMHO.

  3. Pingback: WirelessMoves

  4. @Rigo, no, I’m NOT making any assumption that everybody has the latest smartphone with 1G RAM and a 3G connection. Not at all. Simply breaking HTTPS is unacceptable, as it breaks the inherit definition and expectations which is a secure end-to-end connection. I’m not in favor of creating a new protocol (i.e. go back to WTLS), but W3C shall not break HTTPS and if they insist in introducing a security gap, no need to reinvent gaps and go back to WTLS, and let the content owner decide how his/her code is exposed/consumed.


  5. Hey, I was looking around for a while searching for https encryption and I happened upon this site and your post regarding The “WAP Gap” All Over Again – W3C, HTTPS and Transcoding, I will definitely this to my https encryption bookmarks!

  6. Hi there, I was looking around for a while searching for wireless security protocols and I happened upon this site and your post regarding The “WAP Gap” All Over Again – W3C, HTTPS and Transcoding, I will definitely this to my wireless security protocols bookmarks!

Comments are closed.