W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: [whatwg] Fetch, MSE, and MIX

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Mon, 20 Apr 2015 14:41:28 +0300
Message-ID: <CAJQvAufWazKjowQAjQf_TkA_VWOx0cM7yM8K5r7zu8KKib_PEQ@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Mark Watson <watsonm@netflix.com>, Anne van Kesteren <annevk@annevk.nl>, Martin Thomson <martin.thomson@gmail.com>, Aaron Colwell <acolwell@google.com>, Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Matthew Wolenetz <wolenetz@google.com>, WHATWG <whatwg@whatwg.org>, Domenic Denicola <d@domenic.me>, "public-html-media@w3.org" <public-html-media@w3.org>
On Thu, Apr 16, 2015 at 7:57 PM, Ryan Sleevi <sleevi@google.com> wrote:
> We think this is still an important issue that needs solving if we're to
> offer a viable migration path from existing plugin-based solutions
> I think as we look to
> provide a compelling story for EME over wholly-proprietary (... rather than
> partially-proprietary) solutions, or look to improve the user experience in
> streaming video with MSE vs the <video> tag, this is still very much needed.

Enabling mixed-content MSE in order to speed up migration from non-DRM
NPAPI-based adaptive streaming video and enabling mixed-content MSE in
order to speed up migration from DRM-based DRM have different
requirements on a level that's worth making explicit:

In the non-DRM case, it's sufficient to have a wholly opaque stream of
data going into MSE and nothing but duration data leaking out.

In the DRM case, however, the design of EME involves the browser
extracting the init data, surfacing it to the JS app via EME and the
JS app pushing it to the CDM via EME. If the app and the MSE data are
different-origin and CORS doesn't permit the MSE data to be exposed to
the origin of the app, EME says to block the exposure of init data
from the MSE data to the app via EME. Since we don't allow (and don't
want to allow) cross-scheme CORS, you can't just use CORS to allow
init data to be exposed to the JS app in the mixed-content case.

AFAICT, this leaves the following options:

 * Reducing the proposal to cover only non-DRM cases.

 * Requiring DRM-using services to transport init data in a way that
doesn't involve the browser extracting it from a media container
supplied to the browser via MSE. That is, the app would push the
separately-delivered init data to EME proactively so that EME doesn't
go through the algorithm that causes failure in the case of
different-origin init data.

 * Requiring DRM-using services to transport init data in a media
container over https and use it via MSE and then have MSE make a
one-way transition from non-opaque to opaque when the first opaque
segment is pushed to it. This would, AFAICT, preclude middle-of-stream
key rotation by pushing more init data to MSE, since MSE performed a
one-way transition to opaqueness.

 * Requiring DRM-using services to transport init data in media
containers over https and requiring MSE to track which segments are
opaque and which not and block init data surfacing to the app only
from opaque segments.

The last option is, obviously, the most complex for a browser to
implement correctly and securely but would impose the fewest
constraints on the Web site.

Which of the above options are being proposed? Or have I missed some
possibilities and something that I didn't list is being proposed?

Henri Sivonen
Received on Monday, 20 April 2015 11:41:53 UTC

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