Perspectives on Encrypted Media Extension Reaching First Public Working Draft
w3.org
w3.org
> 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?
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.
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.
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 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.
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.
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?
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.
(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.
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)}At least with <video> the only thing encrypted will be the actual video file.
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.
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.
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.
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.
>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.
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.
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.
Whats your leverage?
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 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...
Update: here is an interface that decrypts a frame and returns the clear version: https://code.google.com/p/chromium/codesearch#chromium/src/w...
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.
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.
"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
It's a big "fuck you peons" repeated again and again. If you can't see that, you're clearly not looking.