RE: Comments on the new EME opinion

Hi Mark,

I wanted to give a quick reply saying thank you for your comments. I agree with most of them for sure. We’ve all been gearing up for our F2F meeting this upcoming week, at which point we’ll be able to better address them and give you a proper reply, but I wanted to let you know they didn’t fall on deaf ears in the meantime :)

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, September 25, 2014 11:14
To: www-tag
Subject: Comments on the new EME opinion

H
​i​
TAG,

I read the latest EME opinion that Domenic referred to in the discussion on secure origins for EME.

I see that many of the earlier comments I made have been addressed, thank you.

I have a
​few
 of further comments and a question
​ below. Will this topic be discussed at the F2F at TPAC ?​


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

Specifically, for known EME implementations:
- For IE and Safari, the CDM code is no different in status from the rest of the UA: Microsoft or Apple proprietary.
​ So this is not really "arbitrary code" in any sense.​

- For Chrome, the CDM code is no different in status from other parts of Chrome that are not in Chromium: Google proprietary.
- For Firefox, the CDM code
​ ​
will be
​ ​
verified at runtime by the UA to be a known Adobe proprietary component. The implementors of Firefox have a direct relationship with Adobe through which they can obtain detailed knowledge of the CDM functionality
​. ​
It is also sandboxed.
​ Since the Firefox implementors can't see the code, they might consider it to share some of the properties of "arbitrary code", but the UA does at least verify it: it's a specific piece of code, not an arbitrary piece of code.​


In the Firefox and Chrome case, the CDM code is certainly different in nature from the majority of the UA implementation
​ and this does raise security issues which have led both of those browsers to sandbox the CDM.​ B
ut it is also quite different in nature from what is usually meant by "arbitrary code".
​ One of the major benefits of EME is that we no longer have to ask our users to install "arbitrary code" of the unknown and unverified kind.​


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 ?

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,
- that a given key system has different levels of robustness on different platforms
- that there is inconsistency in the evaluation of the robustness of a given key system / platform combination between content providers

​So, two content providers may ask for the "same" level of robustness yet still find that the sets of key system / platform combinations they each can support ​is not the same. This is also assuming that you have some way to evaluate equality of robustness requirements across content providers.

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.

...Mark