The problem presented here is based on allowing trusted code in the UA to parse opaque media for rendering, but preventing parsed initiData from being passed in secure messages back to the JS app. Presumably this reflects a concern that if the data is not authentic, then the initData could be in some way malicious.
Has a mechanism been proposed that would block UAs from returning parsed data like this? In the EME spec, UAs are required now to treat initiData as untrusted. In this mixed content case with opaque data, are we extending this to mean that opaque initData parsed in trusted code must be kept opaque as far as the JS app is concerned? Do we agree that is necessary?
Jerry
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, April 20, 2015 5:36 AM
To: Henri Sivonen
Cc: Mark Watson; Anne van Kesteren; Martin Thomson; Aaron Colwell; Brad Hill; public-webappsec@w3.org; Matthew Wolenetz; WHATWG; Domenic Denicola; public-html-media@w3.org
Subject: Re: [whatwg] Fetch, MSE, and MIX
On Mon, Apr 20, 2015 at 4:41 AM, Henri Sivonen <hsivonen@hsivonen.fi<mailto: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.