The thing and the whole of the thing: on DRM in HTML

Bruce Lawson started a very interesting discussion about the Encrypted Media Extensions to HTML a few months ago, with learned and interesting commentary from John Foliot and others. After devoting some thought to this, I believe that the amount of argument around this subject is at least partially caused by its separation of the web from the spirit of the web.

A few things to dismiss first. This is about DRM. John’s technically right that that’s not all that EME is about, but that’s frankly disingenuous. DRM is most of what EME is about, it’s all of what objectors object to, and pointing at the other reasons is like walking into St. Thomas’s Hospital and saying that smoking reduces the risk of Alzheimer’s. It does…but you are missing the point.

Secondly, this discussion is not about whether DRM is a good idea at all. Certainly many people have an opinion on that. It is also reasonable, if you dislike DRM, to believe that EME is a bad idea because it further legitimises DRM, and to make an argument in those terms. But if you fundamentally disagree with DRM then your argument is better directed either at movie studios (to stop them producing movies with it) or at ordinary purchasers (to convince them that avoiding DRM is more important than watching movies). I do not believe that anyone rationally discussing EME is acting in genuine bad faith - there is no big conspiracy here. From what I’ve seen, this is a discussion of pragmatism: given that DRM exists and movies use it and people want movies, is it a good idea to integrate DRM movie playback more tightly with the web? I do not propose that anyone’s sacred right to be heard is compromised: what I suggest is that arguments are best directed against those most able to fix it. If you hate DRM, send your ire against Paramount or your neighbours, not your web browser.

OK, those distractions aside, the point I was making is this: one of the really nice things about the web is that it is set up to be open, and in order to participate, you have to be too. Stuff on the web is available to accessibility technologies; you can read the code that makes up a page; it’s available on many devices including ones you’ve never heard of; it’s backwards compatible right down to text browsers. Of course it’s possible to build stuff on the web which fails to meet these things, but in general, participation in the web means that you’re automatically building something that meets those goals, because that’s built in to the whole concept. There is a reason that the web took off rather than Hypercard or FoxPro. So, historically, “let’s get this new technology onto the web” meant, at least partially, that that new technology would need to become accessible and available to everyone on every operating system and every device and open. So adding a new technology to the web was a good thing for people who wanted to use that technology in places that weren’t anticipated by the tech owners. The web enables everybody; therefore, everybody’s in favour of things being on the web. QED.

The Encrypted Media Extensions are not like that. They are explicitly designed to provide a framework to plug in other technologies, with no guarantee whatsoever that those other technologies are actually available. What this actually means, in practice, is that Microsoft will build a shim layer between EME and the PlayReady DRM parts of Silverlight, and then we’ll be in exactly the situation we are in now: if you have Silverlight now, you’ll be able to use EME then. If you don’t, you won’t. All that’s happened is that DRM plugins have now been blessed as being “part of the web” — PlayReady can now claim to be “HTML5” rather than a plugin. Hooray. What have we gained?

Well, there are some benefits. Given that DRMed video will be available through HTML’s <video> element (I assume), we’ll be able to, say, put that video on the side of a 3D CSS rotating cube, and other similar effects. Obviously not all video manipulation will be possible; at the moment it’s quite easy to digitally manipulate a <video> through a <canvas>, and that’ll have to be stopped if you’re trying to manipulate a DRMed video. It’s nice that DRMed video will at least partially be part of the HTML world rather than siloed off in a little plugin window.

However, I don’t think that that justifies the work. Adding EME to HTML will mean that everyone who can already watch Harry Potter movies can continue to watch them. It will not extend this any further; it will not widen the viewing audience; it will not decentralise the control; and it will divide the web further into the haves and the have-nots. One of the big reasons that the web is a good idea is that it stops there being any have-nots. EME bringing DRM to <video> will stomp all over that. There is no difference, none, between a a <video> tag which requires a platform-specific plugin to work and an <object> tag which plays a video and requires a platform-specific plugin to work. The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised? The goal wasn’t “get everyone on the web”, it was “bring knowledge and entertainment and everything to everyone”, and the web was the best way to do that. If getting the “everything” means giving up on the “everyone”, we’re doing it wrong.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • A response was written at Higher standards ( Many people are—quite rightly, in my opinion—upset about the prospect of DRM landing in the W3C HTML specification at the behest of media companies li…