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 do 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.
Update: May 11, 2016
Cory Doctorow is again aiming his anti-DRM stance at the wrong target (EME), this time via The Guardian with the piece Why the future of web browsers belongs to the biggest tech firms. Now he argues that EME will stifle browser development and create a duopoly of Google and Apple.
Now that EME is a standard, we may never get another Mozilla-like eruption of new browsers – browsers that cater to users, not corporations.
Never mind that I am using both Brave (January 2016) and Vivaldi (January 2015) on this computer.
You can probably dismiss this as his effort to open a new front on a war against a spec he clearly does not understand. As further evidence he is getting his basic facts wrong, here is how he opens the piece:
Ten years ago, there were two web browsers that anyone cared about: Netscape and Internet Explorer.
The timelines suggest Netscape was already dead by then (global stats confirm that). Heck, in 2002 some were hoping AOL would resurrect Netscape by making it the default.
Update: May 15, 2016
Cory has authored pieces at EFF, Save Firefox! and An Open Letter to Members of the W3C Advisory Committee.
Also, yet another browser was just released (though it is built on Chromium), this one aimed at developers and only available for Windows for now: Blisk.
Update: June 30, 3016
W3C finally makes a statement in response to the latest mis-cast from Cory Doctorow (i use that term because while he is technically wrong, I do not think it is an intentional lie).
I never posted the W3C EME fact sheet from back in March, which was a response to the regular mis-statements about EME. Unlike the fact sheet, this time W3C has a more direct response:
EME is not a DRM standard. W3C does not make DRM. The specification does not define a content protection or Digital Rights Management system. Rather, EME defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.
The W3C took the EFF covenant proposal extremely seriously. […] the large majority of W3C Members did not wish to accept the covenant as written (the version they voted on was different from the version the EFF made public) […]
The proceedings of the HTML Media Extensions work are public however, discussions amongst Advisory Committee members are confidential.
Update: February 28, 2017
Tim Berners-Lee has weighed in with his post On EME In HTML5. Sadly, I am on a plane and unable to quote it easily here.
Update: March 3, 2017
The Reply All podcast discusses EME, and after a lengthy interview, uses a quote from me about W3C conference calls (for context, the podcast contacted me to discuss EME, primarily driven by this podcast).
Cory Doctorow should be happy with it, as the podcast incorrectly defines EME as DRM. So his message is working.
Update: March 8, 2017
While it takes a bit long for this Ars Technica article to explain that EME is not DRM, overall it makes a case for EME as necessary for the open web.
[…] Deprived of the ability to use browser plugins, protected content distributors are not, in general, switching to unprotected media. Instead, they’re switching away from the Web entirely. Want to send DRM-protected video to an iPhone? “There’s an app for that.” Native applications on iOS, Android, Windows Phone, and Windows 8 can all implement DRM, with some platforms, such as Android and Windows 8, even offering various APIs and features to assist this.
In other words, the alternative to using DRM in browser plugins on the Web is not “abandoning DRM;” it’s “abandoning the Web.”
Update: April 7, 2017
Cory Doctorow, in his role with EFF, argued in a March 29 post, Interoperability and the W3C: Defending the Future from the Present, that EME was bad for accessibility. He also filed the same material as a formal objection against the EME spec on March 23.
Yesterday the W3C amended a prior statement about EME and accessibility and promoted it via Twitter this morning:
During an Advisory Committee review of the Encrypted Media Extensions (aka EME) specification, concerns were raised regarding potential accessibility for people with disabilities. […] We have not found any such barriers in our investigation.
The document goes on to describe the process followed and summarize the results.