But personally, I'm kinda sick of people referring to the EME draft as "DRM for HTML5", since... well, that isn't what it is. Five minutes with the EME draft would clear up that misconception.
Look, I've read the entire proposal, and it's obviously DRM for HTML5 video. It has specific error codes for standard DRM restrictions like "A hardware configuration change caused a content protection error" and "There is no available output device with the required characteristics for the content protection system" (no HDCP, no playback) and "The Key System could not be installed or updated".
It's designed to support a license server, an (unspecified, naturally) mechanism for the CDM to decrypt keys from the license server and store them internally, a (CDM-specific, i.e. unspecified) mechanism for the CDM to attest that it's deleted keys, and all the other parts of DRM.
The BBC have demanded that HTML5 EME be robust enough DRM that accessing content through unauthorised software is a criminal offense here in the UK, and the W3C spent some time on that too (though it's not mentioned in the standard itself).
It's basically a way of allowing DRM-based sites to claim to be 100% standards-based. It doesn't even provide much interoperability benefit over every DRM provider writing their own DRM API for HTML5 video; sites still need a bunch of DRM-scheme-specific glue code between the web server and license server, and the same with CDM and browser vendors on the client end. They don't even standardize the codecs and containers used - there's a couple of optional, non-normative container encryption schemes, but DRM schemes don't have to support either, so sites may (and probably will) have to encode and store multiple copies of each video to support different DRM schemes. It's less fucking standardised and interorperable than satellite pay TV!
Edit: I just realised that I'm replying to someone other than the author.
Hi, I'm the guy who logged the bug that used the words "HTML5 DRM". [1] That was, of course, a bit of a simplification. However, for a number of reasons, EME is bad for the following reasons:
1. A key distribution mechanism for only playback and for one element indicates that this is the first stage in wanting to apply this sort of rubbish to the rest of the standard
2. EME requires a CDM. While there is a well defined interface to the CDM, the CDM itself is a binary blob that won't be documented, might use OS specific features (e.g. The DRM system of the OS), and will need to be built for each individual browser and potentially operating system.
3. The EME draft is specific to encrypted playback. This is to allow Hollywood and others the ability to produce walled content. It's somewhat obtuse to say that EME will be used for anything other than implementing a DRM system. So far, the only CDM implemented is Google's Widevine DRM for Chrome only. I believe that Microsoft have something waiting in the wings, along with Netflix.
For that matter - let's look at the case where a specific DRM system is not used, and an encrypted key is sent to the CDM, which just decrypts the content. How is that not a form of DRM?
The post gives the following as to why Mozilla is great:
1. The Web should be open: The Internet is a public source of information that must be open to and accessible to anybody around the world.
2. The Web should be interoperable: People should not be locked in to an ecosystem and they should be able to use the technology they prefer to access the Internet.
3. The Web should be ours: People should have the ability to shape the Internet experience and be able to contribute with content without requiring permission from a central entity.
How is enabling Encrypted Media Extensions for the sole purpose of only preventing the playback of video and audio of the web enabling any of those important pillars of Mozilla's raisin d'être?
Last I heard, Google's Widevine EME wasn't just restricted to Chrome, it was restricted to ChromeOS running on official Chromebooks that are in locked-down mode so that the user can't run any of their own code. It's not just DRM, it's really restrictive DRM compared to what it's replacing.
"will need to be built for each individual browser
and potentially operating system."
Right. And once that happens, deals will be struck that guarantee the content will be playable only on given systems. For example, Microsoft creating a set-top box and locking out Roku, etc.
But personally, I'm kinda sick of people referring to the EME draft as "DRM for HTML5", since... well, that isn't what it is. Five minutes with the EME draft would clear up that misconception.