- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Wed, 29 Oct 2014 11:28:53 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: David Dorwin <ddorwin@google.com>, Mark Watson <watsonm@netflix.com>, Domenic Denicola <domenic@domenicdenicola.com>, www-tag <www-tag@w3.org>
On Mon, Oct 27, 2014 at 4:45 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Oct 27, 2014 at 12:02 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote: >> The obvious question that is whether it would be feasible to do >> something that'd make XHR from https to http not blocked. For example, >> could streaming services deliver hashes of the video segments to the >> JS app over https and could https to http XHR be unblocked if the JS >> app told XHR the expected MIME type and hash and those matched what >> XHR actually received? > > Poking new holes in a system that's already fragile seems like a bad idea. It's worth noting that most of the fragility would come from preventing the application from obtaining information about the resource before the hash has been computed (successfully). This fragility already follows if the integrity policy "block" ends up being implemented for XHR per Subresource Integrity: http://w3c.github.io/webappsec/specs/subresourceintegrity/#xmlhttprequest-1 At this point, I'm not advocating anything--just exploring possibilities, but it seems to me that if this is rejected on fragility grounds (as opposed e.g. rejecting this due to there being too much collateral damage from https pages being able to waive confidentiality of XHR subsources), it seems to me that we should then reject the XHR part of Subresource Integrity in general. -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Wednesday, 29 October 2014 09:29:20 UTC