Hacker News new | past | comments | ask | show | jobs | submit login
Perspectives on Encrypted Media Extension Reaching First Public Working Draft (w3.org)
33 points by throwaway2048 on May 13, 2013 | hide | past | favorite | 45 comments



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?


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.


It's the case for some industries, but it's a fallacious example. You're citing cases where businesses have been successful, I would say, in spite of DRM, in industries where the status quo is accepting DRM or having no content.

Amazon distributes MP3s via "the open web" - sure, it's via MP3 files over HTTP, but an <audio> tag can pull that, Amazon could (and perhaps does) implement their cloud player in that manner anyway.

Valve's Steam distributes a great deal of games without DRM - games are high margin products compared to music singles or DVDs, yet they seem quite successful. I try, or often only buy DRM-free games on Steam to support them.

Apple's iTunes switched in the past few years to distributing music without DRM that encumbered their files and locked in consumers to their iEcosystem. Those files can be uploaded, trivially, to any file sharing network.

The Gordian knot of the problem of piracy and DRM is that only one dedicated person needs to leak it, and as long as I can listen to, look at or sense content, the analog hole will exist. Content industries have tried the approach of treating all of their customers like criminals, and it's been awful for consumers and the amount of content available trivially on peer to peer networks hasn't decreased or even decelerated, as far as I can tell. This treating everyone like a criminal to prevent one dedicated attacker is insane in the colloquial sense, wherein content companies try DRM over and over again and expect different results.

I say, let Hollywood and the video content industry squirm until it realizes it needs the internet more than the internet needs it.


Sorry, Steam games are not DRM-free. It is however the case that Steam has some of the least aggressive DRM you'll find in video games, but it is absolutely not DRM-free.


many games distributed on steam do not require steam at all to run. ie, all the humble bundle games.


Yes, but the steam releases typically still have Steamworks DRM, as far as I know - otherwise Steam Achievements and similar features wouldn't work. Has that changed? Can you just copy the folder out of steamapps and run it on another computer?


yes, just tested with binding of issac for instance, which has steam achivements and steam cloud sync, works without steam on a different system entirely.


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?


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.


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.


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.


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?


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.


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


Practicality of porting was never a driving concern for Flash: it was business viability. I don't expect any more platforms to be supported than are today.


Flash is a considerably larger undertaking than a plugin though; if the interface is standard shipping on different platforms should just involve setting up appropriate QA and another make target.

At the very least, the decision of what platforms lies with the provider trying to extract money from the market, rather than one of its suppliers - that's surely an improvement?


In theory it could be more portable. In practice, though, it's looking like the actual CDMs released will all tie into platform-specific DRM at a much deeper level than Flash ever did, and content providers are insisting CDMs do this just because they can.


Among other things, it means a much smaller surface than the bug-riddled ginormous Flash Player.


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.


How does DRM solve "the revenue problem"? If you're currently distributing non-DRMed video for free, wrapping it in DRM won't create money out of nowhere. Are you talking about ad-blocker-blockers or something?


Flash was (and is, but I think the prevalence is declining or at least growth has slowed or stopped) used to deliver much content that I would consider to be or in the nature of being (before ginned up) static.

(Perhaps not the best example with respect to my concern here, but one widely cited example of this: Flash to view the menu of a restaurant I'm interested in or scheduled to visit.)

I fear a DRM mechanism in the standard (and so, with broad, built-in deployment) will be used the same way. You won't get any content without enabling the DRM, and whatever payment mechanism is associated with that.

Whether subscription, or ads. And while I'm not adverse to useful, non-intrusive, safe ads, we've yet to see those realized in a consistent and reliable manner. With DRM, content can be inextricably tied to bad, exploitative, and unsafe ads.

It's not what one thinks it will be used for. It's whatever a developer can twist it to do.

What I find to be similar arguments exist for e.g. not permitting the government to backdoor communications and security systems. It's not always the overt use we worry about; it's often the covert use, whether by government or by third parties.

P.S. I'll add that I'm not a technical expert in this particular area. But, I tend to suspect -- or regardless, look for -- the worst, and I often end up finding it. And doing that in technical environments has been a significant part of my career, where I've done quite well at finding and solving problems before they cause catastrophes (or, as the case may be, after).

TL;DR: I fear this baked in DRM as a closed channel for any and all sorts of dangerous as well as annoying crap and behavior.

I'm not claiming to have a solution to all the current woes. But I don't see this going in the right direction.


EME spec covers only a JS API for metadata exchange with unspecified magical CDM plugins.

The spec deliberately doesn't cover how CDM gets integrated with the browser (currently: you're Google and you make a deal with Netflix privately and get binary to bake into closed version of ChromeOS).

* It might be that CDMs will be shipped with the OS (Widevine in Android/ChromeOS, WMDRM in Windows, FairPlay in OS X) and you'll have to rent licensing servers from each vendor.

* It might be that browser vendors will allow ActiveX-like download or allow regular .exe installers add components to the system and you'll have convince viewers that you're not giving them a virus.

* Or it might be that major browser vendors will license Netflix DRM, Hulu DRM, Amazon DRM and that's it.

In either case if you're a small player, you probably won't be able to use the DRM. The only option for you will be the default ClearKey which is as pathetic as the name implies. It can be broken with:

    javascript:MediaKeys.prototype.update = function(key){alert("game over " + key)}


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.


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.


Many sources provide a flash player that itself obtains the video via a completely open stream - in fact, I haven't seen anyone using encrypted video files on the web. So for practical purposes the current situation is better.


None of the nightmare scenarios are enabled by this proposal that aren't already possible though.

Flash is available and baked in, providers can already run to DRM-ed content since the ubiquitous platform enables it. It's currently used in part as the solution to the revenue problem.

All these problems already exist, mostly because of Flash. We still have to accept without inspection whatever Adobe sees fit to deliver (which leads to terrible results).

All this proposal really represents is an opportunity to unseat Flash and replace it with a more accountable party to complain to when a device you own can't play the content you buy.


EME is worse than the current situation, because it removes Adobe and Microsoft standing between MPAA's desires and your computer.

At least Microsoft and Adobe would refuse to implement DRM that is too user-hostile in order to save their eroding reputation and install base.

But with EME you have to run whatever binary Netflix tells you to install, and that will do whatever people who pull the strings on Netflix want.


That is a valid point, but I think some power is still retained by the consumer in the sense that they can reject individual DRM implementations and accept others, while with Flash they're forced to install it if one provider they wish to use requires it.

The point of user-hostility is the only point that is an obvious problem to me; if the CDM was sandboxed and had a very limited set of access beyond it - pretty much the same environment provided by Flash - I'd be happy.


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


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


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.


Because you can't pressure Google not to include EME in Chrome, because Google knows which side its bread is buttered on.


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?


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.


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


If you want to have a look, here's Chromium's implementation of the spec: https://code.google.com/p/chromium/codesearch#search/&q=...

Update: here is an interface that decrypts a frame and returns the clear version: https://code.google.com/p/chromium/codesearch#chromium/src/w...


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


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.


Indeed. Usually publication of FPWD is done when there is consensus in the group. In this case HTML WG Charis decided to ignore protests of group's members and publish despite objections on both technical and ideological grounds.


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.


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


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


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


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... [5] http://www.w3.org/2005/10/Process-20051014/policies.html#WGA... [6] http://www.w3.org/2005/08/01-transitions.html


His every reply is dismissing very real concerns, (deliberately?) mistaking free as in speak for free as in beer when it is convenient and saying "Yeah. I'm sure this will work with open-source. They'll make open-source implementations of this DRM for all platforms evar. Really. Nothing to see here."

It's a big "fuck you peons" repeated again and again. If you can't see that, you're clearly not looking.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: