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 14:21:57 +0100
Message-ID: <4975CFF5.9090109@eunet.no>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>

Tom Hume wrote:
> 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? 

it scales. Don't listen to Opera. I have been involved with similar 
projects in the past. The top 50 to 100 sites will cover over 50% of the 
traffic. Of course, whitelisting has extra cost for transcoders. But 
this is only fair.

> Should content providers be getting their services whitelisted with 
> every transcoder deployment? How would this be managed?
Let's not forget that content providers are the ones who chose to 
establish HTTPS to start with. They have the option of also allowing 
HTTP login, only allow HTTP login, allow HTTP login from everything 
identified as transcoder ("via" header, for example) or, as I was 
suggesting, by getting whitelisted.

All very simple and straighforward.

>> 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.

why would anyone who uses HTTPS would use no-transform when HTTPS is 
supposed to be point-to-point?

> 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. 
possibly, but it does not mean that they are opting in to transcoding 

Received on Tuesday, 20 January 2009 13:22:37 UTC

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