W3C home > Mailing lists > Public > www-tag@w3.org > January 2015

Re: Draft finding - "Transitioning the Web to HTTPS"

From: David Booth <david@dbooth.org>
Date: Tue, 06 Jan 2015 15:38:23 -0500
Message-ID: <54AC47BF.3000601@dbooth.org>
To: www-tag@w3.org
On 01/06/2015 03:16 PM, Mark Nottingham wrote:
>
>> On 5 Jan 2015, at 12:52 pm, Martin Thomson
>> <martin.thomson@gmail.com> wrote:
>>
>> On 5 January 2015 at 03:04, Tim Berners-Lee <timbl@w3.org> wrote:
>>> If the videos are all https: then he won't be able to cache them,
>>> except -- not to worry, the tools he buys will probably include
>>> MITM attack tools, so in fact he *will* be able to cache things
>>> after all.
>>
>> I think that it's a little sad that this is the only response we
>> have to this situation.  Of course we can break the encryption.  It
>> does instantly restore function to our existing toolchain.
>>
>> Or, we could apply ourselves to the problem and then maybe we can
>> have both security AND caching.
>>
>> Jus' sayin’.
>
> We were just talking about this at lunch. SRI is the most obvious
> candidate we have now.

http://www.w3.org/TR/SRI/
so that others don't have to search for that link as I did.

>
> My understanding is that there is *some* browser vendor interest in
> this direction, but they want to get more deployment experience with
> the more basic use cases for SRI first.
>
> The main problem I see is that SRI (or any other solution with
> reasonable security and caching properties) is effectively opt-in
> from the origin, and the takeup rates of HTTP caching for video
> (pre-HTTPS conversion) are already dismally low, AIUI. That doesn’t
> bode well — but maybe having end-to-end integrity would improve
> things.
>
> Cheers,
>
> -- Mark Nottingham   http://www.mnot.net/

David Booth
Received on Tuesday, 6 January 2015 20:38:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:09 UTC