An open source browser can conform to the W3C DRM standard ("Encrypted Media Extensions") and remain open source.
It also does not define a common API to load such a module in a browser. In fact the module can also be built into the browser. Which is exactly what Microsoft will be doing with their PlayReady for the Internet Explorer.
An open source browser would have to rely on the DRM module to do all the video decoding and rendering. If the module handles the unencrypted stream back to the browser then one could simply change the browser to dump the stream. A browser would also have to make sure that other JavaScript can't access the unencrypted content. So no more funny graphic effects with videos rendered onto canvas or WebGL textures.
This proposal will destroy the open web and make it rely on closed source binary blobs. A free software browser will end up being useless because it will be excluded from most of the content. Who would want to use Firefox or Chromium if they can't access YouTube? When we start to add DRM for media elements then how long can it be until publishers demand DRM for text and image content? And what argumentative position would the W3C have to refuse it?
With Firefox market share decreasing and proprietary browsers like Chrome, IE, Safari increasing we are in a really bad position. Microsoft can simply push their PlayReady in IE and provide plugins for Chrome and Safari. Netflix is already using PlayReady. So no change for them. And then Firefox is fucked. Linux is fucked.
And how long until Google moves YouTube to DRM? Google is involved in the design of the DRM proposal. If DRM is in HTML5 then it's just a simple step for them.
That's why we have to oppose DRM in HTML5 and keep the web open. It is sad that Tim Berners-Lee has given up on the open web. But I won't and I hope Mozilla won't and I hope you and others won't either.
Fully agree. I think the focus of the effort should be to lobby the 2 browser vendors that are driving this DRM effort, Google and Microsoft (see 'Editors' section on https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med... ).
The only way to stop this DRM proposal is to have it not be implemented in browsers. The only way to stop that is to convince Google and Microsoft to stop pushing it.
Opposing EME will simply keep Microsoft and Adobe uncharged of the web video market and keep that market smaller thB the Apple, Google, Amazon, etc. stores.
The last time someone took a “principled” stance like this and blocked H.264 in Firefox, remember what happened? Flash got many extra years of life and Firefox lost marketshare.
I'd prefer we stop pretending this is anything other than a minor shift in the status quo and focus on the larger anti-DRM campaign. The right place to focus is the bottom-line: educating consumers about the restrictions and supporting alternatives. As long as people are paying billions of dollars through native apps, you're fooling yourself to believe that this EME opposition is doing anything but supporting competitors to the open web.
Frankly, this system would only work if you standardise in a DRM system. The W3C may claim "only the simple clear key system is required to be implemented as a common baseline" [1], but that's highly misleading IMO.
1. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
This is really only about replacing a huge proprietary blob with a much smaller one.
The video element already exists and is implemented in all major browsers. Have a good look over http://en.wikipedia.org/wiki/HTML5_video
This has exactly nothing to do with reducing the attack surface of a browser.
What this is about is letting people like Audible and Netflix encrypt their content in a special way that means that only browsers that support the DRM api can decrypt it; by including the closed source binary blobs provided by those vendors.
Don't want to do that? Sorry, our website doesn't work on your browser.
...but to the main point:
This will in fact catastrophically increase the attack surface of browsers, as they are forced to bundle unmoderated, unreviewed binary code blocks (Content Decryption Module, from the spec) that can do whatever they like into the browser code.
That's no different from the current situation with Flash and Silverlight. You're not forced to use them, but some content is only accessible if you do. If we can replace Flash with a CDM, the attack surface is decreased, because a CDM is less complex.
Without the EME standard, it seems highly unlikely that media companies would decide to distribute videos DRM-free. They would simply continue to build and use non-standard solutions. EME is just a standard API for what they'd be bound to do anyway.
The browser must invoke the closed source, vendor provided CDM by pass a binary stream from the server.
Certainly, it's no worse than what we currently have, but current plugins have, shall we say, a rocky security history wouldn't you say? (>_> java)
Worse, every content provider is going to have their home written CDM, because they certainly aren't going to share. Once a CDM is compromised thats it, it's useless.
It's going to be a nightmare of install-all-the-plugins. Most likely major browsers will bundle the most popular one to reduce the burden on the user.
That's why this is such a big improvement.
What was said was that it is there, and services are choosing not to use it, even accepting that using it would be suicide for their business. It's not the responsibility of http to preserve the business models of those companies rather than a free and open internet, though it's understandable that those businesses are fighting for it.
Even half of the ad-supported content on YouTube isn't available.
As an implementor, until mozilla finished shipping native h.264 support I have to either use Flash as a fallback for IE8 and Firefox (mediaobject.js is great!) or encode all of my video twice and double my storage bill. Guess which one is more appealing?
Here it is right in the list of APPROVED Free Software licenses: https://www.gnu.org/licenses/license-list.html#MPL-2.0
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_re...
It's not really a big deal, but the trademark restriction does mean you can't just redistribute Firefox as-is. Whether you count that as non-free is subjective.
DRM-enabled Firefox would be effectively non-free software: you could not modify it and rebuild it from source while retaining the DRM functionality.