Fighting DRM in the W3C

Cory Doctorow has a good post on the EFF website about how they’re trying to fight digital rights management software in the World Wide Web Consortium.

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.

The W3C added DRM to the web’s standards in 2013. This doesn’t reverse that terrible decision, but it’s a step in the right direction.

Tags: DRM, EFF, web

Posted on January 14, 2016 at 2:13 PM • 12 Comments

Comments

Narkor • January 14, 2016 4:13 PM

Doctorow believes intellectual property is unethical and that everything should be public domain.

Ben • January 14, 2016 5:18 PM

Honestly I’m having a hard time getting worked up about this. The W3C is not standardizing or mandating any DRM system, just an interface to binary-blob plugins. No one would have abandoned DRM had the W3C not standardized an interface. They would have used a bespoke interface as they’ve always done before. The standard does allow them to say that their DRM is HTML5-compliant (do consumers really care?), but that also means the W3C has some leverage that they can use to make DRM slightly less awful. And it does seem like they’ve tried to do so (“It MUST NOT be possible […] to correlate identifiers from multiple origins, such as to determine that they came from the same client or user”—I doubt a proprietary spec would have a clause like that). Cory Doctorow now wants them to go further in that direction. If they succeed, isn’t that better than if they’d stayed out of it entirely?

Anura • January 14, 2016 5:30 PM

@Ben

“Honestly I’m having a hard time getting worked up about this. The W3C is not standardizing or mandating any DRM system, just an interface to binary-blob plugins.”

This has nothing to do with plugins. W3C Media Source Extensions already provided an API for using codecs in JavaScript without having to interface with a plugin, and support for plugins in HTML5 is the same as earlier standards. Encrypted Media Extensions is specifically to allow the use of DRM, and serves no other purpose.

Thoth • January 14, 2016 6:15 PM

@Anura
The EME Extension is a software module and is not secure by any means. A lower layer interface with cryptographic keys interception capability could render the Web DRM module useless I guess ?

Another method would be to intercept the decrypted stream and pipe it to storage. Either way, the DRM on client side is flawed especially with software only security. The only problem is watermarks embedded in DRM-ed media that make provide liability.

Ben • January 14, 2016 6:26 PM

@Anura, I understand that it’s only for DRM. It would have been clearer if I’d written “The W3C is not standardizing or mandating any particular DRM system, just an interface to binary-blob DRM plugins.”

Anura • January 14, 2016 6:27 PM

@Thoth

DRM in and of itself relies on the client being able to decrypt the data. Even hardware-level DRM is breakable; it simply takes more effort than software-level. DRM is a lot of time and effort spent on something that can only ever harm legitimate users.

Cassandra • January 15, 2016 4:43 AM

One of the things I have mused about is the energy-cost of DRM. When DRM uses encryption, there is a fair amount of processing of information that goes on, and that costs energy. I wonder how much extra energy the entertainment industry has forced us to use decrypting the same information over and over and over again, compared to just having the plain text and not needing to decrypt?

One day, I might even have a go at doing the calculations. It’s probably not much, but it will be non-zero.

Cassandra • January 15, 2016 4:50 AM

Here’s a random paper addressing the topic in part:

http://ijcte.org/papers/049.pdf

“Energy Efficiency of Encryption Schemes for Wireless Devices”
International Journal of Computer Theory and Engineering, Vol. 1, No. 3, August, 2009
1793-8201

Machin Shin • January 15, 2016 11:06 AM

A large part of the issue is that they are making the HTML standard and building DRM into it. This makes a big issue for those that care about open source and free (as in freedom) software. Debian linux for example has strict rules that included software must be open. This is a big issue because the DRM part of the web browser will not be open with this standard. Meaning Debian cannot ship with a fully HTML 5 compliant browser.

Anura • January 15, 2016 11:16 AM

@Machin Shin

Encrypted Media Extensions is an extension to HTML5, and not required to be HTML5 compliant.

ianf • January 15, 2016 6:35 PM

@ Cassandra

One of the things I have mused about is the energy-cost of DRM. When DRM uses encryption, there is a fair amount of processing of information that goes on, and that costs energy.

You’re onto something, especially in the context of mobile devices, but before you embark on the research route (vessel?), make a survey of listed vs. validated battery lives for specified DRM-media playback. I know only of the iPad definitely being good for 10hrs of video streaming, and one of the earlier Kindles for more than 2 weeks’ reading of .mobi/.awz-encrypted ebooks on a single charge. But maybe the energy overhead for (Adobe Digital Editions DRM) epub-ebooks on iOS etc is still negligible in comparison with other, native graphics-heavy processing in apps on said mobiles?

Incidentally, you raised this issue, so you ought to read and summarize the findings of that your subsequently found “random” paper here:

“Energy Efficiency of Encryption Schemes for Wireless Devices”
International Journal of Computer Theory and Engineering, Vol. 1, No. 3, August, 2009 1793‍-8201

Garrett • January 16, 2016 4:41 PM

Brendan Eich was a major opponent to DRM being added to W3C specifications. Good thing Cory Doctorow got rid of him.

Fighting DRM in the W3C

Comments

Leave a comment Cancel reply