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.

ceo