If anything it's the opposite. Defining a standard interface for content decryption allows such a system to be browser agnostic. You install a module and it works in any browser which implements the spec, whether proprietary or open source.

Unless they've changed it since I looked, the only interface the HTML5 EME specification defines is the one between the website and the browser. There is no standardized interface between browsers and DRM modules, nor is there any requirement browsers support external content decryption modules. For example, last I heard IE was only going to support a built-in implementation of Microsoft's PlayReady which isn't available to anyone else.

In fact it's not clear that anyone can use a standardized, open API for decryption modules and meet content providers' security demands. While some of them were historically willing to use Flash which did use standard browser APIs, they've taken this as an opportunity to demand more.

There's a good diagram on the w3 page. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

It looks like the idea is to implement a system where encrypted content is passed to the browser. The key is then sent through the browser to the CDM, the CDM can take the content and hand back decrypted frames.

It's entirely possible for content vendors to support multiple CDMs for different browser or OS combinations. The advantage of this is that the CDM is a smaller dependency than something like silverlight, so you can have a standard HTML5 video player interface across platforms and just swap out CDMs.

That won't work. If the restrictions module simply hands back the decrypted data then you could just change the browser to dump the data on your disk.

The only way it will work is if the restrictions module handles everything from decryption, decoding, to rendering. Probably even using a hardware DRM scheme and preventing any interaction of the video data with the JavaScript or any other website elements.

If you read the spec: "The Content Decryption Module (CDM) is a generic term for a part of or add-on to the user agent that provides functionality for one or more Key Systems. Implementations may or may not separate the implementations of CDMs and may or may not treat them as separate from the user agent."

So the CDM isn't necessarily seperate from the browser itself - that's left totally as an implementation decision, and at least one widespread implementation (IE11) is integrating the CDM tightly into the browser. Also, even if the CDM is seperate it can render frames directly to the screen without passing through the browser. In particular, note that:

"Where media rendering is not performed by the UA, for example in the case of a hardware protected media pipeline, then the full set of HTML rendering capabilities, for example CSS Transforms, may not be available. One likely restriction is that video media may be constrained to appear only in rectangular regions with sides parallel to the edges of the window and with normal orientation."

So basically, just like with existing plugins, encrypted content is an opaque rectangle plonked on top of the web page that's not part of the browser's normal rendering pathway.

Yes, but it wont be OS agnostic. So it might work on all browsers on Windows but not in any one FreeBSD.

Not true at all, there is nothing in the spec that mandates the use of any particular OS.

But there's nothing compelling plugin developers to support all OS/browser combinations, so no, in practice it likely won't be OS-agnostic.

This scheme basically just creates a special class of plugins; these plugins clearly won't be OS-agnostic, because they can't -- that's the whole point of the exercise: to restrict playback to devices that are fully authorised/controlled from top to bottom, with the browser piping streams from the web to trusted plugins running on trusted OSes using trusted hardware (TPM etc).

Isn't this the same with all software? There is never anything mandating that anybody supports your OS or browser of choice.

If I want to watch netflix or play GTA5 on my haiku box I'm SOL as it is unless there is a business case to be made for doing the port.

This actually makes things easier. For example netflix currently uses silverlight for their streaming, this means that in order to watch netflix you need something that supports the entire silverlight stack.

With this proposal all you need is modern browser and a compatible CDM which is a much smaller chunk of code.

Much smaller, I don't think. It will still have to grab the screen and render directly onto it. It's basically the same thing a regular plugin would do except a little bit of identity validation, from what I understand.

Technically speaking it's almost the same as the status quo, but a little bit of DRM principles have now been enshrined in the foundations of our web. Depending on what your view of DRM is, of course, this is good news or bad news; but from a technical point of view, it changes very, very little.

Indeed, this changes nothing technically. But what it does is harm the idea that standards should promote the the open web. You may or may not agree to this idea of course.

> Isn't this the same with all software?

That's exactly the point, the case is NOT so with HTML and JavaScript. A webapp I write in HTML and JavaScript is OS agnostic!

It's not the same because HTML5 EME is designed to ensure anyone who manages to get media working on unauthorized platforms can be arrested under the anti-circumvention provisions of the DMCA and other similar laws. As in, this was actually one of the stated requirements.

This is simply incorrect, can you show a w3 document that supports this in any way?

Is there anything in the spec that ensures compatibility with more than one OS?

Is there anything in the TCP/IP spec that ensures compatibility with more than one OS?

TCP/IP is an open standard, DRM are not.

Your statement is as wrong technically as stating that encryption cannot be open source. What matters are the keys, not the code.

The purpose of encryption is to secure communications between two trusted endpoints against untrusted intermediaries. Since all parties to the exchange are trusted and the intent is for both parties to have access to the data, an open source encryption system works.

DRM's purpose is similar, but one of the endpoints is in the physical control of an untrusted entity: you. Since the point of DRM is to prevent the user at one of the endpoints from accessing the data, if you have the source and keys to the destination endpoint (e.g. TPM, HDCP-enabled GPU), the endpoint can't be trusted, you can get the data, and the DRM fails at its purpose.