W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [SRI] Escaping mixed-content blocking for video distribution

From: Brian Smith <brian@briansmith.org>
Date: Wed, 12 Nov 2014 18:15:51 -0800
Message-ID: <CAFewVt6jLGMtRb6ZiwEd1yqk-u-28BCcmM=BKVQ8Ov-FO6FFyg@mail.gmail.com>
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

>  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:
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.

Received on Thursday, 13 November 2014 02:16:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC