Back in January, we noted our disappointment with the news that there was a proposal underway to add DRM to HTML5
(called "Encrypted Media Extensions" or EME), backed by Microsoft, Netflix and Google. It was further disappointing to see web creator Tim Berners-Lee defend
the proposal, saying that it was necessary or "people will just go back to using Flash." While the W3C has tried to defend this position by saying that it's not really about DRM
-- and has said it will convene a group to "investigate how to keep the Web maximally open" -- there are still pretty big concerns about this proposal. And it seems quite clear that DRM and locking up content is at the heart of it.
Netflix, perhaps the biggest supporter of the proposal, has noted that it cannot support HTML5 until such support is added
, and made it clear that the DRM part is what matters.
The video content we stream to customers is protected with Digital Rights Management (DRM). This is a requirement for any premium subscription video service. The Encrypted Media Extensions allow us to play protected video content in the browser by providing a standardized way for DRM systems to be used with the media element. For example, the specification identifies an encrypted stream format (Common Encryption for the ISO file format, using AES-128 counter mode) and defines how the DRM license challenge/response is handled, both in ways that are independent of any particular DRM. We need to continue to use DRM whether we use a browser plugin or the HTML5 media element, and these extensions make it possible for us to integrate with a variety of DRM systems that may be used by the browser.
This seems disingenuous. While Netflix and its studio partners may like
DRM, there is no reason that it actually "is a requirement for any premium subscription video service." Lots of professional content and marketplaces work without DRM. Yes, some will copy, but most don't seem to bother. There is no reason that this needs to be built in, and there are many consequences for doing so.
A variety of groups are now speaking out in response to all of this and hitting back against the plan. The EFF's Peter Eckersley and Seth Schoen penned a detailed explanation for why this is a bad idea
The other view has been represented by corporations that have tried to seize control of the Web with their own proprietary extensions. It has been represented by technologies like Adobe's Flash, Microsoft's Silverlight, and pushes by Apple, phone companies, and others toward highly restrictive new platforms. These technologies are intended to be available from a single source or to require permission for new implementations. Whenever these technologies have become popular, they have inflicted damage on the open ecosystems around them. Websites that depend on Flash or Silverlight typically can't be linked to properly, can't be indexed, can't be translated by machine, can't be accessed by users with disabilities, don't work on all devices, and pose security and privacy risks to their users. Platforms and devices that restrict their users inevitably prevent important innovations and hamper marketplace competition.
The EME proposal suffers from many of these problems because it explicitly abdicates responsibilty on compatibility issues and let web sites require specific proprietary third-party software or even special hardware and particular operating systems (all referred to under the generic name "content decryption modules", or CDMs, and none of them specified by EME). EME's authors keep saying that what CDMs are, and do, and where they come from is totally outside of the scope of EME, and that EME itself can't be thought of as DRM because not all CDMs are DRM systems. Yet if the client can't prove it's running the particular proprietary thing the site demands, and hence doesn't have an approved CDM, it can't render the site's content. Perversely, this is exactly the reverse of the reason that the World Wide Web Consortium exists in the first place. W3C is there to create comprehensible, publicly-implementable standards that will guarantee interoperability, not to facilitate an explosion of new mutually-incompatible software and of sites and services that can only be accessed by particular devices or applications. But EME is a proposal to bring exactly that dysfunctional dynamic into HTML5, even risking a return to the "bad old days, before the Web" of deliberately limited interoperability.
In response to all of this the Free Software Foundation
and Defective by Design
launched a campaign against DRM in HTML5, and last week delivered a petition to the W3C against the plan (though you can still sign the petition) and awarded the W3C "the best supporting role in The Hollyweb
The simple fact is that DRM doesn't work and has tremendous unintended consequences that tend to harm legitimate buyers of works. It decreases their value while doing little to stop infringement. Lots of people have realized this for years, but it's true that many in copyright-heavy fields still live under the delusion that DRM actually does something useful. And, it might: the only thing that DRM effectively does is give legacy players a veto right
on new and innovative technologies.
That's really not something the W3C should be supporting -- nor, frankly, is it something that Netflix, Google and Microsoft should be supporting.
Business models for content work just fine without DRM. It's time that the industries producing content finally recognize that. Music has mostly gotten there, but clearly the movie industry is still behind the times on this one. If HTML5 provides enough value without DRM, Netflix and others will figure out how to adopt it eventually. The benefits of using it will just be too powerful to avoid, even if some freak out about the lack of built-in DRM. The industry needs to get over its silly obsession with DRM and to move forward with more compelling technologies and innovation.