(This is a personal blogpost; it doesn’t represent the opinion of my employer, my wife or my hamster.)
Until now, I hadn’t paid much attention to the details of the DRM extension to HTML (which is actually called “Encrypted Media Extensions” in the same way as some people call a “fart” a “trouser cough”).
This is due to a resigned feeling that, like death and taxes, DRM is inevitable because too many vested interests require it and until it does get specified and implemented, those powerful corporations won’t invest in the not-as-open-as-before Web.
Therefore, I wrote last year “Like an unpleasant medical procedure such as having a catheter inserted, if it must happen it might as well come sooner rather than later.”
I also thought that at least specifying it in the language means that some users won’t be completely locked out (as, for example, Linux users are by Silverlight DRM.)
It turns out that I was wrong.
As Geoffrey Sneddon orginally told me, and Manu Sporny’s review of the specification confirms
The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.
I don’t have a moral problem with DRM. I just don’t believe it works, so it’s a waste of time. But encouraging plugins that will leave some law-abiding customers who want to pay for content unable to do so is the worst of all worlds.
Note to DRM people: I’m patenting the idea of <article drm=”drm”> which will disable copy and paste in the browser and pop up an alert warning people not to copy it. Implement it and feel my mighty lawsuit.