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

Re: [whatwg] Fetch, MSE, and MIX

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 20 Apr 2015 05:36:14 -0700
Message-ID: <CACvaWvaGLf1+71p9EG_KoKJMdUNbbX7PgFcnQ7MRizEvHcY0kw@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
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 Mon, Apr 20, 2015 at 4:41 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> AFAICT, this leaves the following options:
>  * Reducing the proposal to cover only non-DRM cases.

Hopefully obviously, this is NOT what is being proposed.

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

Correct. This is one way to solve it.

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

Correct. This is another way to solve it.

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

This is another way to solve it, but not one proposed.

> 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?

None of these are being explicitly proposed - that is, there's no inherent
reason to require one or the other. This doesn't obviate the need for some
changes to serving infrastructure in the cases of EME, but significantly
reduces the complexity from (serve all media content over HTTPS) to (serve
init data over HTTPS), the latter being an order of magnitude less complex
than the former for the vast majority of existing content.
Received on Monday, 20 April 2015 12:36:42 UTC

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