
Perspectives on Encrypted Media Extension Reaching First Public Working Draft - throwaway2048
https://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html?utm_source=dlvr.it&utm_medium=statusnet&foo=1
======
AaronFriel
The mistake being made here is that large content industries need the web more
than the web needs them. The following assertion simply doesn't hold, as seen
by other industries that have had magnificent success despite piracy or
despite DRM:

> Without content protection, owners of premium video content - driven by both
> their economic goals and their responsibilities to others - will simply
> deprive the Open Web of key content.

From whence does this assertion come? Of course, the content industries that
lobbied for this. But if there is no HTML support for DRM, does anyone think
content industries will give up on distributing content online?

~~~
rainforest
Isn't this already the case? Netflix forces users to use Silverlight; YouTube
won't serve HTML5 videos if ads are enabled. The "Open Web" is already lacking
their content because they rely on DRM already.

Content industries won't give up on publishing, they'll just pursue the
current status quo of terrible plugins for the imaginary protection DRM gives
them.

In an ideal world the executives concerned about piracy would realise their
errors, but from my perspective, DRM'd HTML5 videos natively decoded are a
world better than those reluctantly vomited out using Flash.

~~~
gsnedders
How is a third-party black-box module decoding it to a specific point on the
viewport a "world better" than Flash, a third-party black-box module, decoding
it to a specific point on the viewpoint?

~~~
rainforest
The former doesn't include redundant duplication of functionality and other
bells and whistles. Since the only objective is decrypting content it'll
presumably be more practical to port (and reverse engineer) and ship with
fewer security vulnerabilities.

It's by no means perfect, but the less that can be delegated to a plugin the
better in my view. I don't see this as an ideal choice, just a pragmatic
choice for a better option given the circumstances.

My quantification for "a world better" relies on the subjective judgement that
Flash is worlds worse than some mystery crypto blob. I believe that to be the
case.

~~~
AaronFriel
Since the topic is DRM, and DRM only works if you don't know how it works...

> Since the only objective is decrypting content it'll presumably be more
> practical to port (and reverse engineer)

I cannot comprehend the confusion of ideas that could provoke such a
suggestion. Do you really believe open source platforms will get an open
source module? Do you think it'll be anything _but_ a black box whose nature,
by definition, precludes anyone knowing what it does? Where will you get your
guarantees about security vulnerabilities, when the very nature of the code
will be, _must_ be such that it is as difficult to discern its purpose and
mechanism of operation as possible.

~~~
rainforest
Perhaps I could have been more clear; when I say "porting" I mean from the
perspective of a vendor. The current status quo is that content is available
only where Adobe can be bothered to provide Flash. Given that constructing a
"secure" black is a smaller task than providing a standardised runtime
environment, it's feasible that vendors might target more than just Windows
and OSX. This has nothing to do with source availability.

w.r.t easier reverse engineering, given the behaviour is constrained to the
target blob and the interface is standardised, liberating content should be
simplified. As far as security vulnerabilities go the choice still remains,
run the blob or don't view the content.

~~~
wmf
OTOH, it will be impossible to port CDMs to browsers that don't allow CDM
plugins. Do we think Safari or Metro IE are going to allow them?

~~~
rainforest
The same can be said of Flash, however. The other side of that coin is that
content will never be available DRM free, so I'm not sure if it's an important
point; mobile content delivery is normally achieved via apps, or in the BBC
iPlayer's case, in the browser, "protected" by a client certificate.

~~~
wmf
Flash is specifically grandfathered by browsers but EME isn't.

------
pasbesoin
Remember when Flash was becoming ubiquitous?

Here's a primary concern of mine: Many people think this means Netflix will
continue to be DRM-ed, YouTube will gain DRM-ed for-pay channels, etc. AKA
premium video. (Oh, and audio -- nearly forgot that.)

Once the tool is available, baked in, I fear a wholesale run to DRM-ed
content. This will certainly be at least _tried_ as _the solution_ to _the
revenue problem_.

I'll add that, aside from the implications for an "open Net", I also worry
about the security implications: We'll be forced to take without inspection
whatever an encrypted provider sees fit to deliver or falls prey to. No,
thanks.

~~~
beaumartinez
The alternative is that people will continue to use Flash, an even more
obscure (and not to mention closed) format, which we are forced to take with
even _less_ inspection.

At least with <video> the only thing encrypted will be the actual video file.

~~~
pornel
Note that EME is an interface for arbitrary DRM plug-ins (CDMs) that could be
implemented on system/kernel/hardware level.

Flash and Silverlight at least live in userland and have public API (NPAPI).
AFAIK using them in your own browser is not a DMCA violation.

OTOH EME deliberately does not define any API between browser and CDMs, so DRM
vendors have opportunity to license CDMs to selected browser vendors and make
playback with "unapproved" browsers (e.g. your own open-source build) a DMCA
violation.

------
JonSkeptic
>By putting hooks for DRM into your standards you are not protecting the open
web, you are destroying it.

>Please stop before you betray your founding principles any further.

Reposted from the comments of the draft. I couldn't agree more. Don't turn
your back on your principles.

------
surrealize
> Without content protection, owners of premium video content - driven by both
> their economic goals and their responsibilities to others - will simply
> deprive the Open Web of key content.

False. That's what they say, but that's not what they do. When digital
broadcast TV was getting standardized, content owners insisted that there be a
"broadcast flag" that would prevent receivers from copying broadcast data.
There was a bunch of push-back against that proposal, and it died.

And what happened? They go ahead and broadcast everything anyway. It turns out
that the broadcast flag wasn't actually necessary. Without the flag, content
owner business models work just as well as they did before.

Flash is going away. Silverlight is going away. The presence or absence of DRM
in HTML isn't going to change that. Some people remember the frustrations of
flash and silverlight and think that the W3C EME proposal will solve those
problems. But those problems were solving themselves just fine! Now we get to
look forward to a bunch more pain with proprietary, non-interoperable CDMs.

------
Tinned_Tuna
Why not just fork the W3C's specifications, and pressure FireFox and the
makers of other browsers & rendering engines to never incorporate DRM?

My personal issue here is that it seems that W3C is going against it's own
founding principles, running a committee that's biased towards the content-
industry.

~~~
nullc
The Pro-DRM side has netflix and a bunch of other DRMed media sites which will
work if people switch to Google's Chrome browser or MSIE.

Whats your leverage?

~~~
josteink
If you are willing to install various random black-box binaries from random
pages on the internet.

We saw how well that played out with ActiveX. This is pretty much the same,
just even less open-source friendly, since the intent is the deprive the
machine running the code of access to the content. Let's not make a rerun of
that.

The second this goers mainstream expect a bunch of free "porn sites" saying
you need to install their "DRM plugin" to view the content. And voila you have
browser-assisted trojan installations.

Firefox and other browsers supporting the open-web, without DRM, will have
leverage that it doesn't ship with a gaping open door for spyware, malware and
viruses to enter.

It will be the only browser with the user's interest in mind. We've already
seen how Google is abandoning that in Chrome. This will only make it more
apparent.

------
zimbatm
In the current spec[1], CDM might either return the decrypted frame to the
browser or forward it to the system.

In practice it would be way too easy to patch say Firefox if they implemented
the spec to intercept the decoded frames. It means that either the CDM
wouldn't work with any open-source browser, or that they will only directly
render to the OS. But in that latter case I don't see how it would play well
with the rendering of the page, it would be the same problem we had with old
version of flash where you couldn't overlap elements.

Does anyone know if Chromium implements that feature (since Chromebooks
already do) ?

[1]: [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-fpwd.html)

~~~
zimbatm
If you want to have a look, here's Chromium's implementation of the spec:
[https://code.google.com/p/chromium/codesearch#search/&q=...](https://code.google.com/p/chromium/codesearch#search/&q=MediaKey&sq=package:chromium&type=cs)

Update: here is an interface that decrypts a frame and returns the clear
version:
[https://code.google.com/p/chromium/codesearch#chromium/src/w...](https://code.google.com/p/chromium/codesearch#chromium/src/webkit/media/crypto/ppapi/cdm/content_decryption_module.h&sq=package:chromium&dr=C&l=344)

------
Yaa101
It took a decade to have some html draft, and this one goes through with a
breeze, makes you think...

~~~
Ygg2
Former required a lot of thought and consideration, synchronizing various
actors of W3C, while the latter didn't. Also latter group has more money.

I'm sad really. This makes any open source Web Browser a second class citizen
of the WWW.(@W3C) Great job, guys, great job. Seems like a big step on the
road to fragmentation.

------
josteink
What this proposal is saying, just not straight out, is that from now on the
internet should no longer be fully accessible from Linux.

Only "first class" proprietary OSes (Windows, OSX, possibly ChromeOS) with
proper DRM-hooks from boot-loader to video-driver to OS-APIs will have
"sanctioned browsers" for which the content-industry will bother implementing
compatible CDMs, and only they will be able to access so called "premium
content".

The W3C is saying they are _fine_ with standardizing a fragmented, closed down
web.

They have clearly lost their mind and should lose their mandate.

------
throwaway2048
Be sure to read the comments, a lot of valuable points and discussions.

~~~
qznc
Kudos to Jeff Jaffe for staying calm and professional while replying to all
the arguments.

~~~
Daiz
"Calm and professional" while dodging basically all and every argument
presented to him.

~~~
qznc
That comment section certainly is not the place to discuss these issues. Just
like Hacker News is not the right place. He repeatedly pointed to the working
group.

"If anyone strongly disagrees with the content of the decision and would like
to raise a Formal Objection[5], they may do so at this time. Formal Objections
are reviewed by the Director in consultation with the Team. Ordinarily, Formal
Objections are only reviewed as part of a transition request[6]."

[0] [http://lists.w3.org/Archives/Public/public-html-
admin/2013Ma...](http://lists.w3.org/Archives/Public/public-html-
admin/2013May/0030.html) [5]
[http://www.w3.org/2005/10/Process-20051014/policies.html#WGA...](http://www.w3.org/2005/10/Process-20051014/policies.html#WGAppeals)
[6] <http://www.w3.org/2005/08/01-transitions.html>

