RE: Comments on the EME opinion

Hi Henri; thanks for your response. I hope you'll understand if I don't reply to every point, since the portions of the discussion that are meant to affect the working group directly have moved to the EME bug tracker. If you think the impact this spec review is having on the bugs filed is problematic, we can maybe move those conversations to the bugs. Hope that's OK; if I drop any threads you think are particularly relevant please let me know.

From: Henri Sivonen [mailto:hsivonen@hsivonen.fi] 

>> Out-of-band communication (via the CDM or otherwise) should not be 
>> possible
>
> Do you mean out-of-band communication with the key server or also out-of-band communication with an individualization server?

I must confess that the issues you brought up here are not at all what we had in mind. In particular individualization is not an area we looked in to very much. It seems that's encapsulated in a non-normative note about "an initialization or provisioning process"?

In any case, this wasn't the kind of out-of-band communication we were attempting to prohibit.

>> The ability of the CDM to potentially run arbitrary code is a hole in the web platform’s security model.

> Do you mean the CDM taking code via an EME message or a PSSH box and running the code? Which key system has a design like this? Or do you mean this becoming possible via unintentional vulnerabilities in the CDM?

The former is definitely one concern. The question is not necessarily "which key system has a design like this", but instead, "can I design a spec-complaint key system that does this?" This wouldn't necessarily be for nefarious purposes; e.g. it could simply be easier for a key system to implement certain functionality by sending executable code to the CDM in order to implement certain features. The issue is really that EME messages and license requests can contain *anything*, according to my understanding.

But in general, the concern is that, unlike open parts of the web, there is no way to inspect, validate/sanitize input to, and sandbox some implementations. This is required for robustness (from what I understand), but it is still a hole in the usual security model, to explain our original sentence.

>> To the extent that they cannot be, e.g. for robustness reasons, we should restrict access to those features such that they can only be used from secure origins, so as to make them less accessible to attackers.

> Surely, if your concern is the CDM executing code received via an EME message or a PSSH box, requiring the attacker to get a publicly trusted certificate and deploying https in order to access the code injection vector isn't much of a fix.

The simplest attack we are considering here is a HTTP page using such a code-executing CDM talking to a key server over HTTP. In that case an attacker could modify the EME messages sent to the page in order to execute arbitrary code. Whereas, if EME were only usable on secure origins, this would not be possible. In general, there are many network attacker (MitM) attacks that are addressed, including the ones you briefly mention where a message is structured to exploit a bug in an unsandboxed or privileged CDM.

Also, secure origins allow user permissions to be enforced even in the presence of a network attacker. When permissions are used, simply getting a certificate would be insufficient---the user would need to allow the origin. Maybe there should be recommendations regarding permissions, whitelisting, and/or informative messaging when identifiers or unsandboxed CDMs are used.

Finally there's the aspect that the TAG would prefer any privacy-sensitive features (of which EME is one, I believe) to be restricted to secure origins. Search for "RESOLUTION: We support..." in https://github.com/w3ctag/meetings/blob/gh-pages/2014/sept29-oct1/09-29-f2f-minutes.md.


>> and captioning systems.
>
> Besides indications of interest to use EME with MPEG-2 video streams that base U.S.-style closed captioning data into the "video" track in settop boxes for walled gardens, do you see indications of any general-purpose browser implementing support for restricting captions using EME-style DRM or any indications of a video service serving multi-ISP audiences (and not confined to the walled garden of a cable company) seeking to restrict captions using EME-style DRM?

Is it necessary for something bad to happen before we say in the spec that it's bad? That is a large purpose of the TAG review, and a them that comes up again and again in your questions. DRM on the web is a tricky subject and we are trying to give guidance and requirements for how not to fall down the many pits-of-failure that dot the landscape. Saying "there's no need to add accessibility concerns because nobody is doing anything inaccessible yet" doesn't seem appropriate.

As for the walled gardens, we'd rather see such walled-gardens be non-compliant than say nothing and accommodate them.

>> - Independent content providers should be able to use EME to protect their content just as easily as large media companies.
>
> If you don't like DRM (and it seems that you don't) you shouldn't want things that shift the cost of the system away from the source of the requirement and towards the entities closer to the user.

I think you are assuming that this is a zero-sum situation. The collection of bullets (in whatever order) seems like a good set of principles, and I'm surprised you disagree with them.

Is there another web API that effectively requires fees and agreements on one or both ends? Non-royalty-free codecs are the closest, and those have had the disturbing effect of segmentation.

>> - New browser vendors should be able to add EME support to their 
>> browser based on open standards, without needing to license 
>> technology. This should ideally be possible both for new desktop browsers and for new mobile browsers or new devices.
>
> This is a fine goal, but you should first get the services that want to use DRM to want to use an RF video codec, because robustness, in practice, means putting the video codec inside the robustness rule-governed realm, which means that e.g. in the case of dealing with H.264, the solution space is severely limited compared to the solution space in the non-DRM case. That's why I think it's harmful to try to solve these problems in the wrong order. You should solve the video codec royalty problem *first*. And I don't mean just by observing that RF codecs *exist* but by arranging circumstances that make the relevant services to want to use them.

This is a prime example of something that should probably be moved elsewhere, but since it's a very interesting topic, I can't resist: How would you recommend solving the codec problem? Browser vendors have a role here too, from what I understand, e.g. in supporting RF codecs with EME.

Received on Friday, 17 October 2014 21:09:12 UTC