EME is not DRM

But should it be?

As I write this, it’s only a few days past the 25th birthday of the World Wide Web—although one might argue that March 1989 had more to do with the process of conception than the birth. I became involved in web standards in 1992, when the web was just learning to crawl. It’s been an interesting and sometimes messy process watching the web grow up, and now, at 25(ish) years, it’s a good time to think about where we’re headed. And right now the biggest change coming to the web is called EME.

The World Wide Web Consortium (W3C) is working with industry to develop “Encrypted Media Extensions” (EME) as a web technology standard. It’s a framework that allows third parties to write plugins for your browser that will implement Digital Rights Management (DRM). DRM is technology designed to make intellectual property like movies and music difficult to copy.

Protecting copyrighted material is fine in theory, but DRM has been controversial. At a minimum, DRM can interfere with legitimate uses of media, like fair use of short clips. And some DRM technologies takes steps that many consider excessive. On the one hand many of us have used iTunes, and while there are certainly some issues there with fair use, overall it’s been mostly benign. On the other hand sometimes DRM has been explicitly intrusive and disruptive. In one infamous case, Sony BMG added software to their audio CDs which would quietly modify the computer operating system to attempt to make it more difficult to copy their CDs. This software opened up security vulnerabilities on the computers and also consumed significant computer resources, all without any explicit permission from the unsuspecting new owner of the CD.

Because of issues like this, when word got out last year that the W3C was working on a standard related to DRM, it was big news. The web is traditionally an open technology, and to some it seemed like this was a step in the wrong direction. The Electronic Frontier Foundation (EFF) in particular was very critical of this choice. They published a scathing criticism of the W3C. And this criticism has lead to widespread broad criticism of any DRM technology in the web. [They also published a formal objection among other followups.]

The web standards architects at W3C are fully aware that this is a sensitive issue. This is likely why the new EME standard is not a direct implementation of DRM. It’s simply a way for web browsers to talk to a plugin that provides some sort of DRM technology. However this has failed to placate critics like the EFF.

The EFF’s criticism is born from high ideals. Open technology is a fantastic ideal, which I whole-heartedly support. I also very much agree with many of the criticisms they’ve published about EME. However, as an engineer I tend to think less about ideals and more about real-world examples. So I began to think about exactly what this EME standard could mean on the street.

To understand that we need to understand how DRM has affected the web so far. It’s hardly new to the web. It’s in plugins we use everyday like Flash and Silverlight. These are examples of DRM that have been more or less benign (although there are still critics with valid concerns). In other words, the web already has DRM, and so far that seems to be ok.

The Flash plugin was originally created to fill in gaps in web technology capabilities, like animations and video. It’s a general purpose plugin that provides all kinds of services. It works fine. But it’s always been uncomfortable that so much web content was being built on top of a proprietary product (Flash) instead of web standards. Thankfully, today most Flash features can be implemented using standardized web technologies. The only significant service provided by Flash that isn’t in modern web standards is DRM.

The new EME standard is an attempt to address this. It’s built around a plugin architecture, just like Flash. But it’s intended for a very limited purpose: to provide DRM. From a technology stand point, this all sounds like an improvement. The plugin is doing less, and that’s better, because the web is more standardized, and will work more consistently across platforms and products.

But exactly what that EME plugin is doing to implement DRM is left undefined. And pragmatically, there’s nothing that the W3C can do to control this plugin. This might sound sinister, but this is generally true of all software that we buy. We extend a great deal of trust to all software venders, and for the most part they stay in line. Angry Birds doesn’t copy our personal information and sell it to China (I assume). So the real question isn’t whether or not an EME plugin could do other things. The real question is whether or not it would.

Ultimately this is not a question of technology or web standards. It’s also not a question of a knee-jerk fear of anything labelled DRM. It’s about a monumental shift in the landscape of software providers and legal relationships.

Let’s start with the software provider. Up until now, our web software has come from organizations that “care” about us. Now I don’t want to be too generous to the corporate entity, as their sole purpose is to make money. But Microsoft (who produces Silverlight), Adobe (Flash), and Apple (iTunes) all have profit-centered reasons to “care” about the whole customer, i.e. as a consumer of computer software and equipment. It’s in their best interest to provide solutions that can be applied to many different situations and contexts without hampering our computer use.

When Apple brokered the deals with the music industry to sell their music through iTunes, Apple was able to get some compromises between their broad interests and the music industry’s narrow interests. It’s in the music industry’s best interest to do everything they can to protect their product, but it’s in Apple’s best interest to provide their customers with hardware and software the customer can trust.

In contrast with this, the Sony BMG incident provides an example of what we can end up with when the software comes directly from a content provider with narrow interests, rather than a general-purpose developer like Apple.

This then is one problem with EME. It makes it more likely that the EME plugins will come straight from the content vendors like Netflix or Hulu, or perhaps even directly from organizations like the Motion Picture Association of America (who recently joined the W3C to participate in the development of the EME standard). These are organizations with a very narrow focus. They want to sell you content without letting you steal it. They are very interested in protecting their property. They are not interested in your computer as a private communications device or a software development platform or anything else. These things do not serve to earn them money.

To put it another way, we actually obtained some protection from that fact that the Flash plugin did many things. Because of this, it had many masters, and it had to serve them all. An EME plugin will have only one purpose, and only one master.

That’s worrisome on it’s own, but it isn’t the only factor at play here. The change in software providers is likely to be more than just a shift in corporate culture—it’s likely to be accompanied by profound changes in our legal relationship with the software provider.

To some degree, we have a legal relationship with all the software we use. It’s described in those agreements that none of us ever bother reading because we just want to get on with using the software we’ve purchased. The End User Licensing Agreement, or EULA, is a ubiquitous mass of legalese attached to most purchased software that tries to restrict what we can do with that software. However, many people think that EULAs are fairly weak documents and whole sections of them may not be enforceable. This is (in part) because we have significant protections from traditional consumer rights—when we buy something we own it, and that ownership gives us broad rights to use it as we see fit.

But if EULAs are weak, there are other legal relationships that are not. For example a contract that you enter in exchange for an ongoing service is very different from a EULA. Service contracts are very real contracts that have been tested in courts for centuries, and tend to be very enforcable. They have teeth.

When you contract with a company (let’s call them FooFilmz) for your monthly movie addiction, you have a very real, very actionable contract with them. This contract describes your ongoing relationship of money for service, and each party’s legal rights and obligations. FooFilmz has a lot of leeway about what they can put into this contract—like the terms of the customer relationship with FooFilmz’ EME plugin.

So where does all this leave us? We have a company that’s writing software for your computer (an EME plugin) to protect their content. Unlike operating system vendors, they have a narrow purpose. They are creating software with only one master. They aren’t interested in your computer for other purposes. And they are providing you with this software under a solid ongoing contract which very clearly spells out exactly what you are allowed to do with their plugin, and what their plugin is allowed to do.

And what might their plugin be allowed to do?

Let’s start with something minor. If they feel that they only trust Microsoft and Google, then their EME plugin won’t work in Apple’s Safari web browser. This is an entirely plausible scenario. We’ve seen browser wars for years, and we’ve seen all sorts of tactics to include or exclude technology in this or that browser, so this is hardly new territory.

That’s a fairly passive example, but the plugin might take a more active role to further FooFilmz’ DRM goals. Suppose they feel that it’s in their best interest to scan your computer for piracy software, like software that can strip DRM protections. Or bitTorrent clients. They can do that. It’s hardly worse than what Sony BMG tried to do, and unlike that case, FooFilmz obtained your permission for this in their contract.

Or suppose they decide to scan your computer for actual pirated content. Like music and movies. This could actually lead to lawsuits or even criminal charges if FooFilmz so desired. This might seem outrageous, but back in the Napster days the music industry demonstrated their willingness to bring legal action against thousands of individuals that might be involved in copyright infringement. And again, if your contract with FooFilmz says they’re going to do this, it puts them on firm legal footing.

Finally, with Net Neutrality under fire recently, keep in mind that these plugins would almost certainly communicate with the web to help shape the content based on what’s available and what’s not. This is not necessarily sinister, and you could argue that this is the point of EME—if you visit FooFilmz’ website the presence or absence of a plugin could make the difference between “welcome customer” and “subscribe now”. But if it can control that content, it can also control content from other sites that might have contracts with the content providers. It’s entirely plausible that a search of movies on Google or Bing could yield different search results depending on whether or not you had this plugin.

It’s also just as plausible that FooFilmz could contract with your cable provider to make sure that people with the plugin have a faster internet connection than those who don’t. Thanks in part to the recent Federal Court case Verizon vs. FCC, cable companies are already brokering these network bandwidth deals without the existence the plugin. But the EME plugin could serve as a perfect technology to use as a basis for detecting which web surfers will get preferential treatment.

I should also point out that thus far, when vendors have tried to push the envelope of DRM enforcement, there’s been significant push-back from the generous open software development community, which steps in and offers technical solutions to sidestep such nonsense. But again, the service contract you have with FooFilmz could change the game. Under your contract, if they detect that you are using such community software, you might find that your service is terminated and that you suddenly owe them a very large fee. And if you refuse to pay this fee which you agreed to in your service contract, you could easily end up facing a collection agency and a black mark on your credit rating.

All of these scenarios might make you think that I’m very firmly in the camp that wants to keep DRM out of the web.

In fact the exact opposite is true.

As I said, I agree with many of the criticisms from the EFF, and now you can see exactly why I agree with them. But the conclusion that many draw from this criticism, that DRM itself must be kept out of the web is wrongheaded. In fact, this notion is the source of the entire problem. Keeping DRM itself out and specifying only a shell like EME insures that someone else will control this technology.

Some have argued that with no DRM available in the web at all, content providers will just have to play nice. However it seems likely that browsers will still support plugins. And it’s certainly true that computers and phones will still support other apps besides the web. If they had to, FooFilmz could just implement their DRM as a separate app. Leaving DRM out of the web standards simply insures that content providers will be free to implement whatever they feel they can get away with.

We would be much better off if the W3C added DRM technology directly to the web standards. A W3C-based DRM would not fall under control of a service contract, and it would be developed by corporate entities who have a broader view of their responsibilities to the consumer. On the other hand, the EME plugin scheme, or really any other separation between the web and DRM, makes it more likely that content providers with a very narrow view of their role would have unprecedented legal opportunities to monitor and control what happens on your computer.

Campaigns against DRM technology are based on high ideals. But as such, they are idealistic. Pragmatically, hard-line arguments against DRM are moving us in exactly the wrong direction. More DRM is coming to our computers no matter what. The only question left is who will control how this technology is implemented and distributed. It may not pass an Open Technology purity test, but our best hope for protection against DRM abuses is a DRM standard that is explicitly described by the W3C and implemented directly in the browser.

About the author:

I have been involved in the web since 1992, when I participated in early web development. My contributions included ideas for the HTML and HTTP standards, development of a text-based browser, creation of one of the earliest award-winning web services (the Hypertext Usenet FAQ archive), creation of the newsgroup comp.infosystems.www, and installation of what might have been the second and third webcams in the world. I currently work as a systems administrator for the Harvard-Smithsonian Center for Astrophysics where my official duties do not involve the development of any new web technologies or standards.

The views and opinions expressed in this article are my own, and do not necessarily reflect the official policy or position of my employer. I have no financial ties or other obligations to any media providers, service providers, or software vendors.

About the banner image:

This image was generated using POV-Ray software, using several different elements. The computer screen is a screen dump of the Gnome desktop from CentOS 6, and Mozilla Firefox version 24.3, displaying web pages from the World Wide Web Consortium website (www.w3.org), and a browser tab with the icon from the Electronic Frontiers Foundation website (www.eff.org). The cracked pattern is derived from an image purchased from Jolin on Dreamstime.com for the creation of this image. All other data elements in the image were created by the author.