W3C home > Mailing lists > Public > www-tag@w3.org > October 2014

RE: Comments on the new EME opinion

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Fri, 3 Oct 2014 00:03:16 +0000
To: Mark Watson <watsonm@netflix.com>, www-tag <www-tag@w3.org>
Message-ID: <c5215157337f4657b4c3230db9dc4862@BN1PR05MB325.namprd05.prod.outlook.com>
Hi Mark,

Thanks for your comments. We had a chance to discuss them at the F2F meeting this week. Here are our thoughts:

From: Mark Watson [mailto:watsonm@netflix.com] 

> 1)
​> 
> "The ability of the CDM to potentially run arbitrary code is a hole in the web platform’s security model."
>
> I think this deserves some deeper consideration and explanation. In particular the term "arbitrary code" has several interpretations, some of which don't apply in this case. For example, in the case of an NPAPI plugin the User Agent allows code to be executed which is completely unknown to the  User Agent implementors or to the User Agent itself at run-time. This certainly qualifies as "arbitrary code". In the case of an EME CDM, however, the situation can be very different (and perhaps could be required by the specification to be different).

We agree with you that UAs already contain proprietary code. However, that code is generally specified, not arbitrary, at least for web platform features. From a user's perspective, the arbitrary code of a CDM is just as arbitrary as the code of a Flash plugin. It isn't really feasible to say that Microsoft/Google/Apple code is not arbitrary, but Adobe code is.

Additionally, we are concerned about the way in which both video frames and license response channels could be used to send code over the internet into the CDM to execute. Since the CDM is not specified, this is entirely within the realm of a conforming implementation as it stands.

> 2) "As part of interoperability, EME should not provide APIs that are designed to allow restriction of content to one platform and/or key system."
>
> Is this just ​a recommendation for the​ future, or do you have a concern that the specification already provides such APIs ? If so, which ?

This is meant as a recommendation for the future :)

> 3) "While certain key systems may only be supported on certain platforms, and certain content may only be available with certain key systems, ...​"
> 
> Unfortunately, it is also possible, as a feature of the ecosystem, 

Yeah, as we said, it is a sad-but-true feature of the ecosystem. Similar to the sad-but-true fact that certain content is no longer available on Windows XP SP2 because servers have upgraded to SHA-2 certificates.

> 4) "We understand that designing a DRM system for the web brings along robustness requirements that are unlike those of most web APIs, and cause a tension with the usual way specifications are developed openly. EME has chosen to address this via the idea of a CDM, which encapsulates unspecified behavior necessary for robustness"
>
> Robustness is not the only factor that leads to the idea of a CDM. IPR is also an issue, both in the realm of robustness and other functionality.

We plan to remove the words "for robustness" based on this feedback. Thanks!

Received on Friday, 3 October 2014 00:03:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:06 UTC