Cory Doctorow on the problems with Encrypted Media Extensions
Confronting the World Wide Web Consortium on the new digital rights management specification.
Locked chest (source: Sander van der Wel via Flickr)
I talked with Cory Doctorow, a journalist, activist and science fiction writer, for a recent episode of the O’Reilly Security Podcast. We discuss the EFF lawsuit against the U.S. government; the prospect for a whole new industry of pro-security businesses; and the new W3C DRM specification.
Some highlights are below:
Learn faster. Dig deeper. See farther.
The problem with the W3C’s new DRM specification
The World Wide Web Consortium (W3C) historically has been the leading standards body for open standards for the Web. When you make a standards-compliant web browser, you make it W3C standards-compliant. For a lot of complicated and sad reasons, they decided they would standardize digital rights management (DRM)—mostly because apps were starting to eat into browsers, the browser vendors were demanding it, and the W3C was worried about losing its relevance. For the last three years, the W3C has been working on something called Encrypted Media Extensions, or EME, which will create the situation where, for the first time in history, implementing a standards-compliant browser will mean creating a piece of software that is covered by the DMCA (and laws like it) and that security researchers won’t be able to audit without legal risks.
Protecting accessibility in browsers
Many countries enshrine the right to adapt copyrighted works for people who have disabilities, but not if they have to bypass DRM. So we [Electronic Frontier Foundation] said to the W3C, “For accessibility, for interoperability, for competition, for all of these good reasons and security besides, you should make your members promise not to use their DRM rights, their DMCA rights, to attack people who engage in otherwise lawful conduct but have to break the DRM to do it.” We now have 17 W3C members confirmed and ready to block any further progress on the specification. The specification was supposed to go to recommendation or draft recommendation in early August, but they’ve been delayed because they had some problems with their test cases. In the meantime, we also have this massive petition that’s been signed by some of the world’s leading security and cryptography researchers, including names you’ll know—like Bruce Schneier, Ron Rivest, and Alex Halderman—and that petition is live. If your listeners send me an email, cory@eff.org, and include what country they’re in and what institutional affiliation, if any, they want to list, I will add their names to it.
Early intervention to prevent a major compromise
The W3C has historically done the work of the angels. I understand that the Web is under real grave attack from many quarters right now, and that doing DRM for them feels like a minor compromise, since there’s already DRM that’s not standards-defined in browsers. Although that’s not going to be true for much longer—one of the things HTML5 is doing is unsetting NSAPI, which is the API through which DRM ran, but was also a security nightmare. One of the reasons the W3C feels it has to make standards-defined DRM is that without it, there’s just no easy way to get DRM into browsers. I understand that they think it’s a minor compromise. I think it’s a major compromise, and I think the W3C needs to do better here, and that we can make them do better. Every one of us sometimes makes a bad call, and we need our friends to intervene to stop that bad call from spiraling out of control; that’s what I think we’re doing with the W3C.
Related resources: