back
154 comments
TL;DR:

# Myths

1. that DRM doesn’t work; that it exists to protect creators, but since it is easily cracked and can be worked around, it is largely ineffective and irrelevant

2. that DRM in HTML5 is a necessary compromise to finally bring an end to the proliferation of proprietary browser plugins such as Adobe Flash Player and Micrisoft Silverlight

3. that the web needs DRM in HTML5 in order for Hollywood and other media giants to finally start giving the Web priority over delivering media over traditional means

# Reality

1. DRM is not about protecting copyright. That is a straw man. DRM is about limiting the functionality of devices and selling features back in the form of services. (https://plus.google.com/107429617152575897589/posts/iPmatxBY...)

2. DRM in HTML5 doesn’t obviate proprietary browser plug-ins, it encourages them. (https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-d...)

3. The Web doesn’t need big media; big media needs the Web. (http://blogs.computerworlduk.com/open-enterprise/2013/02/bbc...)

# So sign the petition

http://www.defectivebydesign.org/no-drm-in-html5

Honest question - why is having a framework that allows for others to provide some form of DRM different from any other plugin system that exists currently?
Just to nitpick, the post you linked to by Ian Hickson does illustrate how DRM has been used to limit functionality, but both your post and his doesn't explain why "copyright protection" is a straw-man? I don't believe it is a fair argument to say that copyright protection and whatever functionality they enforce or prevent by use of DRM are mutually exclusive.

Although, I do see the point that some parties could hide behind the "We need DRM to protect our copyright\prevent piracy" flag and instead use it to lock-in consumers and build a walled-garden.

Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards.

There is nothing to be won by resisting hooks for DRM in the browser however appealing it seems to take a principled stand. The content suppliers will gleefully go with native apps, flash, silverlight, even Emscripten-cross-compiled codecs. With content consumption going mobile, the push for native apps is even stronger.

Really, all you'll do by resisting this, is teach the majority of consumers who don't know any better that the Web sucks, and all of the enjoyable things they want are to be found on iOS or other proprietary locked down distribution platforms. That if you want apps that deliver the stuff you are interested in, you have to look outside the web.

Back when Chrome proposed dropping H264 support, I was infuriated, even though I fully support WebM as the mandatory to implement codec. I don't think "purity" really serves the platform, flexibility does, and the best way to register you don't like DRM is to simply stop consuming any and all media which uses it. Not just Web media, but all media that's DRMed.

A DRM free HTML5 spec is not going to force Hollywood to allow you to play Games of Thrones on your open source Linux browser.

Emscripten cross-compiled codecs are better than black-box, closed source DRM codecs built into partially or fully proprietary browsers like Chrome and Internet Explorer. Do you really think a DRM plugin would ever work in Firefox or Chromium?

If they really want to ship DRM, they can do it using the same tools everyone else uses, without special monopoly-preserving treatment or 'protected media paths' or kernel hooks or tailor-made plugin APIs. Big Media is no more deserving of special treatment or protection than any of the other industries that want to build apps on the web, and the idea of dedicating time and resources to babysitting a dying industry when there are REAL PROBLEMS that could be solved instead is ridiculous.

The problem is that they know as well as we do that DRM doesn't work, and DRM especially doesn't work without the aid of special kernel/software hooks like the Windows PMP and OS X's anti-debugging protections. This is why they're so desperate to get DRM baked into the HTML5 spec and baked into browsers. The reality is though, adding DRM to browsers produces no value for anyone other than the lazy big media companies that can't adapt to the modern world. It doesn't produce value for consumers, it doesn't produce value for developers outside of big media, and it doesn't produce value for the people who actually produce video and audio content. All it does is enrich IP lawyers and executives.

Furthermore, the idea that lacking DRM somehow makes the web 'suck' is preposterous. Do you know anything about the web? If the web sucks that's entirely separate from whether or not it can play encrypted video. If it sucks, it's because browsers are full of security problems, websites are poorly designed and poorly engineered, web accessibility for the disabled is poor, web performance is miserable in many markets, and ISPs like Comcast continually abuse their monopoly status to overcharge and under-deliver. Encrypted video is so far from a real-world concern or priority for ordinary people that suggesting it's somehow NECESSARY for the web to not suck makes you look absolutely raving insane.

No, but at least it won't be polluted by technically ineffective and poorly justified nonsense put there to assuage the fears of a handful of ignorant content executives.

It's just dumb. DRM is just dumb. It doesn't work for anything but the most naive case. It won't prevent distribution of "pirated" content, ever.

I'm not asking for a DRM-free world, but I still hold out hope that if we continue to push back forcefully enough we might at least get rid of some of the abject nonsense being inflicted on us. Seriously (and without getting into any details), look at the middleware layers of a consumer OS some day to see all the spots where DRM has its greasy fingers. Must it be in HTML too?

Consumers don't care about implementation, they only care about the content, and until they do, suppliers of content hold all the cards.

In this case, forget consumers. Once in a while, something is more important than appeasing the masses.

A DRM free HTML5 spec is not going to force Hollywood to allow you to play Games of Thrones on your open source Linux browser.

Neither is a DRM-infested spec. Instead, you have uninformed consumers Googling for "how can I watch Game of Thrones Season 2 Episode 3 online for free", getting infested with malware, but still watching the show for free.

>A DRM free HTML5 spec is not going to force Hollywood to allow you to play Games of Thrones on your open source Linux browser.

A DRM laden HTML5 spec will mean "my open source Linux browser" will not be able to support the entire HTML5 spec. This is far more unacceptable to me.

Consumers don't even care about content. They care about convienence. It trumps everything. Video on the web is convenient enough that you will be able to watch the TV show du jour through it, and if there is no DRM support in browsers it won't be DRMed.

Pirates are becoming increasingly professional and Hollywood gets to decide if they will spend their legal advantage on defending incompatibility schemes or making money, unless the browsers help them out with the former.

A DRM free HTML5 spec won't have any effect on you being able to watch Game of Thrones on your open source Linux browser aside from maybe giving you an opportunity to pay HBO for it.

> The content suppliers will gleefully go with native apps, flash, silverlight, even Emscripten-cross-compiled codecs.

At least a compiled-to-JS codec or encryption module would be JS, so it would run on the web everywhere. Unlike Flash, Silverlight, and also the EME stuff as mentioned in the article, all of which require proprietary code, and so will only run in some browsers and some platforms.

The web doesn't need DRM any more than broadcast TV needed the broadcast flag. Content producers said that the broadcast flag was necessary, and that without it they wouldn't allow their content to be broadcast.

In that case, there was a bunch of push-back against the broadcast flag, the proposal died, and now all kinds of stuff gets broadcast in the clear. When push came to shove, the content producers didn't actually need the broadcast flag, and their business models still work without it just as well as they did before.

The same needs to happen with the EME proposal; people who care about this kind of thing need to push back and kill it just like with the broadcast flag.

Then they shouldn't be surprised when their content gets pirated. They themselves are to blame for making access to their content more difficult. I bet netflix would make double if they weren't platform limited by DRM implementations.

Most Internet users don't care where their browser vendor leads them. Like you said, consumers are sheep.

>The content suppliers will gleefully go with native apps, flash, silverlight, even Emscripten-cross-compiled codecs. With content consumption going mobile, the push for native apps is even stronger.

What's wrong with that? Keep the junk out of the browser!

>Consumers don't care about implementation, they only care about the content

Therefore, it is the moral duty of those behind html5 to make sure that interests of consumers are not compromised.

Then consumers should revolt, because all this really does is limit on how many devices they can play the content on. And I think everyone hates that.
Problem is that EMA (aka DRM in browser) will discriminate between open source and proprietary browsers, giving latter a bigger edge (propietary plugins, could in theory be bypassed).
One should never deal with the bad guys.
I can't believe that DRM is even on the table. It's ONLY purpose is to prevent third parties from accessing content, which is pretty much the antithesis of the web and open standards.

For me, what it all comes down to is this: HTML5 is supposed to have open standards, so if I implement those standards' specifications in my own web browser, I expect to be able to view and use websites that are HTML5-conformant.

If DRM goes through, this is what will probably happen: Internet Explorer and Google Chrome (two closed source browsers) will definitely implement it. Opera might implement it (who really knows what they'll do?). Chromium and Firefox probably won't implement it. DRM content will likely only be viewable on those two browsers, and only on a supported platform. If you use Firefox on Linux Mint, you're SOL. If you developed your own web browser, you're SOL. Even if you use Firefox on some closed source operating system like OS X, you're SOL.

My take is that Google in particular likes this development (though are probably trying to stay away from it publicly for political reasons) because it allows them to easily (ie. with studio blessing) pilot monetizing their vast YouTube-watching userbase by offering paid content services and user profiling far beyond what is available on cable networks (eg. by selling 'anonymized' matches of consumer viewing behaviour in conjunction with email, location, sleeping-schedule as determined by a cross-section of Google services, etc.). Existing Google projects and their recent significant investment in video (patents, new LA offices, Android 'Smart TVs', ChromeOS Google Fiber) all look like they will benefit from this type of development. With all due respect to people who work at Google, please consider protesting internally in parallel to this public effort, or leaving.
I think Google has a checklist of Chromebook deficiencies and they are just checking Netflix off by doing this. That it will ultimately make it a little easier to do things like you suggest is just an added bonus.
Back in the real world, the web is not inevitable. The alternative to HTML5 DRM is for vendors to turn away from the web and HTML5 altogether.

The web is still open by default, versus other platforms being closed by default. The best architecture is to support fine-grained plugins with well-defined semantics than just some big black box <object> element that could be running anything.

Indeed. Vendors won't be forced to make a HTML5 version - on the desktop the formula that's allowed them to provide browser plugins hasn't changed, and on mobile they're already making an iOS app and an Android app because today, apps provide a better experience than websites anyway. Sure, your niche mobile platform will be left without any way to experience the content, whereas if not for DRM they could provide an HTML5 player as a least common denominator, but it probably doesn't have enough users for them to terribly mind.

That's not to say that HTML5 EME addresses this, just that nobody is going to be forced to use HTML5 in any case. (It's possible that a proprietary but common CDM standard could be created to allow the least common denominator on mobile, since the regular route of browser plugins won't work there, but that would be its own can of worms.)

What is the complaint. It isn't clearly summed up here.

Noone will force you to use DRM on your website. Noone will force you to browse websites that use DRM.

What do you care what others choose to do with their sites and content, unless you believe you have the right to access everything everyone creates, in an unrestricted fashion, for free, in perpetuity.

The primary complaint is that, for the first time since the <embed> tag, W3C is creating an API that by design won't work on some systems.

If that isn't automatically bad to you on the face of it (it is to me, I want to be able to use random-OS-of-the-month as long as it has a good browser), you create a scenario where those on top stay on top by the grace of already being on top.

> Noone will force you to browse websites that use DRM.

If you want to stay legal and watch their content, you bet they will. Major networks will require their distributors to use this DRM. Sure, you don't have to use their content, but the point of fighting it is that we want to use their content and are trying to prevent them from this step.

One complaint is that as the spec stands it's impossible to interoperably implement in browsers just by implementing the spec. You also have to go and do some out-of-band agreements which may or may not happen.

In other words, it's a "standard" that deliberately sets up a situation where behavior across browsers will differ.

Suggestions that the interface between the CDM and the browser actually be standardized have been made ... and ignored.

This is because all you dummies were too busy lauding Google's services and nobody notices how "evil" they are.

This came as a proposal from Google. It was tested in Chromium first. The DRM is essential for their "World-saving" ChromeOS that nobody really cares about.

Yep, if Google implements DRM, no one can stop it. The web is a platform for big software vendors after all, because no other player can virtually implement and maintain this enlarged platform and browser runtimes. Evil browser vendors will take over the role of evil plug-in vendors. Game over.

I predicted this catastrophe when everyone was attacking Flash.

DRM is based on obfuscation at the core. How would this ever work with open source browsers?
It wouldn't. The explicitly stated plan from the people who originated this proposal involves proprietary browser plugins.
What's the solution? Forking html?
Wait, so the W3C is actually letting this happen? How the mighty have fallen.
It appears that the spec for EME doesn't provide a mechanism to reliably detect decryption failure, this will be inconvenient to end users. This could be alleviated by adding a mandatory tag that includes a hash of the decrypted video for verification purposes, to be tested by the client while streaming the content. If the hash is missing or incorrect the media must not play.

The Tiger Tree Hash system is already being deployed for this purpose in other systems.

NetFlix is one of the companies pushing this.
The W3C must ultimately do what it thinks is in the web's best interest. Not the interest of big media companies, or the interest of those against DRM. If they implement a system by which DRM can be reasonably added to the spec to bring those users and companies into the fold, I don't think I'd have much to call them out on, even though I don't like DRM. That bone is to be picked with the media companies themselves.
Consumers don't care about DRM or No-DRM they care about convenience. Large players do not care about technology either they just want control over their market. Under this circumstances the question is what stand should W3C take ?

Should they try to keep web as open as possible or should they play to the tunes of Google and Microsoft and introduce features that benefit them.

As I see it, web standards should be as open as possible.

Why are optional WebIDL bindings really any different than NPAPI bindings? foo.getDRMStream() is bad, but document.getElementById("drmpluginelement").getDRMStream() is somehow fundamentally better?

Seems like mostly a distinction without a practical difference. Some browser platforms won't be able to ship with the bindings for this, likely the same browser platforms that can't ship the NPAPI plugin.

Whether or not Encrypted Media Extensions(EME) is included in HTML5 SHOULD NOT be construed as a referendum on DRM. The HTML5 standard is not the place to determine if something is ethically/morally good, advancing humankind, or will even work.

If some orgs or people want a means to retrict the playing of media in HTML5 by downloading keys from a license server then so be it. The HTML5 standard should be as inclusive as it needs to be to represent the needs of all parties. If enough parties desire this functionality then who are we to say they cannot or should not have it.

I can't read the article, probably a HN DOS.

However, I really can't see the point of doing DRM in html5, it will just result in browsers becoming the equivalent of the evil plugin everyone hates(only certain browsers/platforms will be able to run the content).

Why not just leave html5 video open, and let those who wish to distribute DRM'd content build their own client-side players for the OS's they wish to support. Or let them build apps on top of Adobe AIR or Silverlight out of browser.

Just wondering, is there any provision in any OSS license (or scope to add one) that prevents the code being used in any DRM software or firmware?

I know it wouldn't act retrospectively, and I'm not sure if any OSS libraries are actually in use in any DRM software, but it may at least set a trend. I'd love to see the next open source game changer be open to all except those who oppose openness :-)

I don't see the big deal.

Right now DRM depends on proprietary plug-ins. If this is allowed in HTML5, DRM will still depend on proprietary plug-ins.

What is different?

edit: also, browser vendors don't have to implement it if they don't want to. Really, I don't like this DRM thing that much, but I am kind of indifferent to this.

I think it's good.

Once it's implemented, you can just patch Firefox or Chromium to dump the unencrypted video stream before sending it to the H.264/WebM codec, and you get an universal method to trivially liberate all "DRM"-encumbered web content.

Site is incredibly slow (I see Wordpress is doing its job again). If it goes down, here is a copy of the html: http://pastebin.com/raw.php?i=fnutc6A3
Here's a mirror (I think) of the post:

http://permalink.gmane.org/gmane.org.freeculture.discuss/681...

Forgive my lack of knowledge, but does this mean that in future motherboards or CPUs could be sold that lock out non DRM files, or something in our hardware like that?
Alas, article does not explain where the betrayal is. Or even what the author considers "web". Someone is too self-centric and has no idea what an average web user is and what he wants.

Honestly, rants like this sound a lot like "allowing same-sex marriages will destroy the sanctity of marriage" and alike. How exactly?

Will the ability to have DRM'ed content in HTML suddenly shut down "the open web"? No.

DRM is bad.
EME =/= DRM.