- From: David Booth <david@dbooth.org>
- Date: Tue, 06 Jan 2015 15:38:23 -0500
- 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