Re: Encrypted Media proposal: Summary of the discussion so far

On Sat, Mar 3, 2012 at 5:54 PM, Christian Kaiser <kaiserc@google.com> wrote:
> Here's an attempt to summarize some of the insights from the great
> discussion over the last few days - the sheer volume of messages is making
> it hard to follow every thread.
> I will not cover the more "philosophical" parts of the discussion except in
> the "summary of the summary" at the end.
>
>
> The Fundamentals
>
> The Encrypted Media proposal seeks to establish a standardized way to expose
> the functionality of a CDM into HTML, and therefore enable playback of
> encrypted content in HTML.
>
> It does *not* impose or specify how any aspect of the CDM shall work except
> for two things:
> - it decrypts media content in a way that's standardized by the container
> format of the media to be played.
> - it can establish the key required to do the decryption above through
> otherwise unspecified and opaque messages that are passed through
>
> As seen by a client side JS application, all CDMs work the same way. All
> that is protection-system specific are the (potentially opaque) messages
> passed to and from the CDM to deliver the key that is required to decrypt
> the media format to be played.

Given that CDMs are a necessary portion of the proposal, and that
reverse-engineering common existing DRM schemes is illegal under US
law and some other countries, the fact that this does not specify CDMs
in detail is a *weakness* of the proposal, not a strength.


> In fact, many different types of CDMs *can* be used in this proposal:
> - Clear Key, where the key is delivered through a simple URL, in the clear.
> This mechanism is simple, fully specified and can be implemented in open
> source. It may not satisfy the robustness requirements of all types of
> content business transactions, but it is useful in many cases today.
> - likely a number of existing commercial content protection schemes. These
> mechanisms can likely not be fully implemented in open source for a variety
> of reasons. It is these mechanisms (or some particular ways in which these
> have been used in the past) that seem to be controversial.
> - mechanisms that do not yet exist or which are not known to this group.

I doubt ClearKey satisfies the contractual relationships that the
intended users of this spec are currently bound to.  If it did, we
could simply require it; it's more-or-less similar to WOFF packaging
of a font.  A WOFF font is essentially a TrueType font with an extra
header prepended to it (there can be additional changes made, but
they're optional).  One of the primary motivations for this was to
provide a trivial hurdle between people downloading a font from the
web and using it in their system.  This was enough to satisfy the font
foundries who wanted to "protect" their fonts, and it was sufficiently
easy to work around that it was acceptable to those of us who abhor
DRM on general principles.

It seems clear that, in practice, it's the "existing commercial
content protection schemes" that are the target of this, at least in
the short term.  They are indeed controversial.


> The proposal does *not* prescribe which, if any, of these CDMs a browser
> vendor can or shall implement. A browser vendor can choose to implement no
> CDM, and thus not support Encrypted Media playback.
> It does, however, specify a CDM that presumably any browser vendor can
> implement (Clear Key). Therefore, a baseline is established that makes the
> proposal useful whether or not any other CDMs will be supported by anyone in
> practice.
> A browser vendor can choose to implement additional CDMs, or, if desired,
> even a plugin mechanism for CDMs. Browser vendors can, but do not have to
> agree on a common plugin mechanism for CDMs if they find that useful. Such a
> plugin mechanism's scope will be much smaller than e.g. NPAPI.

As noted, it doesn't appear that any of the primary targets for this
proposal will actually use ClearKey to deliver their content.  It's an
attempt to make the DRM seem palatable by presenting a toothless
version and then waving away any concerns about the fiercer cousins
with "yeah, but you interact with them the same way".  There doesn't
appear to be any reason for a browser to actually implement ClearKey.


> Robustness and Commercial CDMs
>
> The discussion reveals that there's an attribute of CDMs that is
> intentionally not covered in the proposal, but that is important to the
> CDM's applicability for some transactions. Let's call it "robustness" - the
> degree of difficulty with which clear content can be extracted from the
> system. As a rule of thumb, a more robust implementation will be entrusted
> with higher value content by content owners than a less robust one, since
> there is an assumption that the risk of compromise is lower.
> The actual robustness of CDMs depend on their implementation on a particular
> platform/OS, and some of the implementations with highest robustness take
> advantages of platform-specific or even hardware-specific features.
> All CDMs have an inherent limit of robustness. With some the limit is lower
> (e.g. Clear Key), with some it is higher. There is no CDM that can be
> infinitely robust.
> The proposal does not limit or otherwise affect robustness of CDM
> implementations.
>
> It seems that *today*, in order to enable playback of many types of premium
> content, a CDM that implements a commercial content protection system is
> required, since *today* only these can reach the required levels of
> robustness, and therefore the necessary level of trust.

Your emphasis seems to suggest that, in the future, content producers
won't require their DRM to be as inconvenient for users.  While I laud
this goal, what evidence do you have for the implication?  I believe
the historical trends point to distributors coming up with ever more
elaborate ways to inconvenience their customers in the quest for
"robustness".


> There is currently no common understanding how the deployment of such
> commercial CDMs might work for browsers since they likely cannot be
> implemented in open source, and may need be implemented in a
> platform-dependent way. A plugin mechanism (see above) appears to be one
> viable solution, since such a mechanism seems to solve a superset of
> problems for proprietary frameworks that include content protection today.
> It is unclear who would pay for licensing CDMs, their robust implementation
> and their distribution to users. There seem to be a number of options:
> - browser vendor
> - content distributor
> - OS/platform vendor
> - others?
> Members would like more clarity in this area to better understand the
> consequences of the proposal on the browser market.

As noted multiple times in the thread, the fact that *someone* has to
pay for licensing the CDMs in use is incompatible with the W3C's goals
of producing royalty-free specifications for the web.

Many other of the attributes you list are also negatives for the open
web.  All the browser vendors have been burned by including or even
just interoperating with closed-source code before, because they're
unable to fix security bugs in said code.  Platform-dependence is a
negative for any technology, but it's *particularly* bad for CDMs,
since reverse-engineering a DRM system (to implement it on your OS) is
illegal in the US and other countries.

A plugin system for CDMs offers no improvement over the current state
of affairs, where plugins (Flash or Silverlight, generally) are
commonly used to play video.


> Other "Side Effects"
>
> The proposal limits the scope of the content protection system to just key
> delivery and decryption. CDMs are discoverable, interchangeable and
> orthogonal to the media format.
>
> It therefore limits or prevents some platform lock-in strategies, e.g. where
> the content protection system is tied to a proprietary UI framework or
> proprietary media formats.

CDMs are not interchangeable in the sense required for this paragraph
to make sense.  If a distributor encrypts their videos with a
particular encryption scheme implemented only by a particular CDM
which is strictly licensed to only certain browsers/OSes they like,
they anyone not on their list is unable to play the video.


> It lowers the barrier to entry for anyone intending to develop a new CDM by
> creating a way to do that without having to also invent and support a new
> media stack or even a whole UI framework to achieve broad adoption. This
> enables increased competition and innovation in this area, much of it likely
> towards user benefit.

It enables increased competition in the space of DRM schemes.  You
assert that competition in this area would be to user benefit.  Could
you provide some reasoning for this claim?  The historical trends
point to innovation in DRM producing things that are ever less
convenient for users.  If we were still in the good old days, we'd
unencrypt the video using a random word from the back cover of the
movie's box.  Now I have to let a distributor install a rootkit in my
system, have a persistent internet connection while using the program
even if it doesn't use the internet in any way, and can't change my
hardware too much without begging the distributor to unlock my
property again.


> If widely supported, it also lowers the barrier to entry for content
> distributors. Content distributors would no longer have to collaborate
> tightly with a large number of browser or framework vendors and device
> manufacturers to create proprietary and fragmented solutions for premium
> content playback (all of which is costly, and limits the number or
> participants). The resulting increased competition and innovation benefits
> the user.

The current barrier to entry for content distributors is effectively
zero - they just have to put video on their servers, and use the
<video> tag to play it for their customers.  Distributors
intentionally make things more difficult for themselves with onerous
contracts, but that's not our concern.  They could just *not* do that,
and they'd be off the hook.  The music industry has, at least
somewhat, learned how to do this.


> It also enables a world where it will matter a lot less than today which
> CDMs a user's browser or device supports.
> - Content distributors could implement the server counterparts for multiple
> CDMs, and the cost of doing so is much lower than today since CDM scope is
> reduced to key delivery & decryption, and therefore the same media formats
> can be used with multiple CDMs.

This assumes that the CDM is open-source and royalty-free.  Neither of
these are true of current CDMs, and so implementing multiple of them
is still costly and difficult.  I don't believe any of the current
targets for this specification intend to produce and use CDMs which
are open-source and royalty-free, either.


> - Browser vendors or device manufacturers do not have to agree on which CDMs
> to support.
> In this world, users would benefit because the likelihood that their device
> will be able to play content of a given service is increased.
>
> To illustrate, let's assume
> - browser/device B1 supports CDMs A and B,
> - browser/device B2 supports CDM A,
> - browser/device B3 supports CDMs C and D
> and
> - content distributor CD1 supports CDM A and C
> - content distributor CD2 supports CDM A, B and D
> In this example, *all* browsers/devices can play content from *all* content
> distributors even though none of the content distributors support all CDMs,
> and the browsers/devices do not support a common set of CDMs.
> This is not full interoperability, but a lot more of it than in today's
> world. The user wins.

This is a carefully set-up scenario where everyone conveniently
interoperates.  There are several reasonable additions to the scenario
that break that property:

- browser/device B4 supports CDM B and D (and thus can't play anything from CD1)
- content distributor CD3 supports CDM E, which they strictly control
and only allow browser B5 to license (nobody but B5 can play anything
from CD3)
- browser/device B6 can't support any of the CDMs in use, because all
of the CDMs are closed-source and none of the CDM producers wish to
port their programs to B6 as it's a new entrant to the market and has
little marketshare yet.  Since they can't play video from any of the
content distributors, it's unlikely they'll ever gain significant
marketshare.

~TJ

Received on Sunday, 4 March 2012 16:50:38 UTC