- From: Luca Passani <passani@eunet.no>
- Date: Tue, 20 Jan 2009 23:54:33 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
your scenario is already covered by CTG. A developer in your situation can look at the Via header and, if a transcoder is recognized, they can serve a plain HTTP form AND make sure that the submitted data also comes from the transcoder. Problem solved. wrt Whitelist, this is a problem for transcoder vendors to solve. They may decide to create a common sire where companies can authorize all transcoders to break their HTTPS logins in one fell swoop. Anyway, the fact that one content provider approves that one transcoder breaks HTTPS on its site, does not mean that the same content provider is OK with all transcoders breaking HTTPS on its site. Luca Tom Hume wrote: > > I've built sites myself that fit that criteria. For instance - an > iTunes-style music store for a startup I worked for in 99. HTTPS for > login, just to protect the password, but beyond that no need for > HTTPS. No credit cards stored or anything like that. > > In that case, as a content provider I'd be happy for mobile users to > be able to access their MP3s through a transcoded version of the > service... and would be happy to have security slightly degraded. > > I'm not suggesting that this is a general case, or that the lack of a > requirement for absolute security in cases like this outweighs the > need for security in some cases where important information is being > saved, btw. I think you can make a good case that it's best to err on > the side of caution wrt security issues. But cases like this exist. > > But anyway... I was asking about whitelisting, and my question was: > how can we make this work? > > On 20 Jan 2009, at 22:39, passani@eunet.no wrote: > >> >>> How would it work from a content providers perspective? Would they >>> need to register their service individually, or would some sort of >>> aggregated whitelist make sense? I've wondered about such things >>> before [1]... >> >> I never heard of a content provider or developer who, one fine morning, >> realised that, while they wanted to keep HTTPS-only login to their >> website, at the same time they also wanted a mobile site, they were >> not OK >> with building their own, but they liked the idea that someone would >> do it >> for them through transcoding, all of this without even having to care to >> authorize transcoders to by-pass the HTTPS security they peviously >> implemented. >> >> In short, you are on pretty thin ice here trying to find legitimate >> scenarios to break HTTPS for your transcoding friends. >> >> Luca >> >> >> > > -- > Future Platforms Ltd > e: Tom.Hume@futureplatforms.com > t: +44 (0) 1273 819038 > m: +44 (0) 7971 781422 > company: www.futureplatforms.com > personal: tomhume.org > > > > >
Received on Tuesday, 20 January 2009 22:55:12 UTC