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

Tom,
 
I find what you say below so hypocritical. I have offered solutions for
the scalability of whitelisting several times. And you guys have refuted
them under the argument that you are not allow to create any new
technology. In the mean time, it seems that you have an open remit to
destroy any existing technology with impunity: end2end security: ditch
it; content-owners copyrights: who cares, the list continues.
 
Someone before wrote here about PCI DSS compliance. Not a beep from you
guys. Our site is PCI DSS compliant and I am sure the lot of eBay,
Amazon and other must be too. Let's just wait till a PCI DSS audit
declares that one of those big sites looses its compliancy due to
allowing traffic being proxied by the Vodafone or some other network and
let's see what happens when the shit hits the fan. A couple of law suits
here and there by Google and Amazon should do the trick.
 
Jose Alberto
 
From: Tom Hume
 
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
<mailto:Tom.Hume@futureplatforms.com?Subject=Re%3A%20ACTION-893%3A%20Sta
rt%20putting%20together%20a%20set%20of%20guidelines%20that%20could%20%20
%20%20%20%20%20help%20address%20the%20security%20issues%20triggered%20by
%20links%20rewriting.&In-Reply-To=%253C83477947-4CE9-49BA-9A29-1AE488723
0FA%40futureplatforms.com%253E&References=%253C83477947-4CE9-49BA-9A29-1
AE4887230FA%40futureplatforms.com%253E> 
t:    +44 (0) 1273 819038
m: +44 (0) 7971 781422
company: www.futureplatforms.com
personal: tomhume.org