But you can't get a pure HTML5 DRM experience! All the HTML5 bit is, is a Javascript API to a CDM decryptor that is every bit as crappy, proprietary, closed-source, insecure and buggy as Flash or Silverlight.

I'm still unclear as to how users are supposed to get the CDM decryptors. Are they installed like browser plugins? Or are OS vendors going to provide built-in ones for other companies to use?

Either way, the actual user experience is going to be a pure HTML5 player. If I have to install something first, that's unfortunate, but once it's installed I'll never have to think about it again, unlike the current situation where I'm confronted with the crappy plugin-based user experience every time I use the site.

Currently CDM decryptors are bundled with the browser, which in turn is generally locked to a particular OS or device. Browser vendors don't have to provide a way to install different decryptors and many of them aren't planning to.

Also, the actual user experience is not going to be a pure HTML5 player. Since this is intended to support hardware DRM that overlays the video onto the rendered page itself, sites have to assume the video is basically a rectangle crudely inserted into the page just like with plugins. They might be able to overlay stuff like controls on the top using HTML, but it's not clear if they'll even be able to rely on that.

None of the ones that have shipped already are installed like browser plug-ins. The ones Netflix deploys (PlayReady on Windows 8.1 with IE11 and Widevine on Chrome OS with Chrome) are bundled with operating systems and work with the browsers (one per OS) bundled with those operating systems.

Well, at the very least, it's a smaller piece of code :). (Don't get me wrong, I'm very strongly opposed to DRM and HTML5 DRM in particular.)

Maybe compared to Flash and Silverlight because they provide much more. But a CDM module would still have to do all the decryption, decoding, rendering, overlaying the browser window stuff. So it would still be a rather large piece of code.

> Well, at the very least, it's a smaller piece of code :)

I'll grant you that :)

> How is it ruining the web to remove the requirement for crappy (and, at this point, end-of-lifed) browser plugins in order to play Netflix content?

Because then the Web will rely on proprietary binary crappy blobs in its basic functionality. Something which can't be implemented in an open source way. A plugin like Silverlight is no necessity for the web and if Silverlight is crappy and dying then that's really a problem of its users and Netflix. It shouldn't be my problem as a non-Netflix user. If the Web however starts to depend on such a crappy binary blob (which is the result of the EME proposal) then we all have to suffer and it will be a problem for us all.

In other words: If Netflix insists on DRM then they should write their own crappy plugins and applications but not ruin the open Web for all of us.

> You're acting like DRM didn't exist on the web prior to EME, and would continue not existing without EME.

No, we are not. We are just saying that EME will make the open Web depend on crappy proprietary binary blobs and hence no longer be open or libre.

> It existed and continues to exist using proprietary software that is shoved down users' throats.

EME is exactly that! It's proprietary crap software which is forced down everybody's throat because it makes the former open Web depend on it. It's not only something Netflix customers will have to deal with. It's something every web browser and web implementation has to deal with somehow. Which is impossible for open and libre implementations. Thus it will be the end of the open web.