Encrypted Media proposal: Summary of the discussion so far

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.

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.

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.


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.

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.


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

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


Summary of the summary

- the proposal does not address nor claim to resolve the inherent
shortcomings of content protection schemes as we know them today.
- it tries to enable their use in a standardized and interchangeable
fashion, thus improving deployability, avoiding fragmentation, and enabling
increased competition and innovation in this space.
- it attempts to alleviate some of the problems of historic and current
implementations of content protection, for the benefit of both the user and
content distributors.
- modes of deployment of commercial CDMs for browsers are intentionally not
part of the proposal. Some group members would like more clarity in this
area.
- some group members fundamentally disagree with how content protection is
used in business today, and oppose the proposal on these grounds.

Christian