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
- Josh Triplett wrote a comment on this which I found particularly helpful
- It helped me understand how there might be TAG-appropriate
architectural issues involved in the DRM debate
- Hard to identify
- Often obscured by the non-technical aspects of the 'debate'
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:
- 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
- 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
Copyright © 2013 World Wide Web Consortium
Completely license-protected web-to-screen pathways require CDM-integration with the platform software and hardware.
- I commend Peter Gutmann's A Cost Analysis of Windows Vista Content Protection, an analysis of the impact of this requirement on Microsoft Vista and contemporary hardware (chipsets and displays), to those interested in understanding this point and its practical (and architectural) significance in detail.
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
- videos embedded in <object> tags with the relevant Adobe/Macromedia/Apple classids historically could only be played using proprietary, non-open-source plugins
As I understand it, Tim's argument (and that of other W3C staff, including CEO Jeff Jaffe) depend essentially on that parallel.
- "We're just giving you the EME"
- C.f. "we're just giving you the object tag"
- "It's a matter between consenting
adults and part of the Open Web if content owners use that functionality
to deliver protected content, and users install the necessary CDM to view it"
- C.f. "... to deliver protected content, and users install the necessary proprietary plugins ..."
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.
- Whether all the necessary software components of a proprietary, acceptably robust, CDM could be integrated into Linux is a much harder question
- We already have the situation where consumers discover that they cannot watch DVDs they have purchased on their home computers, because the display on their system does not implement the necessary hardware DRM support
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
- Can we really let EME out of CR on the basis of implementations of clear-key CDM only?
- If it turns out that in principle no robust CDM can be implemented for integration with browsers running on Linux, have we really demonstrated interop?
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.
- Saying "Oh, sorry, you can't watch online videos from Such-and-So even though you're willing to pay for them, because you're running Linux and there's no appropriate CDM available" seems rather different.
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.
- The <object> tag argument is not itself a technical one. But it is a useful way to reality-check arguments about what is meant by "Open Web".
I don't think the TAG has the expertise at the moment to address the ghettoisation point directly
- but it may be that it is better placed within the W3C than anyone else to make sure that they get addressed.
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."
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.