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.3.1 : Tuesday, 6 January 2015 20:42:59 UTC