Over many objections, W3C approves DRM for HTML5

Contentious feature is added, without mandate to protect security researchers.

A system for providing DRM protection to Web-based content is now an official recommendation from W3C.

In 2013, the World Wide Web Consortium (W3C), the industry body that oversees the development of Web standards, took the controversial decision to develop a system for integrating DRM into browsers. The Encrypted Media Extensions (EME) would offer a way for content producers to encrypt and protect audio and video content from within their plugin-free HTML-and-JavaScript applications.

EME is not itself a DRM system. Rather, it is a specification that allows JavaScript applications to interact with DRM modules to handle things like encryption keys and decrypting the protected data. Microsoft, Google, and Adobe all have DRM modules that comply with the spec.

The decision to bless the EME specification as a W3C standard was made last week in spite of substantial opposition from organizations such as the Electronic Frontier Foundation (EFF). Many opponents of this regard any attempt to impose such technical restrictions as an affront to the open Web. But HTML's inventor and W3C's director, Tim Berners-Lee, decided that the objections to EME were not sufficient to justify blocking the spec, giving it his, and hence the organization's, approval.

When W3C's 2013 decision was announced, the battle lines were immediately drawn. On the one hand were organizations like the MPAA and Netflix, with business models that depend, in whole or in part, on the ability to protect content from being trivially copied. On the other were groups opposed to DRM on principle. Those groups either reject the notion of restricted distribution at all or reject the way that DRM does an end-run around the "fair use" provisions of copyright law, preventing people from using protected media in ways that are legally protected and do not require the consent of the rights holder.

While these lines didn't really shift—the arguments around DRM are much older than W3C's interest in it—some level of support did emerge from those who might otherwise be opposed to DRM. The alternatives to DRM through the browser are not, in practice, the distribution of unprotected content; rather, companies such as Netflix will instead turn to either proprietary apps or proprietary browser plugins. These apps and plugins tend to be relatively unrestricted in terms of what they can do to a system and what behavior they can monitor. DRM modules built for EME, however, would be subject to rather stricter constraints. They wouldn't demand administrator-level system access to install, for example, and they'd be subject to the browser's various sandboxing rules.
As such, EME was seen by some as providing a way of forcing DRM to be less invasive and better-behaved, representing a step forward even for those opposed to DRM in general.

During EME's development process, certain compromises were proposed and rejected. EFF proposed a binding covenant on W3C members that would prohibit them from using legal action against those who bypassed or circumvented DRM, provided that such bypasses were only used to assert legal, fair use rights—in other words, only use the law to go after pirates. This was rejected by pro-DRM members of W3C.

As a weaker compromise, there was also hope that W3C might be able to alleviate some of the concerns around the legal protection given to DRM such as the US's Digital Millennium Copyright Act, which outlaws anything that circumvents DRM. This was especially important to security researchers. Researchers wanted the ability to inspect the DRM modules built for EME, and report flaws found therein, without risking prosecution under the DMCA or similar national laws.

A narrower covenant not to sue was proposed, but even this much narrower covenant was rejected. The various members of W3C appeared unlikely agree to any particular set of terms, and ultimately were never polled to see if consensus could be reached. Since the original EME proposal didn't include such a covenant, Berners-Lee decreed that failure to form one should not be allowed to block publication as an official W3C Recommendation.