W3C’s work on HTL5 and the Encrypted Media Extensions specification keeps drawing criticism and controversy. I spent today attending Amelia Andersdotter’s event at the European Parliament in Brussels about HTML5 and DRM, as an interested individual member of the W3C community who doesn’t speak for anyone but myself.
The topic is fraught with controversy: The W3C Director found “Content Protection” to be in scope for the HTML Working Group; the deliverable that the group is working on under this heading is EME. The specification itself defines a reasonably simple JavaScript API that permits a Web application to hand key material to a Content Decryption Module (the actual DRM black box). The general API leaves the nature of the key material unspecified; in the general case, that’s likely to be key material that is by itself encrypted, and not accessible to the browser. The EME spec defines one very simple CDM, Clear Key, which assumes that key material is accessible to the Web application and the browser (therefore, to the user); this is the sort of not- really-DRM that will later on permit the HTML WG to demonstrate interoperability of the API without having to dive into proprietary CDMs.
As far as it’s discernable today, EME has significant implementer interest; the motivation there is, of course, to use it as an interface to connect proprietary DRM systems with the Web. As with any controversy, there are plenty of confusing points to go around.
On fundamentals, some argue that content protection is, basically, the same thing as password protection for content that you buy for, or a paywall, or perhaps encryption of confidential material online. That’s a false equivalence: The commercial driver for standardization of EME are existing DRM systems — the proprietary CDMs that I mentioned above. The attacker against whom content is protected is the user (and the browser code, which could be under the user’s control); the attack is use of content in a way that isn’t explicitly authorized by the rights holder.
The DRM systems used in this context cannot be implemented in Open Source, they are typically patent encumbered, and they arguably are corrosive to the notion of putting general-purpose, modifiable computing into users’ hands. And while it is conceivable to build a watermarking-based system on top of EME, that would sound like a pretty awkward approach, and it isn’t why implementers are interested in EME.
All of that, however, doesn’t mean that EME (the interface) can’t be implemented in open source: EME, together with the ClearKey CDM that’s part of the specification, should be implementable in Open Source software, without royalty, just fine. It just doesn’t provide the protection that rights holders are after; the real deployment of EME is as an interface toward proprietary CDMs that are implemented in closed source software, and partially in hardware.
Some proponents of EME try to make it palatable by pointing out that, just maybe, it could help users protect the privacy of their personal information online — we heard that argument today. That doesn’t sound like it’s very plausible: EME is a pass-through API for browser implementation, tightly coupled to inline media elements in HTML. The basic model is actually very simple. Now, it is true that some in the privacy community have looked at policy enforcement using trusted computing mechanisms. But it doesn’t look like EME specifically, or the CDMs it interfaces with, are even in the same ballpark. I respectfully suggest that we just drop that part of the conversation and focus on the actual reasons for deploying EME.
Another argument that is frequently made is that, because EME is made part of a core Web technology (HTML5), “browsers do not have a choice.” That isn’t exactly true, either: EME is a separate spec from HTML5. The two documents can go to W3C Recommendation (or not) independently of each other. Just because somebody says they implement HTML5, that doesn’t mean they have to implement EME. That debate, however, is ultimately a debate about words, not about substance: The deployment driver is the desire to provide playback of DRMed video content, not the exact nature of the API spec, and how it is split across different documents.
The real focus of the discussion, then, ought to be on the merits (or not) of what EME actually is: A carefully scoped interoperability layer on top of existing, proprietary DRM systems, to enable the designers of Web applications (think youtube, think netflix) to pass key material to these CDMs in a way that’s interoperable across multiple browsers. That abstraction layer doesn’t “do” DRM; it can probably be implemented in open source software without royalty; but it isn’t very useful unless we end up in a world with a few widely implemented CDMs that ship with browsers across different platforms, and for which “protected” content on the Web is encoded.
Some of the questions to ask in this context: If EME is successfully standardized by W3C and broadly deployed by browsers — is that, by itself, an improvement over a future in which either of these (standardization, deployment) doesn’t happen? What would other plausible futures for EME or, more generally, for DRMed content sold today even look like? By what criteria would we evaluate those? What’s the impact of these futures on large content providers, small content providers, browser vendors, and innovation for the network?
How does that reasoning change if we assume either of EME being the end of DRM integration into the web platform, or EME being the beginning of DRM integration into the web platform? And which of these is more likely?
What is the weight that we might assign to “goodies” that could come with EME? For example, open APIs further down in the stack (between CDM and browser), or additional transparency into the DRM hat gets deployed on the Web? And what is the weight that we might assign to side effects of DRM deployment through EME — such as, perhaps, additional privacy concerns, and serious accessibility issues?
Finally, what does this entire discussion say about the governance model that we collectively want to apply to Web standards — how do we collectively reconcile between W3C as a member-driven organization, its accountability to the broader public, and its stewardship role for the Web?
No Such Weblog 
“Finally, what does this entire discussion say about the governance model that we collectively want to apply to Web standards — how do we collectively reconcile between W3C as a member-driven organization, its accountability to the broader public, and its stewardship role for the Web?”
=> I’m afraid you’re mistaken in the role the W3C plays. The W3C is a restaurant:
http://longtermlaziness.wordpress.com/2013/10/08/the-w3c-is-a-restaurant/
It’s been confirmed by Tim Berners-Lee:
“W3C does not and cannot dictate what browsers or content distributors can do.”
http://www.w3.org/blog/2013/10/on-encrypted-video-and-the-open-web/
“If EME is successfully standardized by W3C and broadly deployed by browsers — is that, by itself, an improvement over a future in which either of these (standardization, deployment) doesn’t happen?”
=> EME will be successfully deployed in IE11 and Google Chrome. It’s not an “if”, it’s a “when”.
http://blogs.msdn.com/b/ie/archive/2013/09/05/online-professional-quality-video-premium-media-experiences-without-plug-ins-in-internet-explorer-11.aspx
I follow EME-related bugs on Chromium. The latest commit happened a couple of minutes ago and was related to this bug: http://code.google.com/p/chromium/issues/detail?id=307745
It’s happening. Browser deployment happens regardless of W3C standardization. It is a waste of time trying to think of a future where EME might not be deployed.
Whether EME would better be standardized at the W3C than not: yes. At least we sort-of know what’s going on and can write blogposts about it 🙂
Very good post!
Because EME is all about plugging into existing DRM systems I don’t expect DRM interoperability to improve at all.
We have Apple FairPlay vs Microsoft WindowsMedia vs Google WideVine and all of them have competing platforms and stores, so lack of interoperability is not technical — it’s business.
Can you imagine iOS Safari shipping with Microsoft’s CDM plug-in? Or Apple licensing FairPlay CDM plug-in to Android vendors? (and desktop Linux is totally screwed as usual).
If OS vendors keep hating each other we may end up with Netflix DRM plug-in, Hulu DRM plug-in, etc. — every website requiring browser vendors to bundle their own proprietary CDM black box that can do whatever it wants.
At best Adobe will leverage their neutral status, existing streaming DRM server business and remainder of Flash install base to ship their DRM CDM plug-in to everybody, and yay, we’ll have Web video dependent on Adobe’s proprietary system-specific binary blobs again.
I am glad to see some reasoned thinking and questioning happening here, even if, from my perspective there seems to be some flawed assumptions going on.
First, you are not the first to bring up the notion that, somehow, EME (and Content Protection delivered via EME) might have some “serious accessibility issues”. This is, frankly, a huge red-herring and borders on fear-mongering. As a 13 year veteran of Web Accessibility, and an active participant of the HTML5 Accessibility Task Force at the W3C, I can say that the members of that task force have looked at, and inquired around any potential accessibility issues related to this topic. While there might be an extreme edge case possibility of some inconvenience, there is NOTHING related to EME or the idea of connecting the smaller CDMs and smaller footprint of the proposal that would have any real accessibility issues. In fact, when the browser and HTML5’s element are the default media player, the user controls will be part of the browser, and not the encrypted content being rendered inside of the browser. This is significantly different that dedicated “video” players of the past, that allowed for both recording playback in a dedicated hardware device. Frankly, author created, JavaScripted controls have a greater chance of introducing accessibility issues than using the existing native control that ship with the browser, and neither really have anything to do with the rendering of encrypted media.
Secondly, you pose the question: “(What) if EME is successfully standardized by W3C and broadly deployed by browsers…”(?)
I suggest that with or without the involvement of the W3C, EME is already being standardized (2 of the 3 engineers attached to the EME spec work at Google and Microsoft), and further, is being implemented into the browsers already. As a stanch supporter of the W3C standards process, I also accept that web “standards” are not the exclusive purview of the W3C – other standards bodies also have significant roles in the standards soup that is the modern web today: IETF for the http protocol (http://tools.ietf.org/html/rfc2616), ECMA International for ECMA-Script (aka JavaScript – http://www.ecma-international.org/ecma-262/5.1/) as 2 key examples.
The point is, none of the browser vendors *need* the W3C’s permission or involvement to implement a specification, nor do they need to work inside of the W3C to come to an agreement of interoperability. I believe that there is *value* in working inside of the W3C, due to the patent policy and transparent standards process that the W3C have in place, but the finger-pointing and accusations that somehow this is a W3C problem in the making, or that the W3C can somehow stop this work from happening is simply both naive and misguided. I believe that the W3C has a role to play here, but that role is not as the go / no-go deal broker or controller, but rather as a body that can help guide and shape EME to ensure that it’s footprint, its impact on users and interoperability, it’s security and yes, it’s accessibility – all of these issues the W3C can help guide to get the best we can hope to get. Encrypted Premium Media Content on the web is not going to simply vanish, or cease to exist if the W3C stops working on EME today, and that is a truth that many simply must accept, including anti-DRM advocates and European parliamentarians alike.
Thanks, John – I hadn’t been aware that accessibility review for EME had happened. Got a pointer to that analysis?
There’s a good discussion about it on the W3C mailing list (see http://lists.w3.org/Archives/Public/public-restrictedmedia/). John’s right: the W3C is paying particular attention to accessibility here, unlike other DRM schemes.
Mind you, as I’ve said, enhanced accessibility doesn’t alter the fact that DRM, and thus EME, is inimical to several of the W3Cs stated goals, and its mission.
The concerns about accessibility were not based on the accessibility of native controls of the video element, but on the fact that
a) JavaScript APIs may be blocked, so customized controls like Easy YouTube will cease to function. The plugin content is even unavailable for CSS styling! Do you remember the times when Flash content was always on top? I wouldn’t like to see this repeating.
b) The WIPO Marrakesh Treaty exempts people who are blind, vision impaired, or otherwise print disabled from the WIPO Copyright Treaty. I would assume that DRM must provide exemptions for those people, otherwise it violates the treaty.
Nice post.
First, as the person who introduced the argument about DRM being used to follow users’ data, I agree that it doesn’t look anything like the existing EME proposal. Which is why I stated that I didn’t want to dangle it as a “the future is rosy”, so much as a “DRM may not be all evil”. Which incidentally is about as far as I get as a “DRM proponent”. As I have said before, I don’t think DRM is intrinsically evil – although it is unfortunately true that modern implementations seem only to be made for bad reasons. Anyway, I’m happy to leave the data protection discussion out of the EME-specific debate for now.
I don’t quite agree with my good friend John Foliot that accessibility issues are a red herring, although I don’t think they are a reason to oppose the existence of DRM per se. As an example, as far as I know, Netflix ships captioned video, and keeps the captions in the clear so anyone can use them. This is important – if some component of a package that was required for accessibility was only available to an inaccessible player, we would have a real practical problem (and potentially a legal problem, given a treaty made in Morocco on copyright and access for people with disabilities a few years ago).
Which brings me to the crux of the issue. DRM is a technical way to enforce certain principles that are defined in law and “moral codes”. Some of that law is good*, some bad, but the point is that laws should not be written by unelected technical committees. They should be written by the societies to which they apply. And they should cover not only the rights of people who want to “protect” their content, but also the rights of people who have offered something (money, all their personal data, membership in a club, …) in exchange for the right to consume that content.
Attempting to regulate away the existence of DRM is, in my opinion, both a fool’s errand and unreasonably extreme. The unintended consequences are hard to predict – a drop in the outrageous salaries of Hollywood superstars won’t make me lose any sleep (despite the likely knock-on effect flowing from the collapse of the super-luxury housing market), but making it unfeasible for anyone but a major studio to recoup the cost of making a movie would IMHO be terrible.
On the other hand, I strongly support regulating the functioning of DRM to ensure, for example, that people with a disability can get access to content on the same terms as anyone else, or that your ability to exercise rights to use content isn’t extinguished by an accident such as the Key provider’s server catching fire, or the company being sold to a wrecker. The difficulty with this, of course, if getting the regulation right. Lawmakers are not famous for having as good a grasp of the technical realities as they are of being swayed by lobbyists representing people with a lot of money, and technical people are not famous for being able to explain to lawmakers the real implications of technology and the real impact different regulations might have on an industry.
Which is why I am very grateful that Amelia took the time to bring these elements together and try to bring about some rational discussion that could lead to sensible outcomes, and why I was happy that at the last minute, when I found out about it, I could actually get to the event. Although I hope next time there are easier ways to participate in this discussion 🙂
I suspect that any sensible outcome is likely to take a lot longer than anybody wants. But even that seems great compared to the current climate of anti-DRM lobbyists trying to shoot all the messengers (and then in the worst case going home to watch DRM’ed content through Youtube, or to work for companies who are building DRM into the Web platform), and DRM simply being built into systems with a minimum of actual technical and legal input from people in a position to give it, while people who try to strike a path anywhere between the two poles often seem to believe they will be destroyed in the crossfire between the extremists if they honestly and openly speak their minds.
Just my personal 2 копейки.
chaals
*Yes, DMCA, I am calling you an abomination and thereby implying that the people who further your reach by attaching you to trade treaties are doing something very bad)
@kornel,
I agree the the drivers for interoperability aren’t obvious, and most CDM producers are likely to promote *their* solution. If they are also big-time content producers, there would be a natural tendency to use that position to stifle the competition.
But there are a couple of other drivers for interoperability.
Users get sick of dealing with multiple systems, which eventually leads to a “natural monopoly” (e.g. VHS videos), although hopefully one that doesn’t try to extract monopoly rents from that position.
There is also law against anti-competitive behaviour. It is slow, but eventually it can often work, and continually defending cases on that basis tends not to be good for a company in the medium-long term, so they either change their behaviour, or lose out (or both).
Neither of those are foolproof solutions of course. We’ll see what happens in reality…
And finally given that key systems are not that complicated, it is probably technically feasible to “ship ’em all together”. I’d be intrigued to speculate on the impact that will have on the drive for interoperable video (etc – I think anyone who thinks DRM is only interesting for video producers isn’t looking carefully at the real world), because an architecture that allowed a CDM to hand off to a trusted video codec might make sense to some key players. Or not…