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

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

From: Mike West <mkwst@google.com>
Date: Thu, 13 Nov 2014 10:50:40 +0100
Message-ID: <CAKXHy=dtd=qtbJzZ8Wx3xadBET1n3-PWrELGTp+ea-CKD12mJA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>, David Dorwin <ddorwin@google.com>
Cc: Brian Smith <brian@briansmith.org>, Mark Watson <watsonm@netflix.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Nov 13, 2014 at 10:45 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Wed, Nov 12, 2014 at 11:39 PM, Brian Smith <brian@briansmith.org>
> wrote:
> > AFAICT. In order for browsers to be able to appropriately scope the
> > allowance for mixed content that you are asking for, a purely
> > declarative mechanism for MSE would be needed.
>
> While we are being speculative, we could offer
>
>   xhr.responseType = "mse"
>   xhr.onload = function() {
>     video.feedBytes(xhr.response) // prolly has other name than feedBytes
>   }
>
> with xhr.response being an opaque object that only the browser can read
> from.
>
> However, it seems rather weird to offer such a thing just because
> Netflix can't TLS like YouTube can.
>

But if offering such a thing lead to Netflix and other media providers
migrating everything but video distribution over to HTTPS, and allows us to
lock down APIs with dangerous characteristics (like EME and WebCrypto) to a
document whose ancestor chain is all HTTPS, then it's probably worth
considering, at least in the short run.

+ddorwin

-mike
Received on Thursday, 13 November 2014 09:51:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC