More on DRM in HTML5
(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.
28 Responses to “ More on DRM in HTML5 ”
A couple of things to bear in mind.
As per http://www.microsoft.com/playready/licensing/faq/, Microsft “offer a unique indemnification policy for our licensees on IP.” What this probably means is that if PlayReady, the MS DRM solution (which is pretty much a de facto standard in the digital video industry) is *broken* (that is: someone works out a way to trivially unDRM PlayReady’d videos (because of a weakness in PlayReady, not by stealing keys) then Microsoft are liable for a huge ton of money because they’ve indemnified licensees against that happening. This means that they are likely reluctant to license PlayReady to new platforms, or without due diligence, or in a way that might make it easier to break, or anything that even increases the attack surface, because there’s that risk of going into the hole for a zillion bucks if it is broken. There’s also little to no motive for MS to open source PlayReady; then they wouldn’t get the licensing money from it. This indemnification is likely one of the reasons that playReady *became* the de facto standard. So, given an open source DRM solution, who’ll indemnify studios against it being broken?
Secondly, the web (assume for the purposes of this that we can talk about “the web” as one consistent entity) could take a more forcing approach. Instead of saying “ok, movie people, what DRM solution would you like that we’re able to implement?” and getting agreement up front, the web could define and decide on a DRM solution that the web’s happy with (that is: open source, able to be implemented everywhere, technically robust) and then say: hey, movie people, this thing already exists on a billion web devices and browsers and machines. You’re really going to try and force your own proprietary thing rather than use this platform with incredible reach that already exists?
Historically, the web’s been reluctant to force things in this way — that’s what evil monopolists do, not our happy-clappy flower-power web. On the other hand, is anyone using image formats that aren’t jpg, gif, or png any more? Forcing works.
However, this breaks down when you stop considering “the web” as a consistent entity. For this to work, all the browser vendors have to get on board with the plan. The history of the video element and mp4 support clearly shows that if browser vendors are given a choice between market share and web openness, at least some will choose market share and user usefulness over openness, and the same debate with the same actions would likely play out over a Hixie-mandated DRM solution. There is distinct competitive advantage in your browser being able to play Hollywood blockbusters when others cannot, and at least some vendors will not give up that competitive advantage if they have a choice.
Forgive me if I am being unbearably naive but why don’t they just try a PSK approach? Users are given content signed by their public key?
It shouldn’t matter what the content is: audio, video, text file. Cloud lockers already work like this so presumably it’s just a matter of negotiating contracts so that Google and Dropbox can start offering the service.
The agreement came after Disney’s announcement in November 2012, that it would be shutting down its web movie service Disney Movies Online on December 31, 2012.
[...] More on DRM in HTML5 (Bruce Lawson) [...]
reminded me about old ways of protecting intellectuall property 
http://archive.mises.org/18018/no-wonder-there-was-a-revolution/
and this one:
https://twitter.com/KimDotcom/status/288199968932630528
>> How to stop piracy: 1 Create great stuff 2 Make it easy to buy 3 Same day worldwide release 4 Fair price 5 Works on any device
[...] as Bruce Lawson highlighted in his blog yesterday, there are numerous obstacles to overcome with DRM and it is not without some considerable drawbacks. One thing that particularly springs to my mind [...]
From the EME Draft Specification:
This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.
It is my opinion that continuing to state that this is DRM in HTML5 is perpetuating a falsehood, and is not too far off from calling the authors of this specification liars. I really wish y’all would stop (please) – take this draft spec at face value (and instead of taking others opinions, try reading it!)
*****
@Isofarro
I too would like to see an Option 3-like solution down the road, and rather than whining about how “data should be free” (this isn’t data, its entertainment), those same smart minds should tackle the engineering problem head-on.
*****
@Anonymous Coward
…the web could take a more forcing approach…the web could define and decide on a DRM solution that the web’s happy with…
In many ways, that is most likely what the authors of the EME are attempting to do*. It is my belief that we are best to support those efforts, rather than chase them off, because frankly their working inside of the W3C is the best bet we have that the solution will be community supported (as opposed to wholly proprietary).
(*NOTE, this Draft spec specifically is not attempting to establish a DRM mechanism at this time – read the spec – although it is setting the stage for a possible DRM solution to be established.)
I would bristle however at any suggestion that Hixie would have a hand in this – however I strongly doubt he would even try (it was, after all, he who committed “DRM is Evil” in writing, when this topic first surfaced). I have very little faith that Hixie actually cares about consensus and true “openness” – he will tolerate “open” so long as if fits his personal vision, otherwise he chases nay-sayers away from his WHATWG club. (Case in point, he scolded Steve Faulkner about pointing the WHATWG list to the discussions around changes to <article>, because, you know, it’s questioning his genius…).
After having seen how the sausage is being made in the W3C standards process and the semi-competing WHATWG, there is pretty much no chance in hell that such a standard would ever be implemented (correctly!) by all major browser vendors – which really makes this a very questionable endeavor.
What’s the point of standardizing on a DRM plugin API anyway? We’ll get some new, stronger flavor of what Silverlight currently is, and then what? It still won’t work on Linux, it will work barely on Macs and as far as the actual DRM is concerned it is trivial at this point to skim the movie content straight off the screen buffer, no matter how it got there.
I can forecast one thing for sure after having been around this block a couple of times: Everybody will be inconvenienced by whatever the DRM suppliers would like to have in browsers and the only people who won’t care are the actual media pirates.
@John Foliot,
This whole specification is about creating a DRM eco-system. I think the spec spends a great deal of time weasel wording around the concept of ‘protection’ vs. just coming out and saying that it’s a DRM plugin architecture.
While the proposal states that it is not defining a DRM plugin system, that is by far the primary purpose of the specification. While DRM isn’t explicitly required, that is what is going to use the EME specification. I haven’t seen a single non-DRM use case for EME that can’t be done with the Web stack we have today (or will before EME gets to REC).
The bottom line is that the proposal is about DRM. It’s backers are the likes of Netflix, Microsoft, Google, Comcast, etc. I make no value judgement on DRM – it’s a technology. I’ve built DRM systems. I know that you can’t often get content from content companies without them. I know the specification editors are just doing their job. However, to pretend that the spec is about ‘protection’ and not ‘DRM’ comes across as very disingenuous (criticizing the spec, not the authors).
If the goals of the specification was built around this theme, it would be less bad:
“The Web Platform needs to provide a DRM solution for content companies who believe that DRM is going to help their bottom line and customers that are willing to subject themselves to that DRM. The Web Platform is competing against walled gardens like Flash, Silverlight, and native players. If we don’t provide a solution like this, then content companies will use the more error-prone-stack and security-lax stack of proprietary plugins such as Flash or Silverlight to accomplish their goals. This is the lesser of two evils.” (where the use of ‘evil’ is used in the colloquial and not literal sense of the word).
However, it doesn’t do this and supporters of the specification keep repeating that this isn’t about DRM when it clearly is about DRM.
Hi Bruce,
There is no secret that the proposal is in large part related to DRM. But it’s not about defining a DRM system (or “attaching DRM”), it’s about defining a uniform API that can be used to interact with both DRM and other decryption components. That’s also different from defining a plugin architecture for DRM systems. It’s not assumed or required that CDMs will be plugins of any kind.
This spec neither mandates nor expects a plugin, and one use case is that the Content Decryption Module (CDM) can be actual hardware-based, say for example in an IP-aware television (http://www.google.com/tv/). It might also be added to the stack at the OS level in, for example, set-top boxes (http://www.roku.com / http://www.apple.com/appletv/). To therefore take the leap that this will *always* require a plugin is a leap of logic that defies the facts on the ground today.
The problem is that there has been a fair bit of FUD spread around about this proposed bit of technology (a simple API really) due to some moral posturing around whether or not content on the web should be “free”, as if protecting the distribution of, and profiting from a creative work is somehow wrong. I personally cannot accept that presumption.
I also believe that the problem surrounding digital theft is being conveniently swept under the carpet here. From Pirate Bay and isoHunt to 4Shared and Pastebin (and countless others), there is a systematic and widespread theft problem that is rampant on the internet. “DRM” may have its issues (and I accept that there are issues), but until the engineers that decry DRM can come back with a better technical solution, out-right rejection is not (to me) an option. Failing to work on a technical solution leaves open the door to other types of efforts to control this theft, including SOPA and PIPA efforts, which to my mind are far worse than DRM efforts underway. It comes down to choosing our poison.
The font foundries also gave up on DRM, and appear to be thriving.
Bruce,
So we are a lot closer than some might think. I also think that if platforms are going to have even half-a-chance in building CDM solutions that can work for their platforms, that doing as much of that work inside of the W3C is a far better choice than having that work happen in even more closed environments. At least at the W3C the work is done in the open, and is already covered by patent-troll protection.
Better the devil we know, than the one we don’t. It is primarily for this reason that I supported the CFC to publish this as a FPWD – it is the ‘openess’ process in action.
Cheers mate!
John,
I think (and I’m trying to not wilfully misinterpret here) that you’re underestimating the problem of having a mechanism for substitutable DRM at all. I’m not too sure about the analogy I’m about to make here, but I think it summarises my thoughts. Imagine that, back in the early days of the web, someone had said: hey, there are loads of different image formats. Let’s provide an Image Format Plugin hook in browsers; then, we’ll be able to have everyone implement support for the image format they prefer, and the market will decide which ones are best. Then, MySpace, who are huge (at that point) invent the MySpace Custom Image Format, convert all the images on their site to use it, and do a deal with Microsoft so that IE ships the MCIF image plugin by default. So people posting images from MySpace on Friendster are posting MCIF images, and those unlucky people running Netscape 4 can’t see those images. The web is split in half. I can imagine Bruce saying, at that point: why, oh why didn’t those early web definers just mandate a couple of formats, like JPEG and GIF? Then we wouldn’t have this problem!
Creating a way to plug in everyone’s existing DRM system to the web is *not* a forcing approach. I’m not suggesting that we stop DRM as a concept. What I *am* suggesting is that attempting to work with existing players in this market has not produced anything that will work with the web. So, the web should implement one DRM system that *does* work with the web — it’s implementable everywhere, it’s documented, it’s not under the aegis of one single company, just as all other actual web technologies are — and then once it’s out there and deployed on a billion devices, then say: hey, people who want to protect their creative output, instead of trying to use ten different systems to do that, just use the web! Just like you do for your website!
Nobody decided to publish albums in iTunes because they thought FairPlay DRM was technically superior. They did it because they wanted *some* DRM as a baseline, and millions of users were already using iTunes. Well, millions of users are already using the web.
+1 – Stuart is completely on point on this one.
Although, to be clear, I think at least some of John’s point is that it’s all well and good saying “look, if this web-implementable DRM system existed” but no-one’s actually stepped up to create one, and he’s right. Project Dream attempted to do something like this a few years back, and got adoption statistically indistinguishable from zero and thus was abandoned. Since it *was* open and reimplementable, perhaps it could be revitalised, but I admit that I don’t know enough about the details to state that, and perhaps that I’m making pronouncements while in that position is part of John’s argument (and a correct part, at that).
A Proprietary DRM player uses Proprietary DRM technology to legally unlock content. Implementing the Proprietary DRM technology requires signing a LEGAL AGREEMENT with the Proprietary DRM technology’s owner. The LEGAL AGREEMENT requires, amongst other things, deliberately limiting what the player can do with the content once it is unlocked e.g. watch for 7 days. So Proprietary DRM imposes controls on the content and the player.
An Open DRM player uses Open DRM technology to legally unlock content. Implementing Open DRM technology by definition doesn’t require signing a LEGAL AGREEMENT, so sandal-wearing open source hippies get to decide what the player can do with the content once it is unlocked e.g. make unauthorised digital copies, which is of course what the DRM system is supposed to be preventing.
So Open DRM is a non-starter for people who are pushing DRM at w3c, because they want to limit what you can do with the content after you’ve bought and unlocked it, which requires controlling the player.
@Stuart, @Bruce, @Manu,
What John Simmons said here:
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0011.html
We have 2 choices: allow this work to coninue under the big tent of the W3C, or the players most concerned about streaming their content over the network will go off and do their work elsewere. Moral indignation and outrage will not stop this train it’s already left the station
Stuart, I think you have proposed a great idea, but the problem is, who is working on it? (and thank you for recognizing this problem)
On one hand we have a group of smart, hard-working, task-driven engineers (working inside of the W3C, under W3C patent policy, etc.) that are working on exactly what you want: a broad-based, community informed goal, of which EME is but the first part. On the other hand, we have “The Web Must Be Free” advocates that conveniently dismiss the business need that *is* Content Protection, and start jumping up and down about how evil DRM is, without actually engaging in the discourse with anything particularly useful towards solving the problem.
It is fair to suggest that any current path is a poor path, or the wrong path (XHTML2), but until *somebody* starts blazing and developing a new path, a “better” path, all the anti-EME grandstanding isn’t worth a hill of beans.
There is an old expression (and with no offense intended to you Stuart, Bruce, or Manu) that states “Put up or shut up”.
The DRM in HTML5 discussion is a classic case in point.
[...] now, I …read more From: fever saved [...]
John: Not that you will ever read this, but there is no second part. Google and Netflix are using Widevine as the CDM, why would they bother making anything else, particularly an open standard? That’s the train that has left the station, they can go and play with their own trainset rather than pretending to be open in ours.
An open source CDM is basically pointless anyway, as the whole point of DRM is to somehow work around the fact you are giving the player the key and the content and not letting them decrypt it themselves. No real content that demands DRM would accept it.
Payment online is obviously a business need, but I don’t see HTTP status 402 being used – there are other solutions that didn’t need to be standardised by W3C.
Actually James, I do read follow-up comments.
Question for you: have you bothered to read the EME Draft Specification? Or do you simply take the word of some media and anti-DRM advocates that the sky is falling?
As others have pointed out, one of the goals of rights managements is just that, the ability to manage the contractual rights a consumer enters into with the vendor of digital media (entertainment) – aka Premium Content. Those rights are clear, specific, and detailed: you have the right to view/listen to/consume the media you are licensing (note, *Licensing*, not *Buying*) under an “offer of license“, and you as the consumer have the choice to enter into that contract, or not. It is the content owners however who get to set the terms of that contract (as they own the content), and not the purchaser(*); if you do not like the terms of offer, you can refuse. (This is not unlike purchasing a car or a home except in those types of purchase negotiation, actual negotiation can happen: offer, counter-offer, counter-counter-offer, etc.). The moment you agree to the price however, you are also agreeing to the terms of the contract, so if you “buy” your Game of Thrones DVD for $20.00 (or whatever), then with that purchase you agree to all the other conditions. Read the Fine Print: caveat emptor.
Various *Distributors* of this content, under similar contract to the owners of that content, agree to distribute said content under specific conditions. One of their contractual obligations is to ensure that there is a secure and managed delivery channel, protecting the value and re-sale-ability of that content. The do so using a CDM system, which can and likely will be a closed ecosystem/technology, as there is a need to PROTECT part of that system: Widevine being one such system. However (and this is the really important part) Widevine is not a W3C specification or technology. HOWEVER, with the implementation of EME, *all* browsers can interact with the Widevine system using a common API. How can that be a step backwards?
I get that for a lot of web activists, anything that restricts the end user from manipulating their digital bits and bytes is an affront to their sensibilities. But, please, do remember that the original owner of said bits and bytes have the right to set out the terms of how they share those bits and bytes, and there is absolutely nothing wrong with creating a technology that aids in the enforcement of those rights. The trick, as always, is to make it work as seamlessly as possible for the end user: a goal I believe that EME is setting out to reach.
(* If you are of the mind that this sucks, well, perhaps. But there is nothing illegal or immoral about setting out terms of a contract, as both parties are free to enter into that contract, or refuse to do so. If you really want to change the distribution model, then stop paying for content that uses such contractual models. *DONT* buy Game of Thrones, *DON’T* purchase a Netflix subscription, *DON’T* rent DVD’s, etc. Vote with your feet, don’t whine on about how the W3C is facilitating some kind of evil conspiracy.)
Good to know you do read the comments. I did have a brief of the spec, but once I read the CDM is basically another binary plugin I stopped paying attention. I don’t buy Game of Thrones, can’t subscribe to Netflix (being in Australia), don’t rent DVDs, or consume much media at all. I do use YouTube, but don’t have Flash installed. Despite the existence of YouTube downloaders, the large majority of their users still just use the website, and they continue to make billions in ad money for their content owners.
I see the BBC is thinking of banning AirPlay with its CDM, perhaps because you could send it to a computer running XBMC and capture the output. Why can’t they just rely on the honest user not violating the license agreement instead of persisting with overwrought technical solutions that just harm the user? And suing those who violate that license?
“there is absolutely nothing wrong with creating a technology that aids in the enforcement of those rights.” I guess this is where we disagree. There is something wrong, it’s not totally wrong but wrong enough to be worth fighting against getting into HTML5. W3C is supposed to promote open standards, and while that’s more about process, promoting a standard which explicitly relies on something that can only be usefully implemented by a few parties seems to be against that goal.
@James. Blog post here: http://john.foliot.ca/drm-at-the-w3c/
If the movie industry continue to demand a particular technical solution – without technical merit that leaves a few paths:
1.) Apps: the movie studios will probably head down the native app solution, because much like the “DRM plugin” scenario leads to inter-operability problems if you are not on a dominating platform/device, apps will seem like a preferable alternative towards the facade of keeping iron-tight control over the digital bytes.
2.) A DRM plugin architecture on the web – as Manu correctly points out – creates interoperability problems. As well as intellectual property and licensing issues. This will be a poor cousin to the App approach. So why even bother?
3.) An open standard and open source implementable digital protection scheme, preferably baked into the browser rather than on-top. The movie studios will probably dislike this because they lose their perception of control over their content and delegate it to browser vendors. I guess this can only work if enough independent movie studios play along and reap tidy profits. Then maybe the major movie studios will concede that it is good enough, and worth the relaxing of their iron-tight grasp.
I’d like to see option 3 happen. And we should show a concerted effort to support independent movie studios who embrace this approach. But I fear option 1 is where it will go, again limiting the real practical choice of devices.
(disclaimer: I am employed by an online streaming company, but these are my opinions and thoughts, not those of my employer.)