Bruce Lawson's personal site

On DRM in HTML5

This week, I went to speak at Apps World, a great big “Global Developer Event, Mobile Marketing Conference” (according to its site). It was at Earls Court, full of people in suits (6000 attendees) and there was an average of 9.6 synergies per square meter.

As I was waiting for my panel, I listened to the preceeding talk “Is HTML5 the future?” (answer: “yes”). The first question from the audience was about when Digital Rights Management (DRM) will come to HTML5 “so my company can start using it”. Many of the other attendees were nodding their head in agreement.

At the end of my panel, the moderator Robin Berjon asked us “which feature would you like to see come to HTML soon?” and I rather surprised myself by answering “DRM”.

I don’t want DRM. I dislike DRM. Not particularly because I think everything should be free (I don’t; I like receiving royalties for the best HTML5 book) but because I don’t think it works. The DRM graveyard: A brief history of digital rights management in music demonstrates this excellently.

However, “the suits” believe it does work, and aren’t willing to invest fully in the web stack until there is some attempt at DRM. That’s why Netflix, Google and Microsoft have proposed the Encrypted Media Extensions specification that’s being worked on by the Encrypted Media Task Force of the HTML Working Group at the W3C.

Currently, DRM for video is the province of plugins. About a year ago, Lovefilm moved from Flash to Silverlight:

We’ve been asked to make this change by the Studios who provide us with the films in the first place, because they’re insisting – understandably – that we use robust security to protect their films from piracy, and they see the Silverlight software as more secure than Flash.

Simply put: without meeting their requirements, we’d suddenly have next-to-no films to stream online.

This is a problem for Linux users, as Silverlight doesn’t work on that operating system. It’s potentially a problem for Opera users, too, as Opera isn’t officially supported by Silverlight (although it does work). At least if DRM is moved into HTML rather than plugins, people using smaller browsers or operating systems will be able to choose whether or not to view DRM content. Now, they don’t have any choice at all.

But philosophy aside, ultimately, DRM in HTML is coming. WebKit appears to have started work on it 6 months ago, and Microsoft will presumably add it into Internet Explorer. And if those two giants support DRM, which browser would dare not to support it, and potentially be blocked by video sites? It’s like h264 on mobile: nobody likes it very much, but it’s a reality.

Like an unpleasant medical procedure such as having a catheter inserted, if it must happen it might as well come sooner rather than later.

(This is a personal view and does not reflect that of my employer)

Also see More on DRM in HTML5 in which I belatedly realise that the spec is just a plugin architecture.

(Last Updated on )

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

12 Responses to “ On DRM in HTML5 ”

Comment by Geoffrey Sneddon

However, the current W3C proposal is scarcely a standard: all it defines is a new plugin API, just for video. This means that if you use any non-standard platform, odds are vendors won’t bother providing any “module” for your platform. It buys us little in terms of advantages over the current plugin-based model.

Comment by Paul McClean

Hi Bruce,
Whether you personally like it or not, the rights holders (i.e. the people who hold the keys to video and TV content distribution on the web, i.e. movie studios, TV producers) contractually require content protection for their intellectual property. It’s not something that is tagged on to a contract as an afterthought, they’re iron-clad requirements with very specific detail on encryption levels, SWF verification processes etc.

Without meeting these requirements, the simple fact is that content will not be made available for the web. This is not good for anybody.

Yes, it might be akin to an unpleasant medical procedure, but it has to happen if sites like Netflix, Hulu, BBC iPlayer, RTE player want to truly live within the HTML5 ecosystem.

Incidentally, I was at the workshop in London last week. Thanks for the presentations.

Comment by Bruce

Paul, I’m sorry my meaning is unclear. I don’t like DRM. But I acknowledge that the Suits (the rights holders) love that stuff. So it might as well happen.

We agree, I think.

Comment by Biggles

Ffffff owners of the world in my computer… the last line of defence. Hopefully someone will make a chromium build that drops this feature.

Comment by Oren

Hi Bruce.
I attended Appsworld conference too – also as a speaker in the html5 track.
I agree with you view about DRM. As far as it seems – there will always be the counterpart to DRM – as creators and artists tend to release their works free to the public.
I too, hope, that DRM won’t be in much use and that the “open web” concept continues to grow as an open service.
thanks.

Comment by bill

So, DRM doesn’t work. It only serves to annoy honest customers, and does nothing to slow down the others.

And yet, you want it because some clueless “suit” thinks it works?

Do your job, man, and educate your management on how things actually work! On what does work (great products, reasonable prices), and what doesn’t (treating customers like criminals).

There is always someone to get behind the stupidest idea, but, like the emperor of old, they’re wrong.

Comment by Jaz Lai

My spouse and I absolutely love your blog and find the majority of your
post’s to be exactly what I’m looking for.
can you offer guest writers to write content available for you?
I wouldn’t mind producing a post or elaborating on most of the subjects you write about here. Again, awesome blog!

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.