Backgrounder on Encrypted Media Extensions (EME) at the World Wide Web Consortium (W3C)

This backgrounder provides information on the World Wide Web Consortium's work on Encrypted Media Extensions (EME), a common API that may be used to discover, select and interact with content encryption systems. This public document adds to and updates the March 2016 EME Factsheet.

Introduction

The Encrypted Media Extensions (EME) work at the W3C has received a high degree of adoption and implementation. The specification has many technical advantages over previous methods. There have, however, been some controversies about the work.

In 2013, the World Wide Web Consortium members began work on Encrypted Media Extensions, an Application Programming Interface (API) that enables Web applications to interact with content protection systems to allow playback of encrypted audio and video on the Web.

Rationale for EME work at W3C

HTML5 and encrypted video on the Web

HTML5 introduced first-class video support by adding a <video> element. The first draft of HTML 5.0 was released in 2008. It allowed playback control of video directly in the Web platform. Prior to this addition, developers had to rely on browser plugins to display videos. This implied that users needed to install an extra application to be run within their browsers. Plugins were used for video, animations, microphone/camera access, music, etc. - and one by one the Web platform has been eliminating these plugins. The most popular plugins were embedding their own DRM systems to play encrypted video content. However, those plugins were executed in a separate context and outside of the security control of the browsers. With the Open Web Platform gaining features, Web sites have been able to move away from relying on plugins.

Rationale for EME work at W3C

Hundreds of millions of people want to view movies on the Web and most movie companies stipulate that video must be encrypted if it is to be legally available online. Several W3C members requested W3C look at how encrypted movies might be best and most safely viewed on the Web.

W3C Director Tim Berners-Lee thus decided that EME was in scope for the Web and W3C started to explore how the EME technology could run in the browser –not as a separate downloadable app– and be produced in an open manner and with consideration for accessibility, security and privacy.

Wide and increasing use of EME and video streaming

Movies on the Web have become an influential part of our modern life, and are a vital, creative and engaging aspect of our culture. The use of movie streaming services is increasing world-wide. It is estimated that in 2017 the number of people in the US using paid and free video streaming has surpassed DVD, download or even cable use for the first time and that video traffic will be 82 percent of all consumer Internet traffic by 2021, up from 73 percent in 2016. The use of streaming services is increasing exponentially across the globe. Hundreds of millions of subscribers already use EME in services like Netflix or similar. In 2016 there were 93.8 million Netflix subscribers, 98.75 million members at the end of 1Q2017 and announced 100 million in April.

EME is the product of wide collaboration from major companies such as Google, Microsoft, Netflix, Apple, CTA, MPAA (which includes Disney, Fox, NBCUniversal, Paramount, Sony Pictures and Warner Bro studios), and has significant implementation across browsers including Google Chrome, Apple Safari, Mozilla Firefox, Opera, and Microsoft Edge.

Advantages of EME

Encrypted Media Extensions (EME) enables interoperability, better privacy, security, accessibility and user experience in viewing movies on the Web.

Security and Privacy

The aim of the specification is to protect the user: from network attacks, and tracking, as well as protecting information stored on the user device. The introduction section of the specification calls the attention of implementers on the importance of mitigation of security and privacy threats and concerns around EME. For example, conforming CDM implementations are restricted in various ways in EME, including preventing them from accessing network resources, storage, user data other than the CDM state and persistent data, or hardware components not required for video playback. CDMs are also required to provide the ability to clear persistent data. Security and privacy requirements cannot be met without knowledge of the security and privacy properties of the Key System and its CDM implementations. A browser making use of a third party CDM may ensure that it executes in a constrained environment (e.g., "sandbox") without access to the prohibited information and components. Otherwise the specification indicates that the browser should ensure that users are fully informed and/or give explicit consent before loading or invoking the CDM.

The Firefox browser already uses sandboxing and also allows the user to make a choice whether to disable the CDM and opt out of future updates. Chrome also offers the option to disable the CDM (Chrome → Settings → Advanced Settings → Privacy and Security → Content Settings → Protected Content.)

Conforming EME implementations will protect users and provide a model for privacy and security which is superior to native platform alternatives. However, in the current software architecture, in particular the closed CDM implementations, this specification cannot technically enforce a complete protection for users. Nevertheless, the specification sets clear expectation for those protections.

EME in Open Source

The specification itself can be implemented in open source and free software projects since EME doesn't mandate any particular CDM implementations. EME mandates support for the Clear Key common key systems to provide a common baseline level of functionality but that system can also be implemented in open source. The EME specification also allows for future CDM systems, including systems that would be more suitable in free software projects.

Additionally, as with all W3C Recommendations, implementation is voluntary. The Encrypted Media Extensions specification is an extension to the Open Web Platform and the HTML specification, more precisely the HTMLMediaElement interface, — hence the name, which means that browser support for EME is optional: if a browser does not support encrypted media, it will not be able to play encrypted media, but EME is not required for HTML compliance. Such a browser would have no difficulty supporting content that is not protected by DRM.

Moving away from plugins

As mentioned earlier, plugins have historically been used for features that were not available in the Open Web Platform, e.g. Graphic APIs, camera/phone access, audio/video, protected video content, or faster animations. This meant that DRM-related code was loaded for every page that used Adobe Flash or Microsoft Silverlight, even when there was no encrypted video or even any video at all. We have been working on improving the features in the Open Web Platform, following the goals of the Extensible Web to provide a better experience for developers and users. For developers, external plugins programming environments generally required proprietary tools to create applications, and subjected them to a particular development roadmap compared to the rapid-cycle one of the Open Web Platform and the entire modern Web stack. Canvas APIs, Media Capture and Streams, or WebRTC are all extensions of the Open Web Platform.

By developing EME as an extension, W3C is reducing the number of pages that load access to decryption technology. EME has the benefit that all interactions happen within the Web browser and moves the responsibility for interaction from the plugins or third-party applications to the browser. The EME API mitigates the interactions with DRM within the browser itself, limits the access from third-party DRM systems, reducing their exposure for security vulnerabilities or leakage of sensitive user data.

Accessibility

EME improves accessibility of encrypted online video, in contrast to many existing mechanisms, by operating at a level that does not interfere with transmission or control of accessibility information. It does this by isolating the function of playback of protected video content in the EME specification and integrating it in the Open Web Platform. Our analysis and testing of EME has shown no barriers to accessing captions, transcripts, or audio description of video. Applications conforming to EME ensure that accessibility information will either be transmitted in the clear; or, if encrypted, then decrypted along with the primary video file. Additionally, for the specific issues raised in the formal objections, many video functionalities necessary for accessibility are provided in the Open Web Platform. For instance, access to the video controls, time-scale modification, discovery and activation/deactivation of alternative content, use of secondary screen are all functionalities provided by the HTML specification or some of its extensions. These and future accessibility enhancements of the Open Web Platform can be leveraged.

Read more about EME and Accessibility in particular.

Proper Integration with the Open Web Platform

W3C's Media Source Extensions (MSE) is an API that extends HTMLMediaElement to allow more fine-grained control over the source of media, and playback from 'chunks' of video, and enables techniques such as adaptive streaming and time shifting. To be able to adapt content delivery to network conditions and other requirements, EME works with playback of media streams provided by an MSE implementation.

Together with MSE, EME is just one piece of W3C’s larger vision for media tuning which includes HTML5 as well as TTML (for which W3C won an Emmy Award in 2016) as well as other specifications. The Open Web Platform, of which HTML5 is a cornerstone, also includes CSS, DOM, SVG and Web APIs.

All these specifications are open, royalty-free technologies which enable developers to build rich interactive experiences, powered by vast data stores, that are available on any device.

Interoperability

The implementation report provided during the development of the specification already demonstrated substantial interoperability between browsers. Web applications can now take advantage of multiple CDM implementations without a priori knowledge of the Key systems or formats in use. Whether the video format in use is MP4 or WebM, or the Key system is cenc or WebM, it is transparent to the Web application. This simplifies the task of the Web developer and ensures a greater level of interoperability.

EME technology

Browsers

Web sites are expected to conform to the DRMs supported by the browser - no more installing different plugins for each site. Browsers are expected to take care of user security and privacy with respect to the DRMs they integrate with. In some cases, browsers have included their own DRMs, which they control and know well. In other cases, browsers enter into contractual arrangements with DRM providers which should include provisions regarding user security and privacy, or browsers use platform capabilities provided by the user’s Operating System. Browsers will now likely disable plugins altogether, further improving security and privacy. Browser makers have a great track record of encouraging and rewarding independent security review of their products to keep them secure.

Battery

Users can enjoy higher quality, stutter-free video with less battery drain because of the use of hardware video decoders on some platforms.

Clear Key

The EME API allows interaction in the browser with simple clear key decryption as well as complex DRM systems for high-value video.

Although EME does not define DRM functionality, the specification mandates that all browsers supporting EME must implement Clear Key, which is the only de-encryption mandated by the specification. While it is not possible to implement a fully functional EME in free software, due to the closed nature of the encryption required by DRM, the Clear Key system does use an unencrypted key to decrypt the content and no additional client-side content protection is required. Clear key is not considered to be a DRM technology but may be used nevertheless with EME for decryption.

Forward compatibility

EME is an interface for Web applications to control playback of encrypted video content. License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies. The specification does not define a content protection or Digital Rights Management system but, instead, it defines common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. As such, it is agnostic to existing and future content protection system.

EME, DRM and Policy

There have been some concerns about the impact of EME around DRM and its legal implications.

EME and DRM

DRM is commonly used to ensure that videos and other media are not copied or played in an unauthorized manner. Laws preventing the circumvention of DRM exist in a number of countries worldwide, including the DMCA in the United States, and the European Union's Copyright Directive, as well as in WIPO treaties. These laws are often broader than copyright itself, such that anti-circumvention restricts security research and interoperability, even when there is no copyright infringement or unauthorized use.

Some people do not accept DRM in any form and so were opposed to EME for making watching encrypted movies on the Web easier. However, stopping EME would not stop encrypted content from being created or used on the Web; it would just banish encrypted content to closed apps or devices (see also On EME in HTML5). With EME the interaction happens within the browser itself.

The EME API does not define DRM functionality. EME standardizes only the discovery hooks, which don't contain any of the DRM itself. Users have the ability to disallow DRM exposed by EME (and with opt-out, to entirely disallow negotiation with encrypted content). The choice is there to use or not - a big improvement over other systems (see the 2016 Factsheet on EME for more information). As such, no browser is forced to implement EME and no user is required to interact with encrypted content.

Some people are concerned that the recommendation of EME gives a W3C stamp of approval to the use of anticircumvention law. We do not endorse the application of this law against security research. Users can trust EME's security promises best if they or trusted researchers can investigate it and build upon it.

Policy

Some groups demanded that the W3C should enact legal protections around DRM and circumvention related to EME while the group was proceeding along the Recommendation track. There was wide discussion both within the W3C membership and externally in the tech community around the issue of adopting a covenant to protect researchers from anti-circumvention laws while disclosing security or privacy vulnerabilities. Within the W3C, different proposals were put forward, but unfortunately there was no consensus in the W3C membership on accepting or not accepting such a covenant. Therefore the W3C Director decided to allow the EME work to continue as proposed in its charter.

There are already existing Library of Congress exemptions to the US’s DMCA for security researchers secured by the EFF who are also suing to have the law itself changed. The Library of Congress has recently recommended that Congress consider expanding the existing "permanent exemption" for types of "security testing" to make it more applicable to a wider set of security research practices.

In the W3C response to UNESCO, we urged it to use its policy influence to insist that Member States' laws on the Internet be always reasonable and proportionate, and respectful of human rights. W3C has welcomed changing protections under the law for researchers at the government level - the right place for the right changes.

W3C did take seriously the calls from advocates and experts to protect security and privacy researchers. The W3C is discussing guidelines around Security Disclosures Best Practices (see below for more information about the Best Practices).

Quotes and context

The Web must be universal

Tim Berners-Lee noted in “EME in HTML5” in February 2017:

The Web has to be universal, to function at all. It has to be capable of holding crazy ideas of the moment, but also the well polished ideas of the century. It must be able to handle any language and culture. It must be able to include information of all types, and media of many genres. Included in that universality is that it must be able to support free stuff and for-pay stuff, as they are all part of this world. This means that it is good for the Web to be able to include movies, and so for that, it is better for HTML5 to have EME than to not have it.

On the future of commercial media

CTA WAVE wrote:

The HTML5 Encrypted Media and Media Source Extensions will enable many small, specialized providers to deliver commercial media over the Web. And unlike broadcast channels, Web delivered content is point-to-point, with no practical limit on the number and variety of this content. This can lead to the large-scale growth of vertical niche commercial video content, transforming the entertainment industry while expanding the nature and utility of the Web well into the twenty-first century. ...

The real alternative to EME is not some utopian world without encrypted media, but a world where commercial media is only available using proprietary apps and only on what the content owner considers to be the most commercially important platforms.

Choosing the Web

Peter Bright in a March 2017 Ars Technica article "DRM in HTML5 is a victory for the open Web, not a defeat" said:

Deprived of the ability to use browser plugins, protected content distributors are not, in general, switching to unprotected media. Instead, they’re switching away from the Web entirely. Want to send DRM-protected video to an iPhone? “There’s an app for that.” Native applications on iOS, Android, Windows Phone, and Windows 8 can all implement DRM, with some platforms, such as Android and Windows 8, even offering various APIs and features to assist this.

In other words, the alternative to using DRM in browser plugins on the Web is not "abandoning DRM;" it’s "abandoning the Web."

EME as a stepping stone for a more DRM-free world

Bright later argued that the EME platform gives an opening for content providers to test unprotected content, which they would have not necessarily done under a non-Web plugin or app format:

This kind of Netflix Web app would give Netflix a suitable testing ground for experimenting with unprotected content. This unprotected content would have greater reach and would be accessible to a set of users not normally able to use the protected content. It would provide a testing ground for a company like Netflix to prove that DRM is unnecessary and that by removing DRM, content owners would have greater market access and hence greater potential income. Granted, it might also come with the risk of prolific piracy and unauthorized redistribution, so it might serve only to justify the continued use of DRM.

With plugins and apps, there's no meaningful transition to a DRM-free world. There's no good way for distributors to test the waters and see if unprotected distribution is viable. With EME, there is. EME will keep content out of apps and on the Web, and it creates a stepping stone to a DRM-free world. That's not hurting the open Web—it's working to ensure its continued usefulness and relevance.

Current actions

Protection of Researchers

W3C has been called on by some members to develop an acceptable set of best practices. W3C is a convener; a place to bring discussion and interested parties: researchers and advocates along with browser makers, and distributors.

The W3C has been considering Security Disclosures Best Practices to help Security researchers and companies work together to identify vulnerabilities and protect users. We encourage organizations involved in DRM implementations to ensure proper security and privacy protection of their users and consider adopting the proposed best practices for security guidelines (or some variation), intended to protect security researchers. Others might advocate for protection in public policy fora – an area that is outside the scope of W3C which is a technical standards organization.

Continuing to work for the future of the Web

W3C is more than just HTML5 or video; we are working on over 200 active specifications aiming to become Recommendation (see below more about W3C).

About the W3C

The World Wide Web Consortium (W3C), an international standards organization, develops the technical standards and guidelines for the Web. W3C was founded in 1994 by Sir Tim Berners-Lee, inventor of the Web, and Director of the W3C. Dr. Jeff Jaffe is the CEO of the W3C. Together they guide the W3C in its mission "to lead the Web to its full potential." W3C's vision for "One Web" brings together thousands of dedicated technologists representing more than 400 Member organizations and dozens of industry sectors.

Sir Tim Berners-Lee created the Web and released it to the world for free. Since that time he has worked to protect it - fighting to keep it open, royalty free and patent free. He has advocated for making the Web available to the whole world and truly "For Everyone."

For more than 20 years, W3C has developed new standards and ensured the Web remains open, accessible, and interoperable for everyone around the globe, so that the Web works across devices, in different languages, for people of all abilities, and meet the needs of diverse industries.

About the W3C Process

A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C Members and the W3C Director. The W3C Royalty-Free IPR licenses granted under the W3C Patent Policy apply to W3C Recommendations.

The W3C Patent Policy, designed to assure the continuation of the fundamental dynamics of innovation and interoperability that made the Web successful, facilitates the development of W3C recommendations, promotes the widespread implementation of those recommendations, and enables royalty-free access to patents held by authors of the recommendations that are essential to their implementation.

(All text below taken from the W3C Process document which describes the guidelines under which W3C operates)

Consensus

Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Note: The W3C Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.

Managing dissent

The W3C Process states: In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group can make progress.

Dissenters cannot stop a group's work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.

Formal Objections

An individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the W3C Director consider as part of evaluating the related decision. An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection; these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director. A record of each Formal Objection must be publicly available.

Media Contact

Send media inquiries to w3t-pr@w3.org.

W3C Communications