You Can't Destroy the Village to Save It: W3C vs DRM, Round Two
The World Wide Web Consortium (W3C), the nonprofit body that maintains the Web's core standards, made a terrible mistake in 2013: they decided to add DRM—the digital locks that train your computer to say "I can't let you do that, Dave"; rather than "Yes, boss"—to the Web's standards.
At the time, we fought the proposal on a principled basis: DRM has no place in the open Internet because of the many ways it shuts down legal, legitimate activities.
So we came back with a new proposal: the W3C could have its cake and eat it too. It 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. They could make DRM, but only if they made sure that they took steps to stop that DRM from being used to attack the open Web.
This is nowhere near as good as the W3C rejecting DRM altogether, but it's much better than nothing. If the W3C is going to create new DRM standards, let them make them in a way that minimizes the risk to security researchers and standards-implementers, the people that the W3C exists to serve.
We've asked the W3C to make this into their policy. The only W3C group presently engaged in DRM standardization is due to have its charter renewed in early 2016. The W3C called a poll over that charter during the Christmas month, ending on December 30th.
Despite the tight timeline and the number of members who were unavailable over the holidays, a global, diverse coalition of commercial firms, nonprofits and educational institutions came together to endorse this proposal. More than three quarters of those who weighed in on our proposal supported it. Those supporters include Stanford University, the Open University, the University of Southampton, Pontifical Catholic University of Rio de Janeiro, Ripple (a payments company), the Hypothes.is project and several others all said that they would not agree with the group being rechartered at all unless EFF's covenenant were made a condition of participation.
The proposal is now in the hands of the W3C's executive, specifically W3C CEO Jeff Jaffe and Director Tim Berners-Lee. They have it in their power to substantially mitigate some of the worst potential effects of DRM at the W3C. If the W3C adopts EFF's proposal, they will be saying to the companies that push for DRM: "You are welcome to standardize any technology in our group, but you must promise not to use that work to sue programmers for doing normal things that are important to the Web's openness and survival."
To understand why DRM is a bad technology for open standardization, you need to understand the laws that protect it.
Around the world, 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 establish special legal protections for DRM. These governments (and many others) give legal backing to companies that try to lock you out of devices, software, and media that you own, and this interferes with activities like repairing your own electronics or your car, making backups or remixes of videos, auditing the security of medical devices, and many more legitimate and otherwise-lawful activities.
It gets worse. In practice, it's not hard to break DRM, so to slow the spread of information about how to remove the locks on the stuff you own, laws like the DMCA also has been used to punish disclosure of bugs and defects. This doesn't mean that bad guys—enemy spies, cyber arms-dealers, voyeurs, identity thieves, and griefers—don't discover and weaponize these bugs. It just means that you don't get to learn about them until they are used in a high-profile attack, or until a brave security researcher risks a lawsuit to come forward.
While DRM has many other failings, these two are especially pointed in the context of Web standards:
1. DRM is incompatible with interoperability
Interoperability—plugging one thing into another—is why standards exist. Sometimes, vendors welcome interop, offering APIs and other hooks for follow-on tools to plug into. Sometimes, manufacturers don't bother, or actively try to block third party equipment from playing nice with their own (think of inkjet printer cartridges). In the absence of DRM, it's perfectly legit (and common) for manufacturers to figure out how to let you plug something they make into something you own, even when this goes against the wishes of the original manufacturer. You bought it, you own it, you get to decide what you plug into it.
DRM exists to stop users from doing things they want to do and to stop innovative companies from helping users do things they want to do -- or would want to do, if they had the option. Your cable box, for example, will be designed to stop you from recording your favorite shows for long-term storage and viewing on the go.
But if you could just plug any digital video recorder into your cable box, you could record those shows, move them to your laptop, and watch them ten years from now. DRM locks up the data coming out of your cable box with encryption that is arguably unlawful to break, even to do something legal, like make a copy for personal use.
That's not unusual: tech companies have dreamed of the "toaster-maker gets to sell you the bread" business since forever. The common response to this is for a competing manufacturer to design a widget that converts the proprietary, locked output from your gadget into a standard, open one, that can accept a variety of apps, recorders, lightbulbs, bread, etc.
DRM laws put a roadblock in the way of this innovation. So DRM only exists to prevent compatibility without explicit permission—the opposite of a standard.
2. DRM is a security disaster
The prohibition on reporting bugs in systems with DRM makes those bugs last longer, and get exploited harder before they're patched. Last summer, the US Copyright Office collected evidence about DRM interfering with reporting bugs in tractors, cars, medical implants, and critical national infrastructure. The W3C's roadmap for HTML5 is for it to have the flexibility and power to replace apps as the default way to control all those devices and more. If standards-compliant browsers have legal barriers to reporting vulnerabilities in them, it exposes the whole technological world and everything we do in it at risk of attacks that can't be headed off until it's too late.
Many of the eminent security researchers who participated in the Copyright Office's latest rulemaking to consider exemptions to Section 1201 of the US DMCA have endorsed EFF's proposal for a nonaggression covenant, including Bruce Schneier, Matthew Blaze and Matthew Green.
This isn't the first collision between proprietary rights and the W3C. In 1999, the W3C had to decide what to do about software patents. These patents were and are hugely controversial, and the W3C was looking for a way to be neutral on the question of whether patents were good or bad, while still protecting the Web's openness to anyone who wanted to develop for it.
They came up with a brilliant strategy: a patent nonaggression policy—a policy we modelled our DRM proposal on. Under this policy, participation in a W3C group meant that you had to promise your company wouldn't use its patents to sue over anything that group produced. This policy let the W3C take a position on the open Web (the Web is more open when your risk of getting sued for making it better is reduced) without taking a policy on whether patents are good.
The DRM covenant does the same thing. Without taking a position on DRM, it takes the inarguable position that the Web gets more open when the number of people who can sue you for reporting bugs in it or connecting new things to it goes down.
The World Wide Web Consortium is at a crossroads. Much of the "Web" is disappearing into apps and into the big companies' walled gardens. If it is to be relevant in the decades to come, it must do everything it can to keep the Web open as an alternative to those walled gardens. We're trying hard to help them do that. But if the W3C executive won't take the lead on keeping the Web open, they must, at a minimum, not impede those who haven't given up the fight.