DRM Still Coming to the HTML
In March, the World Wide Web Consortium (W3C) threw out a nonaggression covenant that would safeguard people from some of the legal risk associated with building DRM (digital rights management) into the open web. This means that the charter for the HTML Media Extensions Working Group—which oversees the Encrypted Media Extensions specification—has been extended through September 2016.[1]
Let’s step through this together.
The W3C is the nonprofit body governing the core technical standards for the web, responsible for ensuring that specs like HTML, WCAG (accessibility standards), and RDF are openly developed and implemented. In 2007 their HTML5 specification introduced the <video> element, which since has largely freed the web from the chokehold of third-party plugins—like Flash and Silverlight—except when that media needs to be locked down. Netflix obviously doesn’t want its viewers to right-click and download Jessica Jones the same way people save memes.
And although the capability of browsers improved so much so that the cool stuff afforded previously by plug-ins like Flash is now replicable without, our ability to Right-Click-View-Source pretty much guaranteed the persistence of those pesky, impossible-to-update Java applets. These impede the accessibility of the web and the security of its users. We knew it, the W3C knew it. So, a few years ago, they requested an alternative: “In February 2012 several W3C members proposed Encrypted Media Extensions (EME) to extend HTMLMediaElement that would replace the need for users to download and install ’plug-ins’ with a standard API (Application Programming Interface) that would automatically discover, select and interact with a third-party’s protected content.”[2] Encrypted Media Extensions work behind the scenes: when the browser recognizes that a video or audio happens to have one or more encrypted parts, it quickly negotiates the license then streams the content like you’d expect—no fuss, no Flash.
As a W3C member, the Electronic Frontier Foundation has been long since involved, intending to “persuade the W3C that supporting DRM is a bad idea for the Web, bad for interoperability, and bad for the organization.”[3] Electronic Frontier Foundation’s international director Danny O’Brien writes:
The W3C is composed of many thoughtful and experienced engineers and standards writers who know, often through personal experience, how painful digital rights management is to implement, how brittle it is in the face of inevitable attack, how privacy-invasive it can be, how damaging it can be for competition, and how often unpopular it is among consumers. … Our impression is that dominant reason why the W3C (and Tim Berners-Lee, as its tie-breaking Executive Director) has continued to permit DRM to be considered in the HTML working group is their hope that within the W3C, the worst parts of DRM might be tamed.[4]
Tim Berners-Lee himself said as much in October 2013:
No one likes DRM as a user, wherever it crops up. It is worth thinking, though, about what it is we do not like about existing DRM-based systems, and how we could possibly build a system which will be a more open, fairer one than the actual systems which we see today. If we, the programmers who design and build Web systems, are going to consider something which could be very onerous in many ways, what can we ask in return?[5]
The controversy, however, is chiefly legal. Opponents claim that since “laws like the US Digital Millennium Copyright Act, Canada’s C-11, New Zealand’s Bill 92A; and accords like the European EUCD, the Central American Free Trade Agreement, and the US-Australian and US-Korean Trade Agreements” make it illegal to tamper with DRM[6]; essentially, the open lawful development of the web cannot continue since, paradoxically, DRM is core to that development. O’Brien writes:
The W3C can’t fix that [paradox]. Even if its most optimistic goals of limiting the dangers of DRM came to pass—by defining strict sandboxing, say, or carefully cabining off its use in other Web standards—W3C standards could still be used to punish security researchers and attempts at interoperability. You can’t prosecute a researcher for finding a bug in your browser, or threaten someone for using your Web standard in a lawful way you didn’t approve of; but those are the dangers that hang over anyone investigating a DRM implementation.[7]
Thus the Electronic Frontier Foundation proposed in its “Objection to the rechartering of the W3C EME group” a DRM circumvention nonaggression covenant in which W3C members agree not to sue anyone for circumventing the encrypted media specification or in disclosing any vulnerabilities therein.[8] This proposal was rejected.
So, what does all this mean for libraries?
DRM in HTML means that libraries could possibly, more usefully, incorporate vendor-blocked content into their sites and applications without the need for users to download special software, or potentially even visit the vendors’ sites. The argument against, however, as presented by Cory Doctorow, suggests that what net gains there could be in the user experience may be at a substantial cost:
Equally significant in the world of open standards is protecting interoperability. The normal course of things in technology is that one company may make a product that interoperates with another company’s products, provided that they don’t violate a patent or engage in some other illegal conduct. But once DRM is in the mix, interoperability is only legal with permission.[9]
It’s an important conversation to have. Libraries’ predilection toward open source and direct involvement in the development of specs like RDF demonstrate greater stake in these discussions than not. There is an opportunity—albeit a diminishing one—to participate in this conversation, one that librarians on the front-lines of open access look past, unaware.
Resources
HTML Media Extensions Working Group Charter
HTML Media Extensions Working Group
Encrypted Media Extensions Spec
Why the future of web browsers belongs to the biggest tech firms
You can’t destroy the village to save it: W3C vs DRM, Round Two
References
[1] Philippe le Hegaret, “HTML Media Extensions to Continue Work,”W3C, April 5, 2016.
[2] “Information about W3C and Encrypted Media Extensions (EME),” W3C, March 20, 2016.
[3] Danny O’Brien, “DRM Non-Aggression on the Table at W3C,” Electronic Frontier Foundation, March 16, 2016.
[4] Ibid.
[5] Tim Berners-Lee, “On Encrypted Video and the Open Web,” W3C, October 9, 2013.
[6] Danny O’Brien, “DRM Non-Aggression on the Table at W3C.”
[7] Ibid.
[8] “Objections to the rechartering of the W3C EME group,” Electronic Frontier Foundation, December 15, 2015.
[9] Cory Doctorow, “An Open Letter to Members of the W3C Advisory Committee,”Electronic Frontier Foundation, May 12, 2016.
Tags: drm, encryption, extensions, html, libraries and net neutrality, open internet, w3c
