

Requirements for DRM in HTML are confidential - duncan_bayne
http://lists.w3.org/Archives/Public/public-restrictedmedia/2014Jan/0060.html
http:&#x2F;&#x2F;lists.w3.org&#x2F;Archives&#x2F;Public&#x2F;public-restrictedmedia&#x2F;2014Jan&#x2F;0060.html
======
Nursie
Great. DRM. The best example of shooting yourself in the foot ever.

Give customers encrypted content and the keys, try to prevent them from freely
using the two together, undermine copyright fair use and first sale doctrines
as you go along.

Intended effect - No Piracy

Actual effect - Paying customers get crippled products, pirates carry on
regardless

It's crazy. And the more they try to lock it down the worse their products
become and the better piracy looks in comparison. Pirates don't only beat the
legit industry on price, they beat them on quality and availability. How can
the industry allow this to stand? Let alone continue down the same path with
their fingers in their ears shouting LALALALALALA I CAN'T HEAR YOU!?!

~~~
bitwize
Let me tell you how things work in the real world.

When the people with money say "we want this", you don't argue. It doesn't
matter if it's technically infeasible. It doesn't matter if it won't have the
intended effect. When the people with money want something, YOU GIVE IT TO
THEM. And let them deal with the consequences. Otherwise, you won't get the
business, and life can otherwise be made very, very difficult for you.

The people who run Hollywood have lots of money to play with. The people who
run the Web companies want a piece of that action. Hollywood says "no can do
unless we have reasonable assurance that due diligence has been done to
prevent piracy -- that means DRM." DRM isn't really about being effective --
it's about providing a nominal barrier to piracy that will dissuade casual
pirates outright, and in the case of serious pirates, provides something that
can be "broken" so the studios can go after the person who broke it with civil
and criminal copyright infringement claims. Now you know why the DMCA
anticircumvention provisions exist: so the copyright industry can do with the
law what DRM alone couldn't do.

So the Web either gets DRM, or Hollywood makes content available on
proprietary platforms that provide it.

Money shapes reality in this world.

~~~
onli
Let me tell you something about the state of the real world: The content
Hollywood produces is already fully available on the Web. They try to fight
that, but they lose. So the w3c is in no position where it is necessary to
accommodate them to get their content. Besides, for the w3c, where is the
business incentive, where is the money involved?

~~~
flavor8
> The content Hollywood produces is already fully available on the Web.

For people willing to pirate, it, yes. However, it's far less convenient to
pirate movies and get them to your big screen TV than it was to use napster
and listen to songs on your mp3 player. On the flip side, Netflix (i.e.
content with DRM) accounts for roughly 1/3 of nightly internet traffic in the
US. DRM facilitates consumer access to restricted content.

> Besides, for the w3c, where is the business incentive, where is the money
> involved?

The w3c is primarily an industry group. The players pushing DRM in HTML5 are
Google, Netflix and Microsoft, all of whom have a business interest in being
able to stream content via browsers.

~~~
marcosdumay
> For people willing to pirate, it, yes.

What good is protection against piracy from people not willing to pirate?

And no, pirated content is far more convenient than DRMed content. DRM can
only reduce the conveninence, not increase.

~~~
flavor8
> What good is protection against piracy from people not willing to pirate?

It's about business. Protection that works for 99.5% of the population is good
enough for the old content industries. Netflix couldn't exist in its current
form without DRM -- Netflix does not succeed because of novel technologies,
but rather because of successful content licensing.

To be clear I'm not a fan of DRM, especially not when it's baked into the HTML
standard.

> And no, pirated content is far more convenient than DRMed content.

I didn't say that - you're arguing against a position I didn't state.

------
simonsarris
I suppose that the title assertion is to be expected. DRM only works if you
don't know how it works.

~~~

I'm not sure I see anything wrong with DRM _per se_ (this could be my fever
talking), there are probably good uses I'm too dim to think about, but I do
think it's unnecessary as part of the HTML specification.

There's no industry or company that has switched to DRM-free content, that I
know of, that has failed or suffered because of it:

* Music is largely available DRM-free now, thanks to Amazon's MP3 store (at the least, I'm sure there are others)

* For games, Steam makes it easy to avoid SecuROM Hell

* Despite DRM, all of Netflix's original series House of Cards was available on The Pirate Bay within hours of release. This doesn't seem to hurt Netflix's wish to create more content, or police it more heavy-handedly. (Maybe they would if they could)

For that matter, I think in the modern case every single time a business went
DRM free it turned out OK. Isn't that right? In all modern cases, maybe after
2006-ish, DRM-free businesses were accompanied with an easy way to get the
content online, and sales did not seem to suffer because at the end of the day
piracy can appear (or be) shady and people (rightfully) don't trust shady
websites, even The Pirate Bay with all of its popups.

I wish we had better numbers. I would like to see a real analysis on all the
reasons people don't pirate and instead buy on Steam. I wish there was a good
way to convince media businesses at large.

But I guess this is all water under the bridge, and I'm preaching to the
choir.

~~~
shmerl
Steam can't be considered DRM free in many cases, for example because they
don't let you backing up installers / packages, so if the service closes down
you lose your collection. The only completely DRM-free gaming distributor is
GOG. Humble Bundle and Desura are mixed.

You are right in general though. Going DRM free not only won't hurt any
publisher, it will only gain respect from customers and will improve the
quality of their products in a sense of improved usability, because any DRM
means a crippled product (i.e. limited platforms availability, inability to
make backups and etc. and etc.).

The problem is, that most legacy publishers are rarely customer focused and
think that DRM helps their profits. And unprincipled distributors like Netflix
are ready to oblige. But the irony is, those publishers only hurt themselves
by continuing using DRM. It's mostly innovative publishers, or self published
studios (and crowdfunded projects) that have common sense and avoid using DRM.
Luckily some distributors are also principled enough to reject DRMed products
from publishers. But such are a minority still.

~~~
fafner
And GOG refuses to add GNU/Linux support. Considering that many GOG games run
in DOSEmu anyway and some come with native Linux support this is not really
understandable.

~~~
teacup50
Shipping binary software for Linux is like playing a never-ending game of
Space Invaders.

GOG's position is totally understandable.

~~~
shmerl
No, it's not. Their position is (at least from their last status update): "we
are trying to come up with a long term support methodology, and didn't find
one yet". It takes them more than a year to design it. It doesn't sound
reasonable to me.

~~~
pquerna
Shipping binaries on Linux is nearly impossible on a long term support basis.

FatELF would of addressed at least some of these problems, but was largely
rejected by the larger community of people not shipping proprietary products
on Linux: [https://icculus.org/fatelf/](https://icculus.org/fatelf/)

~~~
derefr
Might Docker containers be a valid solution to this? Shipping old games is a
sorta-kinda-similar problem to shipping frozen versions of web-apps.

~~~
shmerl
That can work probably, since Docker claims that it doesn't impose big
overhead, so it can be suitable for gaming.

~~~
techdragon
You would probably find there are performance penalties in areas Docker don't
really bother benchmarking or even talking about since they don't align to the
design goals. I've only seen some fairly rudimentary demonstrations of VNC and
X over the Network for isolating GUI apps in Docker.

~~~
shykes
Docker author here. I really doubt performance would be a problem. Namespaced
linux processes access devices the same way every other process does: by
getting a file descriptor to it and making syscalls against that. What we need
to figure out is a portable way for a docker container to declare "I need
access to the following devices". I would love to work with anyone interested
to add that to the docker APIs for 1.0. I think long-term stable binary
delivery is an important thing to do and I would like to help.

Ping me at solomon@docker.com about this anytime.

------
rlx0x
This is all so ridiculous, rtmp for instance is as secure a DRM as its ever
gonna get and that never stopped me from downloading a stream. Even things
like HDMI/HDCP is broken beyond repair. And all of this should justify
damaging the w3c reputation forever, what are they thinking?!

This whole concept of DRM is just idiotic, its enough if one guy breaks the
DRM and releases it. Why should I even bother booting a propertary OS
(windows) and buying a stream everytime I want to watch something if I can
just download a release and watch it, and its not like they can do anything
against that either.

Why should I bother and buy HDCP capable new hardware, bother with proprietary
NSA-compliant US software I much rather buy the DVD, trash it and just
download it in a open and free format (I don't even bother with ripping (and
breaking CSS) anymore).

~~~
mcot2
I don't care how it gets done, but if we need this to finally kill off flash
than I am for it. This problem is solved technically so let's just get it
done. Yes, every DRM will eventually be broken, but at least it satisfies the
executives enough, so what's the problem?

I don't understand why purists on the email list end up holding up something
that will ultimately be a positive thing from a number of perspectives.
Security, battery life, and script-able/touch friendly controls.

~~~
nitrogen
We want to kill Flash because it's proprietary and closed source (just like
HTML DRM). Replacing Flash, which at least works on Linux, Windows, and Mac,
with platform-specific DRM, is a huge step _backward_ for the web.

~~~
mcot2
Not really. I want to get rid of Flash because of security, battery
life/performance and because it is not touch friendly.

~~~
espadrine
Security, battery life and touch-friendliness aren't necessarily the most
renown features of a DRM binary blob.

Communicating with the blob in an open-source project will be particularly
fun.

------
Daiz
This should really be at the top of every HTML DRM discussion:

HTML DRM will not give you plugin-free or standardized playback. It will
simply replace Flash/Silverlight with multiple custom and proprietary DRM
black boxes that will likely have even worse cross-platform compatibility than
the existing solutions. In other words, giving in to HTML DRM will only make
the situation _worse_.

Some vendors will keep pushing for it, but at the very least we should not
officially sanction what they are doing.

~~~
talmand
But that's the solution you would want, a plugin. That way the DRM is not part
of every browser being made, it's an add-on that individuals can decline to
install. Content providers want this and they will eventually get it, one way
or another. If they don't get their plugin then they'll go with their deep
pockets to demand laws that require all browsers to have this tech by default,
without your choice. Which would lead to browsers either complying or removing
the media elements.

~~~
fafner
What you are saying is just ridiculous. Adding DRM to HTML5 will destroy the
open web and not preserve it.

First of all the DRM proposal does NOT talk about plugins. The DRM support
won't be plugins. Microsoft already implements the spec in their latest IE and
it doesn't work with plugins at all. They ship Microsoft's DRM technology as
the one and only available DRM. Which is perfectly fine according to the spec.

So do you understand? This moves DRM into the browser and not into a plugin.
The plugin thing was what we had with Flash and Silverlight. Those things were
plugins which are not part of the browser (well except Google decided to make
Flash part of Chrome).

There could be no law to force browser vendors to ship DRM. It would not be
legally possible. It is silly to think so. And if it gets proposed we can
fight it then. We don't have to bend over backwards now to take the DRM
bullshit that vile companies like Google are proposing.

If content providers want DRM then they can develop their own crappy DRM
plugins and applications. But they should under no circumstances be allowed to
ruin the open web.

~~~
talmand
That's the initial proposal that I was aware of so if it's changed since then
I suppose I'm no longer up to date. That's fine.

But it is not ridiculous thought for this to plugin based, especially if your
only example is Microsoft. I suppose Apple and Google will build it into their
browsers since they support this. I suppose it's ridiculous that I said it but
it's the solution you support by your very own words? If the content providers
make their own crappy plugins the browser needs a way to communicate to that
crappy plugin, which is exactly what I've always understood this proposal to
be and exactly what I stated.

You don't think that an industry with the backing that the entertainment
industry can't get this done? It's silly to think that? Where do you think the
DMCA came from in the first place?

Now, I'm only talking about DRM for video and audio elements. If you're
talking about DRM across the board for every aspect of what makes a web page,
then I'm with you.

------
andybak
A key paragraph:

link: [http://lists.w3.org/Archives/Public/public-
restrictedmedia/2...](http://lists.w3.org/Archives/Public/public-
restrictedmedia/2014Jan/0066.html)

Well, as I say, the actual requirements that lead to the proposal of EME would
be a start. This is how it looks to those who don't agree that EME is a good
fit with the Open Web:

\- 'big content' has certain requirements relating to preventing users copying
data streams

\- they won't make those requirements public (as you've said, the agreements
are confidential)

\- their licensees propose a technical solution that is unacceptable to many
others because it necessitates the use of non-user-modifiable client
components

\- all proposed alternatives (e.g. FOSS DRM, server-side watermarking, client-
side watermarking, no DRM at all) are shot down as being either too expensive
or inadequate to the (secret) requirements

In a normal software project, I'd take an apparently insoluble conflict (the
requirement for non-user-modifiable client components) to mean that we have
done a poor job of determining requirements.

Hence my request for either a real user to talk to (e.g. an MPAA rep) or the
actual requirements docs, which you've told me are confidential.

And _that_ sets off my spidey-senses ... something is not quite right here.

~~~
RexRollman
Well, my question is does HTML even need to encompass everything it does. It
seems to me that we have an ever expanding monster. HTML does not have to be
everything for everyone.

~~~
talmand
I thought that was more-or-less what was being discussed. My understanding was
that the media element being accessed would not play the stream unless a
specified DRM component was available, most often due to a plugin installed to
the browser. It wasn't that they wanted DRM in the open web, they wanted the
open web to have the ability to communicate with a third-party DRM. A third-
party solution that an individual can decline to install and not participate.

~~~
Nursie
>> A third-party solution that an individual can decline to install and not
participate.

A third party solution that they can't get hold of because the 'official' one
only runs on windows and intel, and the ps4.

~~~
talmand
So? If they don't provide the content you wish to see in a way that's
convenient for you but is convenient for the mass of their market I fail to
see the problem. If you want to see the content bad enough then you accept the
requirements. Otherwise, it says more for you to not participate by not giving
money. As more people do this, things will change.

~~~
Nursie
So we shouldn't encourage its addition to open standards.

~~~
talmand
If it's in the standards to explain how to implement it and make use of it but
it's implemented as a third-party item that's up to the individual to decide
whether to install or not, what difference does it make? We're eventually
going to get that anyway so why not know how it works upfront?

Plus, from what I've read Chrome should start losing market share immediately
because it already has a form of EME implemented. All these people in an
uproar over the W3C's decision should be switching to something else to show
their concern.

------
josteink
Email the W3C. Tell them what you think of this bullshit (in reasonably polite
manners).

I've done it. I've gotten a non-canned response.

But clearly they need more people at the gates bitching. This needs to be
stopped.

~~~
duncan_bayne
To their credit, the W3C are handling the level of interest in this very well
indeed. Especially as many (myself included) have only passing familiarity
with W3C process & protocol.

But yeah, the more voices making clear, well-reasoned objections to this, the
better. Especially if that might actually result in it going to a vote.

------
duncan_bayne
It's worth mentioning that the CEO of the W3C, Jeff Jaffe, is trying to
rectify that:

[http://lists.w3.org/Archives/Public/public-
restrictedmedia/2...](http://lists.w3.org/Archives/Public/public-
restrictedmedia/2014Jan/0067.html)

~~~
duncan_bayne
... but the more I think about it, the more it's scary that things have
progressed so far _without_ the requirements being public.

~~~
wmf
There are versions that are public and I doubt the "secret" studio
requirements are much different:
[http://www.microsoft.com/playready/licensing/compliance/](http://www.microsoft.com/playready/licensing/compliance/)
[http://www.aacsla.com/license/AACS_Adopter_Agrmt_090605.pdf](http://www.aacsla.com/license/AACS_Adopter_Agrmt_090605.pdf)
(see Exhibit E on p. 90)

In reality these requirements are not set in stone; they are a business
negotiation. The first version of iTMS did not meet the record labels' DRM
"requirements", but Jobs convinced them that he'd make them enough money to
make up for any piracy that iTMS allowed. Likewise Windows XP did not meet
Blu-ray's "bag of hurt" robustness requirements but they made an exception
because no one was running Vista and Hollywood presumably cared more about
their movies being playable on computers than about the piracy that XP would
allow. Of course, this doesn't help free software people who aren't willing to
negotiate and would be starting from a very weak position even if they were.

~~~
duncan_bayne
Why do you say that Free Software people aren't willing to negotiate? We are
_very_ willing to; it's just that every suggestion we've made has been shot
down. I think it's very clear who is unwilling to negotiate here.

It's true, though, that there's one point on which we aren't willing to
negotiate: any W3C-endorsed standard must be implementable by anyone who
chooses, without paying royalties or licensing patents.

EME falls foul of this requirement, because the CDMs with which it is intended
to operate themselves fall foul.

~~~
wmf
Free software people aren't willing to negotiate about the right to read and
modify code but non-modifiable code is the only way that DRM can work.

~~~
betterunix
Can you even name any other class of software that _cannot work_ unless people
are somehow forbidden to modify or even _read_ the code? It sounds like this
is a problem with DRM, not with the free software movement.

~~~
chc
As a class, just about any program that depends on security through obscurity
has this trait.

~~~
malka
There is no 'Security through obscurity'. At best, you will have the illusion
of security, wich is worse than no security at all.

~~~
chc
This seems a bit like saying that there is no such thing as debugging because
applications still have bugs afterward. I agree with the overall thrust that
the security through obscurity is unreliable, but it is something, and it has
even been effective to a limited degree on many occasions. (For example, many
video game companies have employed defeatable security-through-obscurity
successfully, because they only need to hold off the crackers for a couple of
weeks.)

~~~
betterunix
Can you name any software that relies on security through obscurity -- and I
assume you mean obscurity from the user of the software, since nothing else
seems relevant here -- that is not just a specific kind of DRM?

------
belluchan
Can't we just fork the w3? Start using Firefox and forget about these people.
Oh I'm sorry your browser is a little slower, but at least it's not Google
made.

~~~
gsnedders
Fork the W3C? This is pretty much happened with HTML. The W3C membership voted
against chartering a group to work on progressive improvements to HTML (v.
XHTML2), initially in the form of Web Forms 2.0, and so the WHATWG was born.

The big problem is copyright on all the specs is owned by the W3C. Oh, you
want to spec CSS? Well, then you have to do it from scratch. Yes, HTML is now
at a point where it is better specified than ever, and more interoperable than
ever, but it's been a long, hard journey there. Consider the spec has been
worked on for over a decade now. Respecifying, from scratch, large parts of
the web platform is an incredibly large undertaking, especially ensuring the
spec defines something compatible with almost all web content when browsers
frequently disagree in edge-cases with up-until-now unspecified behaviour.

~~~
etherealG
are you serious?! copyright instead of left on the standards for the "open"
web? wtf

~~~
petercooper
The background on this issue:
[http://www.w3.org/2010/Talks/doclicense-20100323/](http://www.w3.org/2010/Talks/doclicense-20100323/)
and rationale:
[http://www.w3.org/2010/01/licfaq.html#consequences](http://www.w3.org/2010/01/licfaq.html#consequences)

~~~
etherealG
thanks very much. am i right in that the main reason for this is that forking
is undesired? how is that helpful to an open system?

~~~
gsnedders
The view is that forking of specs leads to a multitude of specs, thereby
making interoperability harder, and ultimately making the system less open.

------
alexnking
Maybe instead of getting everyone to adopt Silverlight, we could just make the
web more like Silverlight. Like more closed and stuff, because movies!

~~~
viraptor
Silverlight has nothing to do with DRM. It's a web content runtime similar to
flash. Sure, some codecs exposed through the runtime on a windows machine
supported DRM. But silverlight itself has as much to do with DRM as http that
was used to transport that content.

~~~
beagle3
> Silverlight has nothing to do with DRM

You are technically correct ("The best kind of correct"). However, the only
places where Silverlight still enjoys any use is, as far as I can tell, in
streaming services to PC and Mac (e.g. Netflix) - and in those places, the
only reason they preferred Silverlight to Flash or HTML5 video is .. DRM.

So practically, Silverlight is on life support maintained by DRM. If e.g.
Netflix decides to drop DRM, you can bet they will stop using Silverlight and
switch to something more portable (e.g. Flash or HTML5 video).

Statistically, Silverlight use has everything to do with DRM.

(weak analogy: Guns don't have anything to do with causing bodily damage. They
just shoot projectiles at high speeds. In this thread, we are discussing
personal safety)

------
ronaldx
Why is W3C involved in this?

Not only does this create a lack of openness and transparency in the core of
the web, but "big content" creators get to pass on the costs of DRM that
nobody else benefits from, including to people who are not consuming their
content.

Meanwhile, browser vendors will become uncompetitive - since nobody else can
compete against a closed standard - and they become even more motivated to
work against openness to maintain their existing oligarchy.

Could not be worse for the web.

------
dschleef
Compliance rules for Microsoft Playready:
[http://www.microsoft.com/playready/licensing/compliance/](http://www.microsoft.com/playready/licensing/compliance/)

The encryption part of DRM systems is effectively the same as client-side SSL
certificates with a secret SSL certificate. How well it's kept secret is
defined in the compliance documents. This secret, plus a secure decoding and
output path, are the engineering core of DRM systems.

Studios require "industry standard DRM" for movies and TV shows, with lesser
requirements for SD. This effectively means "DRM backed by some entity with
lots of money that we can sue if things go wrong". Studios approve each
individual device that you serve to, usually with compliance targets at some
particular future date for various existing loopholes.

Flash (Adobe Access) is somewhat different, and has an obfuscated method for
generating the equivalent of a client cert, thus on laptops it's only rated
for SD by most (all?) studios. Apparently studios don't care too much about
people copying SD content.

Studios would theoretically approve watermarking DRM systems, but there are
two major barriers: having a large (ahem, suable) company offering it, and
some way to serve individualized media through a CDN. Neither seem likely. So
nobody loses too much sleep about whether studios would actually approve
watermarking.

------
girvo
Sigh. Look, I'm okay with DRM, as long as it works on all my devices. EME
won't, under linux, I guarantee the DRM Vendors won't bother releasing Linux
binaries. That annoys me.

~~~
zanny
> I'm okay with DRM

It seems really defeatist to say this. You are a consumer. You have the
ultimate vote on everything, with your wallet, with the only exceptions really
being what you need to survive and whatever your government takes.

And I don't think netflix is on par with eating.

My problem is I have no idea what to do about the w3c. I'd really like to know
what alternative network protocols for document rendering there are, because
they are destroying the platform they are supposed to advance, community
backlash be damned, they got bought off.

I'm definitely looking into ways to get qml into browsers, though. I think
qtquick apps as remote resources would be amazing, because they would be
actual apps, not documents with scripts running on them.

~~~
girvo
I'll be honest, I can say that I don't mind it as I rarely consume media that
we're discussing. If I do, it's one show rented on my Apple TV, and that's it,
maybe once every six months.

~~~
zobzu
Well, this very push for DRM on the web is to change exactly that. It's to
force _you_ to use DRM-only content.

So - yeah.

------
shmerl
_> So, the DRM vendors have solved the problem of creating solutions that meet
studio requirements and what we are trying to do with EME is provide a clean
API to integrate these solutions with the HTML Media Element._

Which reads as: studios have nonsensical requirements, which are implemented
and soon broken. And "we" (i.e. W3C) need to oblige this insanity for the sake
of <...>.

Put your own reason, but I bet it won't be good.

~~~
duncan_bayne
I just posted to the list, trying to explain that EME is not a requirement, it
is an implementation.

~~~
shmerl
I understand. My point is, it's an implementation of an absurd requirement
which simply should be ignored, rather than obliged as in providing an
implementation.

------
kevin_bauer
I guess, the "another backdoor" proposal will go very well in Europe, where
most citizens are just static about americas view on privacy and respect for
constitutional rights. Way to go, maybe the W3C will finally get Europe and
the rest of the "free" world to create their own web!

------
pyalot2
HTML-DRM, proudly building "solutions" to problems nobody has, by following
requirements nobody knows about, to create a landscape of content nobody can
play.

Way to go W3C, keep up the "good" work.

------
Zigurd
Why should DRM be part of a standard? Aren't plug-ins sufficient?

~~~
gsnedders
EME essentially defines a wrapper around a module, which can quite easily be a
plugin, that implements the DRM. You can view it as a means to require smaller
plugins than NPAPI, PPAPI, etc.

~~~
Zigurd
So, why have that discussion inside a standards discussion, especially if it
brings in confidentiality requirements? Let the publishers talk among
themselves and write their plug-ins.

~~~
duncan_bayne
In my more paranoid moments, I worry that the answer is: this work is
explicitly intended to break the Open Web as we know it.

This is why I'm so keen to get all the requirements out in the open and start
discussing them transparently.

~~~
eponeponepon
Personally, even in my least paranoid moments, I think that's a certainty. Why
let things be open when you can charge people for the key? See also:
turnpikes.

------
alkonaut
The only benefit I can see from standardizing something is that browser makers
who want to claim to be compliant actually have to support it, so you won't
end up in the flash/silverlight situation where some platforms don't support
it.

But if a plugin framework is standardized, why settle for only DRM? Why not
fix the whole crapfest that is plugin applications entirely? A standardized
interface to a fast sandboxed virtual machine with good hardware support would
be excellent. Currently there is javascript, ActiveX, flash, java applets,
Silverlight, NaCl, WebGL and a number of others, each having their own
benefits and drawbacks.

If I want to write a web based multi-threadced GPU accelerated webcam-using
application that works on any compliant browser on any platform, what do I do?
Isn't that what the next kind of web standards should be addressing?

~~~
fafner
> The only benefit I can see from standardizing something is that browser
> makers who want to claim to be compliant actually have to support it, so you
> won't end up in the flash/silverlight situation where some platforms don't
> support it.

Please read the spec. Your assumption is wrong! The EME just defines an API
for JavaScript to access an unspecified CDM (the DRM module) in the browser.
It does not specify how the DRM should work (it would be by definition
impossible). It does not specify how a browser should acquire or handle the
CDM.

Therefore EME will not only ruin the open Web. But it will be less portable
than Flash. At least Flash somehow works on Linux.

~~~
alkonaut
You misunderstood me, I think if there should be standardization of _some
kind_ of platform indepndent "plugin" it should address what flash, applets,
ActiveX and Silverlight does but in a standardized way.

~~~
fafner
It is - by definition - not possible to have an open standard or libre
implementation for DRM. You could simply implement it to dump the stream
instead of displaying it.

If you mean the features besides DRM then we don't need a plugin because HTML5
and JavaScript are perfectly fine for replacing those plugins and they can be
openly implemented and distributed.

~~~
alkonaut
I mean a standard way of distributing binary executables where anything the
plugin author wants can be done (within a sandbox). For example the decoding
and display of protected data. Much like flash, but with some form of
standardized bytecode vm. I understand that the implementation if the actual
DRM will probably be closed, but the plugin standard that hosts the DRM code
should not have to be.

Apart from allowing closed binary applications it should of course offer some
other benefit over javascript, such as offering good hardware support (true
multithreading with shared data, access to all peripherals, and so on).
Javascript even with WebGL+WebWorkers+similar frameworks isn't it.

------
PavlovsCat
Here are some thoughts by Cory Doctorow on web DRM. Spoiler: he's not a fan.

[http://mostlysignssomeportents.tumblr.com/post/72759474218/w...](http://mostlysignssomeportents.tumblr.com/post/72759474218/we-
are-huxleying-ourselves-into-the-full-orwell)

------
hbbio
Looks like the W3C may have been the inspiration for Games of Thrones...

Seriously, if there are men and women of honor in this organization, they
should stand up against any form of standardization for DRM. DRM can be a
proprietary extension for the people who want it.

------
xyjztr
Hey Guys, can somebody create a simple guide, FAQ or something similar for
non-tech people to understand what is going on with HTML and DRM? It will help
to spread the word.

~~~
hsivonen
[https://hsivonen.fi/eme/](https://hsivonen.fi/eme/) explains what EME _is_.
Granted, it might not explain "what is going on".

------
duncan_bayne
From the mailing list: "[with EME] ... the publisher will have the possibility
of deciding which platforms may access their content."

That was from one of the proponents of EME, touting this as a _good thing_.
The response from another list regular was excellent:

"In non-web-terms this is the publishers deciding on what brands of TV you're
allowed to play their content."

That's where EME will take the Open Web. We need to oppose it, strongly,
urgently.

------
pjakma
I download movies and TV shows using Bittorrent and index sites like TBP
because of DRM. Often these DRM systems are not available for Linux, or if
they are, they require installing some big blob of binary code. It is easier
and more secure for me to use bittorrent.

I would happily use the legal services, if not for this DRM. Those services
sometimes are even free (e.g. BBC iPlayer). I would happily pay for a
subscription service (I pay subscriptions to a number of different of online
sites, mostly journalism or data-organistion - I've no problem with that).

The industry standardising proprietary DRM in W3 will just ensure that I
continue to support the distributed, end-user provided services which are DRM-
free.

------
drivingmenuts
Since many are using Steam as an example of DRM - the important difference is
that Steam is a free product, but is not open-source (though it can be used to
distribute open-source). It is produced by a company as a means of
distributing their products.

It is not even a valid comparison to the blinkard pig ignorance of the secret
DRM requirements in HTML, which is an open standard.

I'd just like to know what dipshit at the W3 signed off on this.

------
dreamdu5t
What's the problem? Don't support companies that distribute any DRM content.
Standardizing DRM and propogating DRM aren't the same thing.

~~~
higherpurpose
It sure helps propagating it, once you have a standard all the vendors can
use.

~~~
duncan_bayne
But all this standardises is the interop between the browser and the non-user-
modifiable client component, the CDM.

~~~
shmerl
Any standard makes it less messy and gives them more excuses to continue
pushing it instead of admitting that it should be dropped. It's absurd to
promote standards for unethical practices.

~~~
duncan_bayne
Yes. Perhaps I did a poor job of explaining things in my previous post. I was
just trying to say that EME being standardised won't actually help standardise
CDMs.

------
aquanext
Can't we just boycott this entirely?

------
mcot2
If our end result is to see Netflix using HTML5 video on Desktop browsers, how
do we get there from a technology and business point of view? Keep in mind
that Netflix has content created and owned by the major studios. If any form
of DRM is not the way, than what? How do we get to this end goal? Do we make
streams 'free' to copy and rely more on the legal system for protection? We
are all keen to slam DRM, but what is a viable alternative?

~~~
onion2k
There is no reason why the free and open standards of the internet should be
compromised so that a particular business can operate on it. If DRM-free HTML
video makes it so that Netflix can't develop a browser based viewer, so be it.
The internet is bigger, and considerably more important, than streaming
movies.

------
jlebrech
why can't they just build it in NaCl and leave the open standard alone.

~~~
hsivonen
In that case, the site providing DRMed video and the NaCl player would have
distribute an H.264 decoder (and potentially other encumbered stuff) to end
users as part of a NaCl executable. It's much more convenient for a company
like Netflix not to have to distribute the DRM component when companies like
Microsoft and Google are willing to do it instead. Also, NaCl doesn't
integrate with the HTML media elements, you'd need to implement the whole
media stack in NaCl instead of just the DRM part.

Furthermore, since NaCl is sandboxed by the browser (and the browser is
untrusted by Hollywood in the DRM trust model), it can't conspire with the GPU
on low enough a level to hide pixels from the browser and the operating
system.

------
silveira
HTML6 = HTML5 - DRM

------
Fasebook
The internet was nice while it lasted.

