EME at the W3C

There’s an ongoing kerfuffle about DRM (Digital Rights Management) being implemented in browsers and whether the W3C should publish a standard (‘recommendation’) that provides access to DRM content.

In case this goes wider than my usual audience of about a dozen people, I should make clear that:

• I don’t like DRM. It is a silly technical solution that doesn’t actually protect content. The way DRM interacts with laws is also pernicious, in that laws such as Section 1201 of the US’s DMCA make illegal some things that should not be. Personally, I won’t buy DRM content unless I know how to ‘archive it’ without the DRM. (That doesn’t apply to ephemeral streaming services where you subscribe to a varying collection, I don’t have a problem with that as a deal.)
• My reason for being involved at the W3C is web accessibility, a domain in which I’m rapidly heading towards 20 years of experience.
  I won’t claim to be a video or DRM expert, but I have followed the arguments about it since the EME work was announced.

The key specification is Encrypted Media Extensions, the main point of which is that EME is an API to a DRM module (which isn’t covered by any W3C spec).

For background, I would read Tim Berners-Lee’s post about it. To understand the objections read the EFF’s appeal against publishing EME.

What good is EME?

Given my stated position on DRM, it should be an easy decision to oppose EME, right? Not so fast, you have to consider the alternatives.

There is so much pressure for DRM from ‘rights holders’, they really won’t put movies on the web without (the emperor’s new clothes of) DRM. In a branch of reality where EME never happened at the W3C, Flash/Silverlight would still be going, or a similar plugin replacement created.

If Flash were still plodding along providing browsers with a method of doing DRM video, how is that better?

EME was the last nail in Flash’s coffin, which is the best outcome for a11y.

The browsers might have replaced the NPAPI interface that they hate so much (for good reason), but something would have been used to consume DRM video. If that was done outside of the W3C it would have been messy, the browsers would each do their own thing (a worse outcome on every measure) or come together at another standards body. It’s a JavaScript API, so perhaps ECMA?

I’ve seen comments saying that the rights-holders wouldn’t turn away 1 billion web users, but they wouldn’t have to. Their video would be available through devices and set-top-boxes (with DRM) to probably 90% of that billion users. I think the browser makers saw that and would rather there were an option for ‘premium’ video on the web.

For example, if you want to watch Game of Thrones in the UK on your computer, the only legal place to do that is at NowTV.com (owned by Sky). Once subscribed you browse to the programme page, and you have to install a dedicated app, which then pops-up when you click on the programme. So now I have an app installed on my computer instead of watching it in the browser, which sucks.

I’ve spoken to people at broadcasters and an online video service and they were clear that DRM was going to happen somehow. There is research that shows piracy doesn’t appear to displace music & book sales, but it does impact new movies significantly which is the focus of EME.

The bottom line is that: On an open platform, you can’t ban something that the content-owners require and (most of) the public want to use.

What are the problems with EME

Cory Doctorow outlined several issues, I’ll use that numbering with shorter titles:

1. Security

This is the most concerning issue, which is that security researchers are preventing from finding and reporting issues with the DRM. That research is being prevented by the laws about DRM, rather than EME (the API to the DRM).

There was a large effort to create a covenant to protect security researchers, but no middle ground was found. For the engineering-types who represent companies at the W3C, they would be taking this covenant back to their company’s lawyers. Those lawyers would then be saying things like “So we have to agree not to sue someone breaking into our technology? I don’t think so.”

I would certainly like to see some compromise there, but it seems unlikely so the question then becomes: Whether to publish the EME spec or not?

2. Accessibility

The EME spec & implementations actually improves the general situation for accessibility (W3C commentary), as part of the W3C process there were several rounds of accessibility reviews.

Therefore the issue raised is around a new aspect of “automated generation of accessibility metadata”. For example creating a filter to detect flashing content:

Applying such a filter to (say) the entire corpus of videos available to Netflix subscribers who rely on EME to watch their movies would safeguard people with epilepsy

Regardless of DRM, does anyone really expect Netflix to open up their entire corpus of video to anyone? That is not how wide-spread accessibility has worked in a multimedia context. If there were such a tool (which could be developed using the <video> element without DRM), it would have to be Netflix that runs the script and provides the metadata via their player. There is no way they just open up the vaults.

The way that multimedia accessibility (which is an intensive production process) has worked historically is that a solution (e.g. audio description, captions) is either known or created, and then regulators insist that the providers use those solutions. The good thing is that there is a lot of overlap between companies creating the automated / machine-learning processes are the same ones that provide video and/or DRM modules.

Would it be a better world if anyone could run through the entire set of videos on Netflix/iPlayer/Amazon/HBO etc? Yes. But that wouldn’t happen in any branch of reality where those companies exist as profit making entities.

The intrinsic problem for things like applying filters is with the DRM that encrypts the video, not the API to the video in the browser (i.e. the EME spec). What the EME spec does do is protect access to alternative formats, which wouldn’t exist if we were still using plugins.

It has been suggested that a covenant could protect people who bypass the DRM for accessibility reasons (e.g. to apply filters). However, a DRM bypass could then be used for any reason including piracy, so the DRM provider would have to shut it down. It is similar to the arguments about “back doors” in encryption, you can’t have one without anyone being able to use it eventually. The method of shutdown might be technical (close a hole/bug) or legal (sue the person bypassing DRM), but the bottom line is that a DRM provider cannot sign up to a covenant that forces them to ignore holes in their DRM.

If you consider the alternative (realistic) possibilities, web accessibility is in a better place with EME.

3. EME essential to new players

I struggle with the logic of this one, I think the crux is:

EME’s existence turns on the assertion that premium video playback is essential to the success of any web player. It follows that new players will need premium video playback to succeed…

You could argue that access to premium video content is essential to any new web video player (browser?). That content relies on a DRM module so you are beholden to the people providing DRM. The existence of EME should make that process easier, not harder.

To EME, or not to EME?

People seem to think the W3C is creating a spec to put DRM in browsers. This is fundamentally untrue in several senses.

Firstly, the W3C is like a restaurant:

It has a lot of tables, it has a bunch of people paying to be here and discuss at the tables. The W3C at occasions moderates discussions, but that’s its only impact on the web platform. The people around the tables make the decisions, not the restaurant.

Secondly, the browsers implemented EME several years ago, the standards follow implementations.

DRM in browsers was there before, and it will continue to be, so the question is whether to publish the EME spec.

Overall, I don’t think it makes a huge difference either way, but the world will be a slightly better place with an standardised JavaScript API to DRM.

The world will be a much better place if the laws that enforce DRM are re-written, and I support every effort in that direction at appropriate venues.