- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 12 Nov 2014 18:15:51 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Nov 12, 2014 at 2:50 PM, Mark Watson <watsonm@netflix.com> wrote: > Yes. If this is a big concern, then it would be a reason to consider the > video-specific option I outlined in my earlier mail. > > However, what is the concern with respect to passing the XHR bytes to > Javascript ? I think the concerns about mixed content, in general, are described well at http://www.w3.org/TR/mixed-content/#intro and http://www.w3.org/TR/mixed-content/#categories. > If this is a security concern, isn't this mitigated by the > requirement for the script to provide a hash of the response ? Presumably, > if the script has a hash of the response, then it could probably obtain the > actual response some other way (indeed, it could request it over HTTPS). So, > we're not giving any bytes to Javascript that it couldn't get anyway. We can very easily demonstrate this reasoning is faulty with a counterexample. Here is a SHA-256 hash of some content: a3d6b8110635bb9726fddaab6a638f13fc8bf68227f5de4763e25273571e354e. Please post the content that was hashed. We're trying to eventually disable all mixed content so that browsers' security indicators are simple enough to be truly meaningful to end-users. I think a lot of security and privacy engineers would admit that the actual security and privacy issues regarding HTTP vs HTTPS are more nuanced than all-or-nothing, but it seems like all-or-nothing is all we can expect end-users to understand, so that forces us into all-or-nothing approaches. Cheers, Brian
Received on Thursday, 13 November 2014 02:16:19 UTC