W3C home > Mailing lists > Public > public-bpwg@w3.org > January 2009

Re: ACTION-893: Start putting together a set of guidelines that could help address the security issues triggered by links rewriting.

From: Luca Passani <passani@eunet.no>
Date: Tue, 20 Jan 2009 23:54:33 +0100
Message-ID: <49765629.4030607@eunet.no>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC