Re: Comments on the new EME opinion

On Thu, Oct 2, 2014 at 5:03 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

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

​I'm not sure I follow this. I don't think that the average user of a
proprietary browser knows ​or cares that it is conformant to some W3C
specifications and thus does not contain non-specified ("arbitrary" in your
use of the word) functionality. It's not clear that conformance to the
specifications - as demonstrated by testing - is evidence that additional
functionality is not hidden there. Users trust that no malicious code
exists because they trust the representations of the browser vendor, not
because it passed some conformance tests. Whether that trust is well-placed
or not, there's no distinction between proprietary UA code and CDM code
from the same vendor in this respect. I think the use of the word
"arbitrary" to mean "not constrained by any standard" is at least unusual
and so should be better explained.

​In the case of Firefox, there's clearly a difference between a plugin that
is unknown and unverified by the UA and one that is known and verified,
even if the code is proprietary.​


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

​First, this is presumably not an EME-specific concern for proprietary
browsers, which could include such a backdoor anywhere in their code if
they so chose (and in such a way that all web platform conformance tests
still passed).

And it seems other browsers could suffer the same problem to the extent
that they access any proprietary (browser or platform) capability without
fully sanitizing the data on the way in. Using a platform's video decoder,
without decoding the bitstream yourself first to check it is valid, would
seem to be just as dangerous as using a CDM. An even then, even if you
check that a video decoder or OpenGL shader or whatever is valid, I don't
believe that proves it does not contain some hidden code to be executed by
a backdoor interpreter in the video decoder or OpenGL implementation:
steganography is a well-developed art.

Would it mitigate the concern if we required UAs to validate messages to
the CDM to the extent possible ? These messages are expected to be small,
so at least length checks would seem to preclude quite a lot already. The
CDM implementor might be able to suggest a host of other checks that the UA
could do, especially if CDM implementor and UA implementor are one and the
same, which is the case for the majority of UAs.

One mechanism which could be of value here is that service providers (such
as ourselves) greatly dislike user permissions prompts getting between
users and our service. This is one of the major reasons for migrating from
plugins. If UA and CDM implementors could together achieve a situation
where they were both convinced there was no incremental security or privacy
risk to users from the use of a CDM, a prompt would be unnecessary. I think
we should strive for this outcome.


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

​Ok, good. I'm not really sure what such an API would look like, though, so
that I can look out for it in future. Did you have something in mind ?​



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

​I was suggested that you point out these other "sad-but-true" features​ of
the ecosystem, not just one of them.


>
> > 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!
>
>
​Thanks.

...Mark​