|
|
Subscribe / Log in / New account

Encrypted Media Extensions and exit conditions

By Nathan Willis
June 15, 2016

In March, we reported on the contentious argument surrounding the Encrypted Media Extensions (EME) framework developed by a working group at the World Wide Web Consortium (W3C). At the time, there were several active protest efforts underway to dissuade the W3C from renewing the charter for the working group in question, since that renewal was slated to come up for a vote soon. Since then, although public activism has quieted down significantly, there have been several important developments.

To recap, the EME framework defines a set of APIs for Content Decryption Modules (CDMs) that implement some form of authentication scheme used to enable or disable playback of <audio> or <video> elements. While there is a simple, plain-text CDM defined in the specification (and even though open-source CDMs have been developed), the ultimate goal of EME is to allow media-delivery companies like Netflix or Hulu to deploy proprietary, binary-only CDMs that implement a DRM scheme.

The W3C's oft-stated position is that defining the EME framework in the context of other W3C web standards is better than staying out of the discussion, which would merely encourage media companies to implement their DRM playback modules through other means—such as in Flash or Silverlight. The limited API of a CDM, according to this line of reasoning, is less harmful than the security-hole–riddled Flash virtual machine and, furthermore, by engaging media companies directly the W3C can have a positive influence.

A number of outside groups take strong exception to W3C's position and object fundamentally to the inclusion of any DRM-supporting technology in a web standard. First and foremost among the critics is the Electronic Frontier Foundation (EFF), which led a campaign in January to persuade the W3C to adopt a "nonaggression covenant" on Digital Millennium Copyright Act (DMCA) litigation before it renewed the charter of the HTML Media Extensions Working Group, the group developing EME.

Charters

Like all W3C working groups, the Media Extensions group operates under a time-limited charter. In March, a W3C members' meeting was held, during which the group charter was scheduled to come up for renewal. The EFF pushed to have that renewal tied to adoption of the DMCA nonaggression covenant. But, despite several public declarations in support of the EFF's proposal (and some well-publicized protests by other DRM opponents), the Media Extensions group's charter was extended through September 2016.

The W3C blog records that the covenant was discussed at the meeting. The exact events that took place leading up to the renewal, however, are not public. In a June 6 blog post, EFF's Cory Doctorow wrote that:

Enough W3C members endorsed the proposed change that the charter could not be renewed. After 90 days' worth of discussion, the working group had made significant progress, but had not reached consensus. The W3C executive ended this process and renewed the working group's charter until September.

Similar wording is found in an April EFF blog post, attributing the renewal to "the executive of the W3C". In both instances, the phrasing may suggest that there was considerable internal debate in the lead-up to the meeting and that the final call was made by W3C leadership. But, it seems, the ultimate decision-making mechanism (such as who at W3C made the final decision and on what date) is confidential; when reached for comment, Doctorow said he could not disclose the process.

The W3C announcement did not address the details either, nor did the renewal notice sent to the working group's public mailing list. That notice pointed readers to another, W3C-member-only mailing list. Nevertheless, the blog post announcing the charter extension did acknowledge that there are security implications to EME. In particular, the concern for security researchers is that disclosing vulnerabilities in EME or in a particular CDM would result in prosecution under the DMCA. Although that argument found traction at the W3C, the blog post directed interested parties to a new, still-in-development working group meant to host discussions over W3C policy, rather than encouraging such debate within the Media Extensions group.

Round two

For its part, the EFF has moved on to target the working group's new charter-renewal date in September. As Doctorow explained in an email to the Media Extensions mailing list, the new plan is to make the nonaggression covenant an "exit condition" of the working group—meaning that "EME would not become a W3C recommendation until the group agreed to some covenant". The new proposal does not mandate that the covenant adopted be the one written by the EFF, just that it address the same issues.

In addition to protecting security researchers from DMCA prosecution for disclosing flaws in EME, Doctorow said, the nonaggression covenant would protect interoperability between implementations.

The reason for including interop in the covenant is that, unlike other W3C recommendations, EME will limit interop to browsers that have explicit deals with publishers -- that is, the publishers will have to bless an element of the user-agent (the CDM) for the user-agent to render its content.

This is a new step for the W3C, and for the browser ecology. It's true that the Web allows servers to distinguish among clients based on things like auth tokens (my bank's web-server won't let your browser see my account details), and of course browsers have always been able choose not to implement the decoding or display of certain content. But this creates a new situation where only certain implementations of otherwise identical user-agents are acceptable; that choice is determined by publishers and enforced by law.

In other words, there are two interoperability concerns. First, a fully EME-compliant browser may not be able to play any EME-protected content, because playback is actually dependent on the publisher's choice of CDM and, importantly, the publisher can choose to block any browser for any reason.

If a particular browser's EME implementation is discovered to perform an operation not authorized by the publisher(such as to allow users to pause playback, store content for later viewing, or even provide accessibility features), the publisher can block the browser in question in the CDM module. Second and more serious, because the CDM is an "anti-circumvention" tool, the publisher can also sue the browser vendor under the DMCA.

Doctorow subsequently proposed adding a discussion of the DMCA nonaggression covenant to the working group's timeline. However, the working group's chairman, Microsoft's Paul Cotton, refused the request outright:

Discussing such a proposed covenant is NOT in the scope of the current HTML Media Extensions WG charter. If the W3C Director has wanted the HME WG to take on this task when the WG was re-chartered on March 31 I am sure he would have added this dependency to our charter.

Perhaps that reaction is to be expected; a quick survey of the working group's mailing list archive reveals that few if any questions of policy elicit any sort of response from list subscribers, particularly in recent months. The group members, it seems, prefer to stick to issues of clarifying the wording of the specification and to ignore everything else.

To be fair, the group's purpose is to write the specification, and there appears to be pressure from other working groups at the W3C to wrap the process up. Such pressure exists, even if for no other reason, because finishing the EME specification would finally complete the work of the original HTML Working Group, of which the current Media Extensions group is the last remaining vestige. Still, one could be forgiven for finding the general unresponsiveness of list subscribers to be a source of serious frustration. If, as it seems, the group members themselves cannot be persuaded to entertain calls to adopt a nonaggression covenant, the EFF has another tactic available: appealing to the W3C Advisory Committee instead.

The Advisory Committee is part of the W3C's permanent governance structure; it consists of one representative from each W3C member organization. Doctorow is the EFF representative, and he posted an open letter to other representatives, asking them to commit to supporting the EFF's move to make the DMCA nonaggression covenant an exit condition for the Media Elements working group. It is unlikely, the letter states, that the group will have completed the EME specification by September, so another charter renewal decision will have to be made.

It is difficult to handicap the EFF's odds of success. The previous attempt to force adoption of a nonaggression pact gained a fair amount of support, but may have simply been overruled by W3C leadership. Keeping the pressure on will in all likelihood allow the EFF to pick up additional allies, but whether or not it can force the W3C's executive leadership team to reconsider may be a different question entirely.


to post comments

Encrypted Media Extensions and exit conditions

Posted Jun 16, 2016 8:21 UTC (Thu) by ortalo (guest, #4654) [Link]

I'd welcome a general presentation of W3C governance or any appropriate pointers you or other commenters may know of.
I do not know that well in fact, and it seems to me this body is not working as smoothly as other important regulation bodies, like IETF do for example - from my point of view obviously.

Oh, did I say the IETF was working smoothly? ;-)

Encrypted Media Extensions and exit conditions

Posted Jun 25, 2016 4:43 UTC (Sat) by toyotabedzrock (guest, #88005) [Link] (1 responses)

So basically instead of flash we will have an infinite number of security holes?

A motivated hacker could write any code they want to be run as a protected process because it claims it is a drm module.

CNBC is already misusing this for videos on their news site, if your using chrome on Android.

Encrypted Media Extensions and exit conditions

Posted Jun 25, 2016 15:10 UTC (Sat) by anselm (subscriber, #2796) [Link]

So basically instead of flash we will have an infinite number of security holes?

Perhaps. Probably not. Compared to, say, the Flash plugin, an EME plugin only does something very specific and limited and can be much more effectively sandboxed by the browser.


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds