W3C EME is not DRM (nor other fear-mongering TLAs)

Photo of hippie, text: Thinks EME and DRM are unethical. Uses Chrome. 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.

  1. DRM in HTML5 is a victory for the open Web, not a defeat, at Ars Technica, May 10, 2013.
  2. Dear EFF: please don’t pick the wrong fight, by Chris Adams, October 4, 2013.
  3. The Bridge of Khazad-DRM, by Brendan Eich (Mozilla CTO), October 22, 2013.
  4. (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 post). You can hear my clip at 5:20.

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.

Update: July 31, 2017

You can follow this thread asking Cory to weigh in on EME and his angle on how opposing it helps people with disabilities:

Many in the accessibility community are wary of this angle. Especially since it really only came to the fore when other attempts to block EME at W3C were rebuffed. Given this argument:

…I would hope that EFF is willing to take as strong a stand against Twitter and its use as a tool to allow attacks on others prone to seizures.

Update: September 18, 2017

EME is officially a W3C recommendation. W3C put out a press release that reads a bit too much like Kool-Aid drunkenness for my taste, but there it is: W3C Publishes Encrypted Media Extensions (EME) as a W3C Recommendation.

There is also a less rah-rah post from Jeff Jaffe, Reflections on the EME debate. I think he hits a point worth noting, even if I do not agree:

There is potential fallout from the debate. Some on both sides of the issue complained about the intensity of the arguments on the other side. Others told me that they felt that the overall intensity of the debate was harmful to W3C.

Update: September 19, 2017

The EFF has resigned from the W3C in an open letter. This is not surprising. EFF joined W3C for the express purpose of disrupting EME. Frankly, given how Cory Doctorow has been using misdirection and misrepresentation, and most recently trying to use accessibility as a shill, this is better for both organizations.

Sadly, my opinion of EFF has dropped in all of this as well. For an organization that claims to be technical in nature, it has invested too much time and effort fighting the wrong people in the battle over DRM. That it also allowed Cory Doctorow to hijack it so deftly also makes me worry about the organization’s capacity for recognizing a straw man (argument or person).

Alastair Campbell wraps it up nicely in his post from just a couple hours ago:

I get that DRM is not a good thing, I agree, but the EFF attacks the W3C by relying on two false assumptions:

  1. Browsers would not have implemented DRM without the W3C’s blessing (and the alternative is better).
  2. It would be possible for some people can bypass DRM but not others.

The misdirection is playing on people’s assumptions that the W3C controls the technology, and implying that EME is DRM rather than an API to DRM.

I am trying to find a positive from the EFF letter, but all I see is a commitment to do something the EFF should have been doing all along instead of squandering resources and effort going after the wrong people. Anyway, maybe there is some hope here:

So we’ll keep fighting to fight to keep the web free and open. We’ll keep suing the US government to overturn the laws that make DRM so toxic, and we’ll keep bringing that fight to the world’s legislatures that are being misled by the US Trade Representative to instigate local equivalents to America’s legal mistakes.


Consider all the effort expended fighting an API since 2013 that could have been better used fighting DRM laws.

Update: September 22, 2017

Hearing and seeing all the folks on Twitter who are engaging in hyperbole (more, and more [tweet by @elrond25 deleted], yet more [tweet by @LibertyPaulM deleted], also more, and so on) about the W3C’s decision on EME, the W3C published a response (W3C hearing the concerns the EME recommendation raises) that addresses the most common arguments (each link below is an anchor link to that part of the document):

Those who are invested in their position will not be swayed.



I agree that there's significant fear-mongering about DRM. However, I'd rather there was a real DRM spec in web standards. I think EME is a bad idea because I think it's likely that content providers would directly provide the plugins, and that they'd be controlled under service contracts instead of EULAs. Together these could represent a significant new level of corporate access to our computers. I wrote an article about this on Medium: https://medium.com/cyber-security/36f7eed1e9b2


I was sorry to hear how your quote in that podcast was (mis)used, Adrian. I’m even sorrier now that I know you made time for a lengthy interview with them. However, thank you for doing it.

In response to Coralie Mercier. Reply

Thanks, Coralie. I suspect a combination of TimBL’s brand new EME post and my probably too-technical-for-its-audience responses were a factor in my limited airtime. It was this blog post that put me on their radar, so at least they knew what they were getting.


EME is fucking garbage: https://www.w3.org/TR/encrypted-media/
It does zero things for user’s safety. Does it even defines how CDM should be? FUCK NO. It even says that multiple implementations of CDM could exist and they might not be compatable. And it creates one question: why the hell we need CDM even? You can do the same with the javascript, it’s better and portable and it’s safer. Oh, I get why: because proprietary CDM could allow them to screw with the customers by treating them different (Netflix, one of the editors already does that, with Microsoft browser getting 1080p videos). Also, CDM could even work with your videocard driver. And they are admiting that flaws in CDM implementation could allow to screw your computer.

Asukafag; . Permalink
In response to Asukafag. Reply

You can use JS to give special treatment based on browser or operating system, too, as well as use it to screw with people’s computers. I’m not saying a proprietary option is the right way to go, but pretending JS is secure is just sticking your head in the sand. In fact, it’s so insecure that just allowing it in adds makes the spread of malware and hijacking browsers super easy.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>