Sure, but we don't have to aid them in their quest

>The overwhelming majority of content on the web is DRM free. These proposals do not mandate nor give any incentive for that content to be protected if it is not already.

The practical effect of being able to deliver DRM'd content to every non-technical web user, without first having to get that user to download and install your proprietary software, is just massive. This is one of the biggest falloff points in the conversion funnel, so it makes this new delivery method highly attractive. As it is now, businesses have to balance the cost of losing customers against the cost of not being able to DRM their content. Take that dilemma away and I think you certainly have a new incentive. The practical effects of this are far reaching imo.

And the businesses (Hollywood) with the content that Web users want have done that math and decided that DRM through plug-ins and native apps is an EXCELLENT system and they're happy to keep mandating it forever. If Plug-ins go away, as they're slowly but surely doing, then native apps will be the only place to get this content.

Hacker News types, myself included, will cringe at this truth, but most consumers don't give a shit about the Web. They care about the content the Web gives them. If the Web cannot give them the content they want, they'll get it elsewhere, probably from silo'd App Stores where things "just work."

And in this scenario (i.e., the way things are now), someone like me, who doesn't give a shit about "content" but does care about the Web itself, can still avoid DRM by not installing the plugins, not using the silo'd App Stores, etc. But if my browser is the silo'd plugin/App Store, I'm SOL. That is why all this matters: it makes DRM and all of the closed source nastiness that goes with it the default, instead of something people have to choose. I think that's a very, very bad idea.

EME is not strictly DRM in your browser: it's a standardised interface to allow your browser to talk to DRM modules.

I don't cringe at that, it's just the way it is. But I promise you no-install browser delivery of DRM'd content which "just works" is very valuable to those businesses. People grab the thing within arm's reach. Sure, if there isn't anything in arm's reach a decent amount of them will still walk across the room for what they want, but I think that's besides the point.

> get it elsewhere, probably from silo'd App Stores where

> things "just work."

That's entirely reasonable. Silo'd 'app stores' are where things like DRM belong, not the World Wide Web.

Perhaps there exists a class of people who wanted to implement DRM on all of their content but were just waiting for the W3s blessing but such a class will be extremely small.

Most of the DRM you see comes from mandates from big content firms, most other people could give less of a shit.

Try exercising your fair-use rights on those DRM'd bits for example.

If anything this is worse than proprietary plugins because those used documented APIs that any browser could support, whereas this is integrated into the web browser itself.

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.

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.

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.

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.

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

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.

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.

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!

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.

But more importantly the idea of HTML5 was to get rid of proprietary closed source plugins like Flash. Adding DRM to HTML5 will make it rely on proprietary closed source plugins.

I hope the W3C reconsiders. If somebody feels the need for DRM then they should implement their own stuff outside of the open web.