October 25, 2017
By Jan Ozer Contributing Editor
Featured Articles

Status Update: Encrypted Media Extensions and the Future of DRM

On July 6, 2017, Tim Berners-Lee, the director of the World Wide Web Consortium (W3C), moved the Encrypted Media Extensions (EME) to recommended status. Although this move was later appealed and the final decision is on hold, this felt like a good time to review the status of EME as a replacement for plugin-based DRM.

Let’s Review: What Is EME?

Briefly, EME is an API that lets browsers and other applications communicate directly with digital rights management (DRM) systems, replacing the functionality that plugins like Flash and Silverlight previously performed. While few mourned the loss of plugins, this immediately complicated the lives of publishers that distribute content to browsers.

That’s because in a plugin-based DRM world, publishers could work with one DRM provider to stream to all browser-based targets. Publishers that used Adobe Flash used Access (now Primetime) DRM; those that chose Silverlight used PlayReady.

However, once plugins were out of the picture, browser vendors had to incorporate one or more DRM technologies directly into their browsers. Predictably, Apple chose FairPlay, Google chose Widevine, and Microsoft chose PlayReady. Mozilla originally chose Primetime, then also integrated Widevine into Firefox.

So with plugins, you could support all browsers with a single DRM. With EME, to distribute protected content to Chrome, IE/Edge, and Safari, you’d need to support three DRMs, not only from a licensing perspective, but also from an encoding and playback perspective. The licensing aspect is simple; the EME specification easily supports multiple DRMS in the same source file.

The problem is the multiple incompatible formats, such as Dynamic Adaptive Streaming over HTTP (DASH), Smooth Streaming, and HTTP Live Streaming (HLS), that are required to deliver to the multiple targets. In many cases, this means that publishers have to store multiple sets of encrypted files to serve these targets, boosting storage costs and diminishing the effectiveness of browser caches. Expanding support for DASH and new technologies like the Common Media Application Format (CMAF) are helping, but EME is still more complicated and expensive for producers than the plugin model.

What Did the W3C Do?

According to its website, the W3C is “an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.” Tim Berners-Lee, who is widely considered the inventor of web, heads the organization. On July 6, 2017, the W3C issued a Disposition of Comments for Encrypted Media Extensions and Director’s decision. The document reviewed all the objections that members had to the EME spec, and concluded the following:

The Encrypted Media Extensions specification remains a better alternative for users than other platforms, including for reasons of security, privacy, and accessibility, by taking advantage of the Web platform. While additional work in some areas may be beneficial for the future of the Web Platform, it remains appropriate for the W3C to make the EME specification a W3C Recommendation. Formal publication of the W3C Recommendation will happen at a later date.

Subsequent to this filing, the Electronic Frontier Foundation (EFF) appealed this decision. I’ll discuss that later in this article.

What Does Recommended Status Mean?

From the perspective of most W3C members and other parties interested in the theoretical appropriateness of EME, it ends the debate, or at least it will once the appeal is settled. From the perspective of companies that actually use EME, like browser and player developers and DRM vendors, it means surprisingly little. Unlike other web standards like H.264/H.265, which aren’t commercially released until the standard is formalized, EME has been in use for 2 or more years, depending upon the browser.

Writing for Medium, author Sander Saares states, “Web standards are usually developed in parallel with implementations and EME was no different. Two major browser manufacturers—Microsoft and Google—each had their own DRM technology and they were eager to get it on the market in a widely usable form. While discussions were ongoing, their browsers implemented what seemed to be the most sensible opinion of the day and sometimes created custom API extensions where there was no EME-provided solution.”

Saares goes on to describe how that commercial usage tended to reduce the urgency of creating and finalizing the specification, and observes, “EME in practice has been a done deal for a year or two already. It is in widespread use and blocking standardization will not get rid of EME or change what browsers do. In many ways, EME survives at the mercy of browsers, not the other way around.”

W3C director Tim Berners-Lee seems to agree. In his lengthy and surprisingly readable blog post, “On EME in HTML5,” which addresses many of the objections to EME, Berners-Lee states:

When a company decides to distribute content they want to protect, they have many choices. This is important to remember.

If W3C did not recommend EME then the browser vendors would just make it outside W3C. If EME did not exist, vendors could just create new JavaScript based versions.

Viewed in this light, the W3C recommendation is more a ratification of the work already implemented than a directive to be observed by those who implement. That said, this doesn’t mean that the specification serves no essential purpose. Beyond thoroughly documenting the specification for all users, the final spec sets expectations regarding one of the key issues that hindered its adoption.

What Concerns Did EME Raise Among W3C Members?

There were a number of concerns raised which fell into two categories, concerns about DRM in general and concerns about the EME implementation. Berners-Lee disposed of the generic DRM-related concerns in his comments above; basically, premium content companies won’t ship content without DRM, so either the W3C includes it in the spec, or the browser industry incorporates DRM anyway.

Most of the EME implementation concerns related to the fact that the content decryption modules (CDMs) actually inserted into the browser code were black boxes, so users couldn’t tell if they were accessing personal data or installing some kind of malware on the computer. These concerns are not totally unfounded, as Sony was caught doing that in 2005 in the famed rootkit scandal. You can draw your own conclusions about the likelihood of Apple, Google, Microsoft, or Mozilla trying something similar.

Either way, according to Philippe Le Hégaret, project management lead for the W3C, these concerns led to a new section in the W3C draft spec entitled CDM Constraints. This section states in part, “User agent implementers must ensure that CDMs do not access any information, storage or system capabilities that are not reasonably required for playback of protected media using the features of this specification.” The specification leaves the implementation details up to the implementer, and specifically mentions a sandbox as a valid alternative.

As shown in Figure 1, a sandbox controls all of the communications the DRM has with the computer. As described in the blog post “Reconciling Mozilla’s Mission and W3C EME” by Andreas Gal: “In our implementation, the CDM will have no access to the user’s hard drive or the network. Instead, the sandbox will provide the CDM only with communication mechanism with Firefox for receiving encrypted data and for displaying the results.” Since Mozilla is an open source browser, users, DRM providers, and/or content publishers can audit the sandbox to ensure that it provides all the necessary protections. Anyone who thinks Mozilla’s users aren’t passionate about DRM should check Gal’s post, which had 466 comments when we checked in August, including, “I agree with many others: EME is unnecessary, and just plain evil.”

Figure 1. Mozilla places DRM in a sandbox to prevent the CDM from any unauthorized operations.

So the final W3C spec did what it could to address these and other concerns.

What Was the Appeal About?

The appeal raises three specific issues. First, the EFF wants the ability to audit the sandboxes in the browsers to ensure that user privacy is being preserved. The appeal requests “independent verification in the form of adversarial peer review by outside parties who do not face liability when they reveal defects in members’ products.” While Firefox is open source, most other browsers are not, and whether Apple, Google, Microsoft, or other vendors will open up their code for inspection remains to be seen.