Re: Comments on w3ctag/eme/

On Sat, Feb 22, 2014 at 4:49 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
> OK, sorry this offended you. I’ve replaced with a direct quote from the EME spec and the HTML charter, and a characterisation that I think addresses your concern.

Thank you.

> OK, obviously a bad choice of wording on my part. I’ve switched to calling DRM DRM.

Thank you.

> OK. The goal of this section is to try to outline what a truly platform-independent mechanism for playing protected content might look like. I’d really appreciate your help to improve it. I’ve added some wording about it being possible to get hold of the keys in an open way as well

Getting hold of the keys in an open way would be contrary to the goals
of DRM. Making a DRM scheme platform-independent and open to the point
that anyone can interoperably implement it without permission (as one
might expect from a normal Web standard) means that a user could
implement the scheme and acquire the keys (since "user" is part of the
set "anyone"). This would mean giving the keys to the adversary. So
the keys can't be acquired in an open way. (Assuming that "open"
extends all the way to stuff actually working. Extending "open" only
to protocol definition isn't enough to achieve platform-independence,
as noted earlier. For example, if the key acquisition protocol is that
the CDM sends the CENC key id in an OpenPGP-signed message and the
server sends the key back in an OpenPGP-encrypted message but only if
the CDM's OpenPGP key has been signed by a particular third party,
OpenPGP being open doesn't help much if the third party always refuses
to sign keys belonging to CDMs on some platforms.)

When software implemented by anyone can't be what acquires the keys,
the next best solution for achieving platform independence seems to be
defining a virtual machine that can be implemented by anyone as a
white-box environment for executing a program that's so obscure that
it's effectively a black box, so that the providers of such obscure
programs would only need to target the virtual-machine platform
instead of having to target every non-virtual platform. In the context
of the Web Platform, a Web Worker executing JavaScript is the natural
answer for an execution environment. As noted earlier, even if the Web
Platform provided API surface for implementing Worker-based CDMs
(encrypted video elementary stream data and EME messages in, EME
messages and pixel buffers out), JS-based CDMs would face some
challenges relative to the sort of CDMs that EME now assumes and that
have been shipped.

> The changes that I’m suggesting to address the points above are in a pull request at:
>
>   https://github.com/w3ctag/eme/pull/1
>
> so that they can be discussed more easily.

I commented a bit more on a couple of the changesets in the pull request.

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Wednesday, 26 February 2014 13:55:50 UTC