
Tell W3C: We don't want the Hollyweb - hosay123
http://www.defectivebydesign.org/no-drm-in-html5?
======
pyalot2
HTML DRM consists of two parts. The first part is EME (extended media
extension) that defines the API how a browser interacts with the CDM (the
actual implementation of the DRM)

The EME is what is being standardized. The CDM is what is up to the platform
provider (or any plug-in provider) to implement, such as Google, Sony,
Microsoft etc.

There are a couple problems with this.

1) The actual DRM functionality will not help keep people from having to
deploy on flash/silverlight because the technology is ladden with proprietary
licenses and NDAs. Ordinary web developers will not be able to make use of
"HTML DRM"

2) Since the CDM requires to do some user specific encryption/restriction, the
CDM will be able to uniquely identify each web user regardless of privacy
settings, cookie blockers etc. You will not have control over what the CDM
does, it will sacrifice your privacy on the web, absolutely. This is a
supercookie on steroids.

3) Due to the CDM having to be provided by third parties as a proprietary
blob, this will make it harder to support the DRM on free/libre/speech/beer
implementations such as Firefox, Linux etc.

4) It will decrease compatibility of video on the web by fracturing already
fractured video support (the codec wars) into the even more fractured DRM
format wars.

5) Because the CDM is a proprietary blob, there is no scrutiny, code review
and control over what it does. Fiascos such as Sonys rootkits and a host of
security exploits in shoddily written proprietary DRM blobs are inevitable.

6) Companies like Google, Microsoft and Apple will use the DRM to gain
leverage over their competitors by intentionally denying them compatibility to
consume videos of services they created.

7) Companies like Netflix, Amazon etc. will use the DRM to gain leverage over
their competitors by denying them the ability to produce videos compatible
with their DRM implementation.

8) And finally DRM will be used by everybody implementing it to rise the
barrier of entry for companies in the entire market, as well as to exclude
innovation.

~~~
bzbarsky
Actually, it's even worse. EME does NOT define how a browser interacts with
the CDM at the moment. That's precisely why some people are objecting to it in
its current state.

EME defines how script in a web page can ask the browser to talk to the CDM.
How the browser actually does that is up to the browser and CDM vendor. There
is no requirement that any CDMs expose any sort of standardized API that
browsers can use to talk to them.

For example, given the current proposal Microsoft can ship a CDM on Windows
that only IE can talk to, Google can ship a CDM that only works in Chrome,
etc.

So in its present state the setup can be trivially used to lock out third-
party (and especially open-source) browsers: just don't let them talk to any
CDMs.

------
Daiz
I'm actually a bit conflicted about support for DRM schemes in HTML5.

I absolute loathe DRM and I wish every damn publisher of every damn type would
come to their senses and actually sell DRM-free digital products.

However, there is one case where some form of "DRM" does make sense, and
that's actual renting - or more specifically, the popular case of "catalog
subscription" (ala Spotify, Netflix and so on). You're clearly renting access
to a catalog of goods in this kind of model, and therefore it makes sense that
you'd want to stop people from permanently acquiring copies in such a
scenario, especially if you're selling actual DRM-free downloads at the same
time (in my ideal digital store where it makes sense they would offer both of
these side-by-side). The catalog subscription model has some clear value to
it, and I'd hate for it to disappear due to "technical unfeasibility".

As such, I would at least prefer for most of the tech / architecture to be
based on HTML5 stuff instead of closed plugins like Flash, Silverlight,
Widevine and so on. I can't really think of a good solution to this, unless
you got the big wigs at various publishing outlets to accept that to do HTML5
streaming, you can only make downloading the rentable versions inconvenient
for regular versions (instead of being able to use a heavy-weight closed DRM
plugin), but I'm afraid that could be quite challenging. It has worked for
Adobe and webfonts, though[1], so maybe there's hope. Forcing HTML5 to be DRM-
free could eventually lead to this direction.

[1] [http://blog.typekit.com/2009/07/21/serving-and-protecting-
fo...](http://blog.typekit.com/2009/07/21/serving-and-protecting-fonts-on-the-
web/)

~~~
MatthewPhillips
> As such, I would at least prefer for most of the tech / architecture to be
> based on HTML5 stuff instead of closed plugins like Flash, Silverlight,
> Widevine and so on.

It's not really based on open stuff. EME isn't DRM, it provides a way to talk
to a DRM service (probably a hardware DRM in most cases). They are creating a
false-sense of "open standards" when this thing still won't work in Linux and
most not-locked-down platforms.

~~~
eridius
Unfortunately, this sort of problem is basically unsolvable for Linux (and
other such "open" platforms). Either you get a proprietary blob that
implements a protection scheme, or you simply don't get the functionality
being promised.

Objecting to efforts to make the situation better for HTML5 experiences on
other platforms because it won't work on Linux is, honestly, pretty selfish.
It _can't_ work on Linux, so you're basically saying since it can't work for
you, it shouldn't work for anyone else too. And that's just dragging down the
state of the web to the lowest common denominator.

~~~
summerdown2
> And that's just dragging down the state of the web to the lowest common
> denominator.

Or up to the state of most openness?

~~~
eridius
Leaving out functionality because Linux can't support it isn't dragging
anything up.

------
hosay123
There's a pretty lively thread over on Reddit:
[http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_...](http://www.reddit.com/r/technology/comments/1asm1x/tell_w3c_we_dont_want_the_hollyweb_drm_in_html5/)

------
chjj
A dark future for HTML. I can't really describe the melancholy I feel when
thinking about this. In 10 years, we'll be reminiscing about how the web was
once an open platform, and we'll kick ourselves for having said at the time,
"I hate DRM...but then again, I do like netflix!"

------
kibwen
The W3C requires at least two implementations before standardization can
happen, right? Theoretically, if both Webkit and Gecko refused to implement it
(or, more diplomatically, "indefinitely deprioritized its implementation"),
would this be DOA?

~~~
azakai
Google and Microsoft are supporters and working on the spec,

[https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-
med...](https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-
media/encrypted-media.html)

Which makes two implementations, I am afraid. Unless we can convince at least
one of those to stop.

~~~
kibwen
Right, but it's Apple, not Google, who holds the keys to Webkit. Not that I
presume that Apple is so benevolent (naive much?), but it wouldn't be the
first time that Apple has outright rejected a Googler's patch (I can't
remember the link now, something about Dart integration). Obviously Google
could always fork the whole project for the sole purpose of implementing DRM,
but what a fiasco that would be!

~~~
azakai
Google doesn't need to officially fork WebKit, it can keep these features in
Chromium and not push them into WebKit - like many other features, including
the one you mentioned (Dart support that Apple rejected). But Chrome is still
a major implementation, it doesn't have to get into WebKit or not (for
standardization purposes that we are discussing here).

~~~
kibwen
Thanks, I wasn't sure what was considered an "implementation" according to the
W3C.

In other news, azakai, you work for Mozilla, correct? Have they issued an
official statement regarding this?

~~~
bzbarsky
Chrome certainly counts as an implementation. You just can't count Chrome and
Safari as two separate implementations if the actual code is in shared WebKit
(but you _can_ count them if the implementation is unshared code, for what
it's worth).

As for Mozilla, no official statement yet, though there have been some public
comments from Robert O'Callahan on the EME spec.

------
tomelders
It's hot HTML's job to fix broken business models.

~~~
zanny
They are being pressured by businesses that want to support those broken
business models like Google. Youtube is a great example - _thousands_ of
people are now living their lives off youtube ad revenue, yet you can get a
simple addon for any browser to download the mp4s.

DRM isn't necessary, old media just wants total control. I seriously think if
we just play the battle of attrition, they will die off soon because they
can't compete in an on-demand get-what-you-want information free era.

------
edgesrazor
If DRM is inevitable, I'd take a properly implemented DRM that's been through
community scrutiny than another Sony rootkit fiasco any time.

~~~
yarrel
How would you like hooks in your web browser for the Sony root kit?

That's what's being proposed at the W3C.

~~~
recoiledsnake
Please, that's hyperbole. Sony rootkit and the DRM present in
Flash/Silverlight are worlds apart.

~~~
ihsw
Actually the description is apt -- the proposal is when a web page loads then
a binary blob (that has OS-level hardware access) will be invoked. It would be
as simple as including a highly-insecure JS file rather than installing a
browser add-on/plug-in/extension/whatever.

The security risks cause me imagine EME news that makes the recent Java 0-day
news frighteningly tame.

------
randall
I think DRM makes sense sadly because otherwise it'd be as simple as 'right
click, save as' and you'd have the contents of a movie. There'd be little
incentive to subscribe to Netflix past a month. Rdio too.

Simple anti-copying provisions that are still defeatable, though through
effort, help incentivize the migration of those channels. And that's what I
really want. I want Hollywood to feel comfortable using the web, because then
more open alternatives will emerge when it's a level playing field. (IE
watching TV is watching the web.)

~~~
darkchasma
No, this doesn't make sense in the slightest.

Fact 1. If I want a movie or song without paying for it, I can get it.

I don't need any more facts, this "solution" doesn't solve fact 1's problem.
It simply breaks the internet. So what part of creating a burden that doesn't
solve a problem make sense?

~~~
recoiledsnake
How does it break the internet anymore than Flash and Silverlight do right
now?

~~~
darkchasma
I have the option to not use flash, or silverlight. When built into a
specification, that option is absent.

~~~
jiggy2011
Not really, you can always disable that option in the browser or use a browser
that doesn't implement that part of the spec.

------
ogmo
I don't know what the solution is here, but I'm worried that if we don't
implement this solution, the web will fall even faster out of favor to native
apps.

I'm talking about mobile.

Right now running flash or silverlight on your desktop is no big deal. This
"solution" is unnecessary. But on mobile we have a real problem: the only way
for anyone to deliver encrypted media is via a native app, which is exactly
what everyone is doing. That comes at the expense of the web. So now we have
an entire generation of users growing up on apps (netflix, hulu, spotify)
because those content licensing deals require DRM.

The desktop is fading. If we want the web to stay relevant as everything moves
to closed ecosystems, this may be a necessary evil, because the web+EME is
infinitely more open than the an iPhone/Android app.

------
jessaustin
There is more information at the EFF page [0] linked in TFA, although not
quite the same "call to action".

[0]: [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)

------
chrischen
Isn't this going to be necessary for a site like YouTube to be able to fully
switch off of Flash?

~~~
schoen
Currently YouTube doesn't require Flash Player for the overwhelming majority
of its videos. It's a bit unclear whether they are still using RTMPE for some
Hollywood stuff (as they were a year or two ago), but if you go to
<https://www.youtube.com/movies> the free movies work perfectly using all free
and open source client software, with no Flash Player.

Most (or all) of YouTube is implemented as FLV or MP4 files delivered over
HTTP. You can watch this in action by using software like youtube-dl.

So apart from the purported, perennial Hollywood threat to boycott things, the
empirical answer with regard to the existing YouTube seems to be no. (Though
maybe there is still some RTMPE lurking somewhere on the site.)

