A list of the best responses countering the most common reasons advocates of Digital Restrictions Management (DRM) give for why DRM should be included in the HTML5 specification.
In March of this year, the long-time shepherds of the web, the World Wide Web Consortium (W3C), pressured by corporate interests (primarily Netflix, Google, and Microsoft), announced that they would define an Application Programming Interface (API) to aid web-based video services in restricting the rights of users who utilize their services. They claim that this API, called Encrypted Media Extensions (EME), "does not define a content protection or Digital Rights Management system." Technically that's true, but it does "bake-into" the specification the ability to implement DRM natively. As the Electronic Frontier Foundation (EFF) put it, "this is like saying, 'we're not vampires, but we are going to invite them into your house.'"
The announcement raised a hue and cry heard 'round the web, and many freedom advocates (including the EFF and the Free Software Foundation [FSF]) began working to expose the scheme, in an effort to prevent it from happening. Despite this, the founder of the web and director of the W3C, Sir Tim Berners-Lee, added his support for EME earlier this month and gave his reasons for doing so. This precipitated another round of contention between DRM supporters and defenders of freedom.
The following is a list of the claims in favor of codifying DRM on the web and the arguments against them.
DRM protects artists by ensuring that they get paid.
This is laughable on the face of it. DRM protects corporate profits, and thus prolongs corporate control of media production. The corporate system of arts and entertainment production is designed to limit the number of artists who can make a living at their chosen craft. While it's true that some artists (those favored by the corporations) will make money, the vast majority of artists are harmed by the prolongation of this system. There are hundreds of thousands of starving actors, writers, and wannabe filmmakers in the world, with only a few thousand actually making a living in Hollywood, at any given moment.
The W3C has a mandate to provide a "protection" mechanism for content.
It has no such mandate. The W3C's mission is to maintain an "open web." Digital restriction mechanisms work against openness and weaken the W3C's claim to web leadership.
DRM is necessary to "strike a balance" between the rights of content creators and the rights of "consumers."
The language of this claim is silly. Creating a false dichotomy of "creators" and "consumers" harms all users. The label "consumer" is demeaning and implies that some web users are inferior to others. At any rate, it isn't the W3C's place to strike this particular balance, just to ensure openness.
Web DRM will only be used to with video, which must be protected because of the huge cost of producing movies.
First, movie production costs are deliberately inflated to limit the number of people who can produce films and get them into distribution. The Big Six Media corporations own all of the Hollywood studios, all of the distribution companies, and all of the large cinema chains. They work closely with the guilds to force artificially high prices for "talent" and they've created rules that prevent films, that don't use this "talent," from being allowed to be shown in cinemas. Thus preventing most people from being able to afford to make a movie that is allowed into distribution.
Second, once the precedent has been set for video it will be impossible for the W3C to deny other content creators (writers, photographers, musicians, even font makers) the same ability to restrict usage.
If DRM isn't included in the specification then video services (like Netflix) won't be able to operate.
Another claim that is preposterous on the face of it. These companies are already operating using proprietary DRM schemes. This won't change because the web's maintainers don't validate it.
Since some content providers will use some form of DRM it's best that it be standardized in the specification.
The argument here is two-fold: One, if DRM is standardized this will facilitate an open discussion of the standard. True, but an open discussion of something clearly wrong, does not make that thing any more acceptable. And two, if implemented in the specification, DRM will be an interoperable standard. Also true, but this merely serves to make DRM implementation more efficient at it's purported aim: restricting usage. A standards body, putatively commissioned to ensure openness, should have nothing to do with making the means of eliminating openness more efficient.
Including DRM in the standard gives web developers some kind of leverage over proprietary content providers.
Huh? Web developers are only one group harmed by DRM. The main targets of DRM are content customers. This argument appears to be a divide and conquer strategy. They appear to be offering developers a sop in order to get them to betray content customers.
To be universal the Web has got to be open to many different business models.
Allowing businessess or business models that strip other users of their freedoms is not a good way to ensure openness. It's like suggesting that someone should be free to lock-up others and charge a fee for their release in an effort to ensure that, that business model is allowed to propagate.
Is it Time to Fork the Web?
It's obvious from these arguments, and those made by others, that DRM is a net negative and its inclusion in web standards would be disastrous. If the W3C continues on this track, what can be done to remedy the situation?
In an interesting article, columnist Glyn Moody suggests that if the W3C persists in it's folly of pursuing EME, then the web needs to be forked. Among other observations, he notes that the web was forked before by the Web HyperText Application Technology Working Group (WHATWG) over a disagreement about which markup language to use. The W3C wanted to develop and use XHTML while the organizations (primarily Apple, Mozilla, and Opera) behind WHATWG wanted to extend HTML and continue using it. This fork forced the W3C to continue with HTML. Maybe this strategy could work in this case.
Let me know what you think in the comments section below.