W3C EME is not DRM (nor other fear-mongering TLAs)
Plenty has been written about the W3C and DRM. Sadly, most of it has been written in the form of attacks against the W3C, with very few laying out the facts.
Note: I am a participant in the W3C HTML Working Group (as an invited expert). Encrypted Media Extensions (EME) are part of the scope of the HTML Working Group. You can decide if my opinion is tainted, but I owe nothing to the W3C to warrant arguing either way. I also don’t speak for the W3C.
In Doctorow’s latest post on Boing Boing, Requirements for DRM in HTML5 are a secret, he cherry-picks an email from the W3C’s Restricted Media Community Group where someone wants to dive into DRM requirements but is rebuffed simply because the W3C isn’t making DRM, just the APIs to access content protected by DRM (via the EME spec):
[…] what we are trying to do with EME is provide a
clean API to integrate these solutions with the HTML Media Element.
And that’s the crux of what the W3C is doing with DRM — developing a standard API so browsers can access content that will be locked down with or without their participation anyway.
The more W3C-savvy among you may recognize that W3C community groups don’t publish specifications, they provide a way for the general public to weigh in on topics and generate wider discussion. As stated on the Restricted Media Community Group page,
[T]his group will not publish specifications. In fact, if you are reading this and care about it, you should join. You may note that the people attacking the W3C haven’t.
If you still aren’t sure what the Encrypted Media Extensions (EME) spec has to do with DRM, then just read the abstract:
This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.
This is why Tim Berners-Lee declared it as in scope for the W3C. DRM exists and has existed for a long time. DRM requires plug-ins or third-party applications right now. By creating an API that all DRM systems use, playback in the browser will be possible (via Content Decryption Modules), thus helping to support an open web (just use your browser) instead of continued silos (Hulu app, Netflix app, Silverlight plug-in, etc).
Tim Berners-Lee provided further context in response to community outcry. Those who are bashing the W3C for DRM should read it, or perhaps just these salient points:
[I]f content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box. Those are key arguments for the decision that this topic is in scope.
This clearly doesn’t jive with the false headline Doctorow used in October, W3C green-lights adding DRM to the Web’s standards, says it’s OK for your browser to say “I can’t let you do that, Dave”.
It also doesn’t suggest the kind of future that Doctorow outlines in his personal post, We are Huxleying ourselves into the full Orwell, where he says
I’m not kidding about any of this. I can’t sleep anymore. I think it may be game over. Of all the things to lose sleep over, this really shouldn’t rank. I’m not kidding.
Cory Doctorow is fear-mongering. At this point I believe he is mis-representing the facts to further his agenda of stopping all forms of DRM, as there is more than enough evidence to suggest the opposite of what he claims (though he never links it, so perhaps he’s terrible at Google?). This may be because he genuinely doesn’t understand what EME is intended to address, or it may be to drive ad revenue on Boing Boing by hitting a volatile topic, but I’d like to think it’s the former.
People far smarter than I, and closer to the issues, have written about this. If you find my arguments lacking then you should read these before deciding the W3C is evil.
- DRM in HTML5 is a victory for the open Web, not a defeat, at Ars Technica, May 10, 2013.
- Dear EFF: please don’t pick the wrong fight, by Chris Adams, October 4, 2013.
- The Bridge of Khazad-DRM, by Brendan Eich (Mozilla CTO), October 22, 2013.
- (Austening ourselves to the full Brontë) Please Bring Me More Of That Yummy DRM Discussion, by Robin Berjon, January 10, 2014.
If you want to comment, I do not moderate but I don’t allow anonymous posts (strictly spam issues). If you want to post without linking to a social media account, contact me on Twitter and I’ll temporarily remove the restriction.
My rant that got me started…
Update: January 15, 2014
Well, here’s a nugget that suggests this conversation is unlikely to be calm:
Update: January 21, 2014
HTML5 Rocks published an article on the 16th titled EME WTF? An introduction to Encrypted Media Extensions. For those interested in seeing some code examples, take a look.
Update: February 14, 2014
Some of the members of the W3C TAG are hammering out a document about EME. They outline the goals here:
Over the web’s 25 years there have been several technologies and architectures which have had the effect of restricting access for some people to portions of the web. This document explores how these work and the effect they had on the web, with the ultimate goal of aiming to inform the debate about the inclusion of Encrypted Media Extensions (EME) in HTML.
In it they cite authentication and the
object element as current examples of restricted content on the web.
Update: January 13, 2016
Cory Doctorow has penned a piece at the EFF site, You Can’t Destroy the Village to Save It: W3C vs DRM, Round Two, where he once again accuses the W3C of creating a DRM spec. His wrong assertion aside, he is proposing that the W3C the following:
[W3C] could adopt a rule that requires members who help make DRM standards to promise not to sue people who report bugs in tools that conform to those standards, nor could they sue people just for making a standards-based tool that connected to theirs.