- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 Jan 2015 15:16:45 -0500
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Tim Berners-Lee <timbl@w3.org>, Henri Sivonen <hsivonen@hsivonen.fi>, Public TAG List <www-tag@w3.org>
> 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. 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/
Received on Tuesday, 6 January 2015 20:17:10 UTC