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