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: Tom Hume <Tom.Hume@futureplatforms.com>
Date: Tue, 20 Jan 2009 23:33:43 +0000
Message-Id: <07F0FE8D-F87C-4FB6-89F3-20630EF52D76@futureplatforms.com>
To: MWI BPWG Public <public-bpwg@w3.org>

Sorry, have I explained myself poorly again?

I just gave you an example of a case where degrading HTTPS would be OK  
from the content providers POV. I can *guarantee* you it exists - I  
was that content provider. If there's one, there's probably others.  
And I'm not saying this means it's OK to routinely degrade security...

On 20 Jan 2009, at 23:28, Luca Passani wrote:

> No. Those cases do not exist.
> I don't think that solving a problem that still does not exist and  
> probably never will deserves any of my time.
> What keeps me here is just checking that W3C does not demolish the  
> foundations of the web.
> Luca
> Tom Hume wrote:
>> On 20 Jan 2009, at 22:54, Luca Passani wrote:
>>> 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.
>> Is there nothing we can do about this, particularly if it's in the  
>> interest of content providers?
>>> 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.
>> I completely agree; in fact I think I pointed that out :) But it  
>> does mean that such cases exist.

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 23:34:20 UTC

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