
The W3C's plan for DRM in HTML5 is a betrayal for all web users - riordan
http://freeculture.org/blog/2013/04/23/dont-let-the-myths-fool-you-the-w3cs-plan-for-drm-in-html5-is-a-betrayal-to-all-web-users/
======
kxra
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...](https://plus.google.com/107429617152575897589/posts/iPmatxBYuj2))

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...](https://www.eff.org/deeplinks/2013/03/defend-open-web-keep-drm-
out-w3c-standards))

3\. The Web doesn’t need big media; big media needs the Web.
([http://blogs.computerworlduk.com/open-
enterprise/2013/02/bbc...](http://blogs.computerworlduk.com/open-
enterprise/2013/02/bbc-attacks-the-open-web-gnulinux-in-danger/index.htm))

# __So sign the petition __

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

~~~
cleverjake
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?

~~~
MatthewPhillips
Different, how? It's different in several ways. For one it's not a plugin
framework, it's a DRM plugin framework; meaning it's designed specifically
with 1 use case in mind. Secondly its expressed intent is to take away
functionality; I'm not aware of any other instance where a web API is created
to disable features of a user's computer. I'm sure we can rattle off more ways
that it is different, but I'm not sure what you're looking for here.

~~~
cleverjake
>> For one it's not a plugin framework, it's a DRM plugin framework;

A DRM plugin framework is by definition a plugin framework. I relly don't want
DRM in html either, but I have a hard time finding logical arguments against
it, and I don't see how this is a good one. If you could further your point, I
would love to hear it.

>> Secondly its expressed intent is to take away functionality

Take away what functionality? The ability to download audio/video? Again,
playing the devil's advocate, I would imagine a vast majority of the content
that would be streamed using the DRM encodes would not be streamed using the
video element currently - it would be streamed over flash/silverlight, etc
(think netflix, hulu). If that is the case, what is it we are losing?

>> I'm not aware of any other instance where a web API is created to disable
features of a user's computer

To be fair, this isn't. EME is just a way for people to create addons that
leverage native encryption. The same is true of the current plugin system.

>>I'm sure we can rattle off more ways that it is different, but I'm not sure
what you're looking for here. I am looking for logical reasons to say why
adding EME hurts the open web so when I get into arguments I have better
reasons other than 'I hate it'

~~~
yarrel
A DRM API in HTML5 harms users by legitimizing and enabling restrictive
technology under the banner of the free and open web, with all the practical
harm (lack of control, reduced bargaining power, security issues) that loss of
freedom entails.

If the framework is no different from existing frameworks, why do we need it?

~~~
cleverjake
>>A DRM API in HTML5 harms users by legitimizing and enabling restrictive
technology under the banner of the free and open web, with all the practical
harm (lack of control, reduced bargaining power, security issues) that loss of
freedom entails.

In whose eyes does it legitimize it? Are you saying someone will be convinced
that DRM is ok because it is in a web browser?

>>If the framework is no different from existing frameworks, why do we need
it?

Because it is different. Native solutions are more likely to be faster and
more secure than external plugins.

------
cromwellian
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.

~~~
kevingadd
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.

~~~
kvb
How can the "lazy big media companies" adapt? What's the DRM-free business
model that would allow them to produce the blockbuster movies that are
apparently still quite popular with the public?

~~~
kevingadd
You're assuming that blockbuster movies are a business model that will
continue to work in the future. That's highly questionable - in the game
industry developers and publishers are being forced to accept the possibility
that the blockbuster model is no longer going to be a reliable source of
revenue or the right way to develop things. I won't claim to know enough to
say whether this is true for film or television, but it is at least reasonable
to ask 'maybe the reason these products require fragile, overcomplicated DRM
solutions is because we're building the wrong products'.

I hate to use this analogy, but this really seems like a potential buggy-whip
situation: It's quite possible that the content Big Media is producing is
simply no longer relevant, even if the lack of relevance is due to changes in
how people consume media and not because people are somehow no longer
interested in explosions or big-name actors.

~~~
cromwellian
Possible, I'll buy that. Maybe YouTube will one day kill off the major
networks and studios, and production will get cheap, just like startups have
gotten a lot cheaper to run with EC2.

But I'm still going to go see Iron Man 3 and Star Trek Into Darkness and I'm
not holding my breath that a non-DRM version will be cooked up outside the
blockbuster system anytime soon. :)

~~~
kybernetikos
Is there any doubt that Star Trek Into Darkness could raise an unspeakably
large amount of money on a crowdfunding platform?

It looked very much like fans of Firefly would have been able to raise enough
to continue making the series but they were given not very subtle hints than
getting involved in a crowdfunded production would have been bad for the
showbiz careers of those involved.

------
shitlord
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.

------
contingencies
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.

~~~
MatthewPhillips
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.

------
mmahemoff
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.

~~~
comex
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.)

------
whiddershins
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.

~~~
Laremere
> 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.

~~~
ndesaulniers
Excellent point. We take away the previous held concept of possessing media,
making money by renting it to you repeatedly, then lobbying Washington with
the profits to make it illegal to not play by our rules, and you're addicted
so you can't break the habit.

~~~
whiddershins
What? Addicted? Really?

------
campuscodi
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.

~~~
NinjaWarrior
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.

------
nwh
DRM is based on obfuscation at the core. How would this ever work with open
source browsers?

~~~
JoshTriplett
It wouldn't. The explicitly stated plan from the people who originated this
proposal involves proprietary browser plugins.

~~~
MatthewPhillips
Not necessarily browser plugins. Could be browser or OS or hardware.. Each
website has control over what DRM it accepts, which leads to a world where
hardware eventually becomes the requirement.

~~~
azakai
Regardless if it's technically a plugin or part of the OS accessed through a
bridge, or anything else, EME fundamentally depends on proprietary code (and
that code will not be part of any open source browser).

------
rocky1138
What's the solution? Forking html?

~~~
Millennium
The solution is waiting it out. They caved on music; they will cave here too.
All that is required is patience: something that is admittedly rare in the
tech world, but it works.

~~~
mlinksva
Not at all clear to me that waiting it out is a winning strategy. There is no
deterministic path for other media to follow music away from DRM, and indeed
there is a threat that a faux-standard as proposed will mean that DRM becomes
the expectation and demand of/by record companies, again.

------
verandaguy
Wait, so the W3C is actually letting this happen? How the mighty have fallen.

~~~
dthunt
It's still a proposal at this point. It should be opposed, obviously.

------
bcoates
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.

------
ricardobeat
NetFlix is one of the companies pushing this.

~~~
shmerl
Also, note that Google is one of those companies as well. They forgot about
"not being evil" with this one.

------
cantankerous
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.

~~~
bzbarsky
The W3C will ultimately do what is in its members' best interests: it's an
industry consortium.

Its members are whoever paid the membership fee.

There are plenty of instances of the W3C doing things that its members asked
for that were either irrelevant to the web or detrimental to it, because there
is no "W3C" per se when it comes to getting stuff done, just the set of
members.

------
tn13
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.

------
cromwellian
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.

~~~
TazeTSchnitzel
Well, we can at least not make the situation worse. We already have NPAPI,
let's not add another proprietary plugin API.

------
smutticus
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.

------
rjempson
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.

------
Intermernet
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 :-)

~~~
zb
No, by definition, since that would no longer be Open Source.

<http://opensource.org/osd>

------
runn1ng
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.

~~~
AnthonyMouse
>What is different?

That's kind of the point. The people promoting this seem to be
misunderstanding what the result would be. It would in no way reduce the
amount of poorly written proprietary code full of security vulnerabilities. It
would just move it around a little.

But in the meantime it breaks the web. Even if you support the new HTML5 spec,
you can't _actually_ support it without having the proprietary black box
necessary to make it work. You break the ability of the web to be platform
agnostic. For the web to work at all you'll soon end up needing the black box,
because once it's there sites will use it. So if the black box doesn't exist
for your platform or you want to create a new platform then you'll be locked
out of most of the web. How can that be acceptable?

~~~
runn1ng
But it is NOT platform agnostic anyway.

That is my point. Right now, you have to have certain plugins to see certain
sites. At _this very moment_.

So according to the new specification, there won't be <embed> with a specified
plugin in TYPE attribute (or something similar in <object>), but probably
something else and similar with EME. Why does it matter so much?

If this is not passed, evil corporations will use <embed> and <object> again.
If this is and browsers will support it, they will use EME instead.

Again, I can't see any big change.

~~~
AnthonyMouse
We should oppose the old plug-ins just like we do the new ones. The big change
is that the old plug-ins have been starting to die out. People originally used
Flash because it was the best way to play video in a web browser, not because
it had DRM. As improvements to HTML eliminate the non-DRM need for such plug-
ins, the plug-ins start to go away. Apple got away with prohibiting Flash on
iOS because it became possible to use Youtube et al without it. We ought to be
encouraging the legacy plug-ins to finish going away, not reintroducing new
ones.

------
blust
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.

------
lucb1e
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>

------
mmastrac
Here's a mirror (I think) of the post:

[http://permalink.gmane.org/gmane.org.freeculture.discuss/681...](http://permalink.gmane.org/gmane.org.freeculture.discuss/6814)

------
alan_cx
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?

------
rimantas
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.

------
snambi
DRM is bad.

------
coherentpony
EME =/= DRM.

~~~
ndesaulniers
Technically speaking, you're right. EME is not DRM, it's a facilitator. From
the spec "facilitating the development of robust playback applications
supporting a range of content decryption and protection technologies [read
DRM]." I may have inserted that last part. Using a new acronym affords
Hollywood more time to get implementations in major browsers while we try to
raise awareness. Most consumers don't know about DRM, fewer still about EME!

