Intro to technical background for DRM discussions

Henry S. Thompson
8 Jan 2014

1. Origins

This is a very lightly edited selection from an email thread I started on the www-tag list on 22 October 2013.

2. Starting points

Tim wrote an earlier blog post

3. The (then) current W3C story

Providing a robust (read: acceptable to W3C members who are pushing this) Digital Rights Management (DRM) capability in HTML5 comes in two parts:

  1. Some Encrypted Media Extensions (EME): extensions to the <audio> and <video> tags and special-purpose APIs associated with them to hand access-control for the media they identify to
  2. A Content Decryption Module (CDM):
    "a part of or add-on to the user agent that provides functionality for one or more Key Systems."
    "A Key System is a generic term for a decryption mechanism and/or content protection provider."

The current EME draft says (in the Abstract):

"Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline."

I think we can safely stipulate that the simple clear key system will not be judged robust enough to satisfy some important content providers.

4. Some observations

As only obliquely implied by this introductory diagram in the EME draft

box diagram of EME/CDM relationship
Copyright © 2013 World Wide Web Consortium

Completely license-protected web-to-screen pathways require CDM-integration with the platform software and hardware.

It seems very unlikely that platform owners catering to content providers intending to make use of strong DRM protection for their content will provide open-source implementations of their CDMs, or even allow for plugin support: only platform-native CDMs will be acceptable (see David Baron's contribution to the thread).

5. The Open Web argument ("There are precedents")

If W3C's EME spec goes ahead, the prospective situation seems, as Triplett points out, to be broadly comparable to what we already have with respect to the <object> tag and e.g. Flash or Quicktime

As I understand it, Tim's argument (and that of other W3C staff, including CEO Jeff Jaffe) depend essentially on that parallel.

6. The ownership argument ("All your platform are belong to us")

It is perfectly possible to install proprietary software, including e.g. graphics card drivers, under many if not most Linux distributions.

Not only does putting EME in HTML5 enable the same difficulty to arise for video and audio content on the Web, but it also extends the scope for similar much more extensive failures

Saying "Well, you don't have to watch online videos from Such-and-So if you don't want to pay for them and install an acceptable CDM" is one thing.

7. Conclusions

I'm now convinced that there are at least some _technical_ and/or architectural aspects to this debate.

It seems to me the burden of proof lies with the advocates of EME inclusion, to show that including EME in HTML5 will not lead to (non-expert-sysadmin-level) Linux users being confined to a CDM-free ghetto where they cannot (legally) access DRM-protected content.

I don't think the TAG has the expertise at the moment to address the ghettoisation point directly

Henri Sivonen's contribution to the thread, and particularly his "What is EME?" page, discuss the technical dimension in careful detail

8. Forward-looking responses

Tim replied, inter alia, to David Baron

"Can we imagine or design a EME system which instead as usable by anyone as a publisher? Suppose anyone could set up an web serve and serve encrypted content to end users without going through a bottleneck vendor."

Henri Sivonen's response:

I find it very distressing that you are talking about making DRM egalitarian in this sense rather than talking about making DRM egalitarian in the sense of allowing anyone to implement and ship the client technology stack royalty-free and without having to get keys signed by a particular gatekeeper or talking about making DRM egalitarian in the sense of different suppliers of the non-DRM parts of the stack having a level playing field when it comes to integrating with the DRM part as opposed to DRM component supply getting coupled with the supply of the rest of the client stack.