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

On 20 Jan 2009, at 11:59, Luca Passani wrote:

> Absolutely false. This solution is totally viable. Don't take  
> Opera's word for it: Just track the top 200 sites which require  
> HTTPS login in your system (which covers 95%+ of the traffic),  
> contact the site owner to get approval and off you go. Very viable.  
> Also create a process by which  content owners can add their sites  
> to the whitelist (of course, they'll need to prove who they are).

Luca

Personally I'm in two minds about whitelists - on the one hand they  
push some responsibility onto transcoder deployments, which is a good  
thing IMHO - but on the other, how does a solution like this scale?  
Should content providers be getting their services whitelisted with  
every transcoder deployment? How would this be managed?

> Let me ask you a question. I am a content provider. I don't want my  
> content to be transcoded so I decide to use HTTPS. What am I doing  
> wrong? why isn't this protecting me from transcoders?

/me lights the blue touchpaper

The way to stop transcoding is to use no-transform. It's imperfect in  
that it stops *all* transformation, true, but it's The Way.

Personally I would say that a CP using HTTPS has stated they wish to  
have their service accessed securely, but not that they're opting out  
of transcoding by doing this. The two are different (though there may  
be overlap in that end-to-end secure services can't be transcoded).

> Personally, I would be OK with this idea. Staying silent would mean  
> that transcoder can keep doing it, but they would be unable to quote  
> W3C in defense of what many will perceive as an abuse.

> > 3. acknowledge that it is being done and start from there to try  
> to find ways to
> > limit the impact, and maximize security. This could be more useful  
> to raise awareness
> > on the dangers of playing with secure content.
> just a big mess. Far from bringing order, it would give an excuse to  
> transcoders and others to do whatever they want with HTTPS. And it  
> would also cover W3C with ridicule as a side effect.


I'd like to see some more normative guidance from transcoder vendors  
and/or operators on how this can be done securely...


--
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 12:58:17 UTC