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

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:47:53 UTC