By
May 19 Update: We’ve added an FAQ below the text of the original post to address some of the questions and comments Mozilla has received regarding EME.
With most competing browsers and the content industry embracing the W3C EME specification, Mozilla has little choice but to implement EME as well so our users can continue to access all content they want to enjoy. Read on for some background on how we got here, and details of our implementation.
Digital Rights Management (DRM) is a tricky issue. On the one hand content owners argue that they should have the technical ability to control how users share content in order to enforce copyright restrictions. On the other hand, the current generation of DRM is often overly burdensome for users and restricts users from lawful and reasonable use cases such as buying content on one device and trying to consume it on another.
DRM and the Web are no strangers. Most desktop users have plugins such as Adobe Flash and Microsoft Silverlight installed. Both have contained DRM for many years, and websites traditionally use plugins to play restricted content.
In 2013 Google and Microsoft partnered with a number of content providers including Netflix to propose a “built-in” DRM extension for the Web: the W3C Encrypted Media Extensions (EME).
The W3C EME specification defines how to play back such content using the HTML5 <video> element, utilizing a Content Decryption Module (CDM) that implements DRM functionality directly in the Web stack. The W3C EME specification only describes the JavaScript APIs to access the CDM. The CDM itself is proprietary and is not specified in detail in the EME specification, which has been widely criticized by many, including Mozilla.
Mozilla believes in an open Web that centers around the user and puts them in control of their online experience. Many traditional DRM schemes are challenging because they go against this principle and remove control from the user and yield it to the content industry. Instead of DRM schemes that limit how users can access content they purchased across devices we have long advocated for more modern approaches to managing content distribution such as watermarking. Watermarking works by tagging the media stream with the user’s identity. This discourages copyright infringement without interfering with lawful sharing of content, for example between different devices of the same user.
Mozilla would have preferred to see the content industry move away from locking content to a specific device (so called node-locking), and worked to provide alternatives.
Instead, this approach has now been enshrined in the W3C EME specification. With Google and Microsoft shipping W3C EME and content providers moving over their content from plugins to W3C EME Firefox users are at risk of not being able to access DRM restricted content (e.g. Netflix, Amazon Video, Hulu), which can make up more than 30% of the downstream traffic in North America.
We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM.
This makes it difficult for Mozilla to ignore the ongoing changes in the DRM landscape. Firefox should help users get access to the content they want to enjoy, even if Mozilla philosophically opposes the restrictions certain content owners attach to their content.
As a result we have decided to implement the W3C EME specification in our products, starting with Firefox for Desktop. This is a difficult and uncomfortable step for us given our vision of a completely open Web, but it also gives us the opportunity to actually shape the DRM space and be an advocate for our users and their rights in this debate. The existing W3C EME systems Google and Microsoft are shipping are not open source and lack transparency for the user, two traits which we believe are essential to creating a trustworthy Web.
The W3C EME specification uses a Content Decryption Module (CDM) to facilitate the playback of restricted content. Since the purpose of the CDM is to defy scrutiny and modification by the user, the CDM cannot be open source by design in the EME architecture. For security, privacy and transparency reasons this is deeply concerning.
From the security perspective, for Mozilla it is essential that all code in the browser is open so that users and security researchers can see and audit the code. DRM systems explicitly rely on the source code not being available. In addition, DRM systems also often have unfavorable privacy properties. To lock content to the device DRM systems commonly use “fingerprinting” (collecting identifiable information about the user’s device) and with the poor transparency of proprietary native code it’s often hard to tell how much of this fingerprinting information is leaked to the server.
We have designed an implementation of the W3C EME specification that satisfies the requirements of the content industry while attempting to give users as much control and transparency as possible. Due to the architecture of the W3C EME specification we are forced to utilize a proprietary closed-source CDM as well. Mozilla selected Adobe to supply this CDM for Firefox because Adobe has contracts with major content providers that will allow Firefox to play restricted content via the Adobe CDM.
Firefox does not load this module directly. Instead, we wrap it into an open-source sandbox. 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.
Traditionally, to implement node-locking DRM systems collect identifiable information about the user’s device and will refuse to play back the content if the content or the CDM are moved to a different device.
By contrast, in Firefox the sandbox prohibits the CDM from fingerprinting the user’s device. Instead, the CDM asks the sandbox to supply a per-device unique identifier. This sandbox-generated unique identifier allows the CDM to bind content to a single device as the content industry insists on, but it does so without revealing additional information about the user or the user’s device. In addition, we vary this unique identifier per site (each site is presented a different device identifier) to make it more difficult to track users across sites with this identifier.
Adobe and the content industry can audit our sandbox (as it is open source) to assure themselves that we respect the restrictions they are imposing on us and users, which includes the handling of unique identifiers, limiting the output to streaming and preventing users from saving the content. Mozilla will distribute the sandbox alongside Firefox, and we are working on deterministic builds that will allow developers to use a sandbox compiled on their own machine with the CDM as an alternative. As plugins today, the CDM itself will be distributed by Adobe and will not be included in Firefox. The browser will download the CDM from Adobe and activate it based on user consent.
While we would much prefer a world and a Web without DRM, our users need it to access the content they want. Our integration with the Adobe CDM will let Firefox users access this content while trying to maximize transparency and user control within the limits of the restrictions imposed by the content industry.
There is also a silver lining to the W3C EME specification becoming ubiquitous. With direct support for DRM we are eliminating a major use case of plugins on the Web, and in the near future this should allow us to retire plugins altogether. The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins.
While the W3C EME-based DRM world is likely to stay with us for a while, we believe that eventually better systems such as watermarking will prevail, because they offer more convenience for the user, which is good for the user, but in the end also good for business. Mozilla will continue to advance technology and standards to help bring about this change.
FAQ
What did Mozilla announce?
In a sentence: Mozilla is adding a new plug-in integration point to Firefox to allow an external DRM component from Adobe to supply the function of decrypting and decoding video data in a black box which is designed to make it difficult for the user to extract the decryption keys or the decrypted compressed data.
A plug-in of this new type is called a Content Decryption Module (CDM) and is exposed to the Web via the Encrypted Media Extensions (EME) API proposed at the W3C by Google, Microsoft and Netflix (Here is a short technical explanation of EME). A CDM integrates with the HTML5 <video> and <audio> support provided by the Gecko engine instead of the <embed> or <object> elements that third parties have historically used to enable playback for video wrapped in DRM to Firefox, via software such as Adobe Flash Player and Microsoft Silverlight. We have formed a relationship with Adobe, who will distribute to end users a Firefox-compatible CDM implementing the Adobe Access DRM scheme, and Firefox will facilitate the download and installation of that CDM. Streaming services requiring DRM and implementing the EME-compatible version of Adobe Access should thereby, if they choose to, be able to stream media to Firefox Desktop users on Windows, Mac or Linux.
Does this mean Mozilla is adding DRM to Firefox?
No. Mozilla is providing a new integration point for third-party DRM that works with Firefox. Third-party DRM that works with Firefox is not new. Firefox (and every other browser) already provides another integration point for third parties to ship DRM: the Netscape Plugin API (NPAPI), which has been part of web browsers since 1995. What’s new is the ability of the third-party DRM to integrate with the HTML <video> element and its APIs when previously third-party DRM instead integrated with the <embed> and <object> elements. When integrating with <video>, the capabilities of the DRM component are more limited, and the browser has control over the style and accessibility of the playing video.
Firefox, as shipped by Mozilla, will continue to be Free Software / Open Source Software.
Why is Mozilla adding a new DRM integration point when the NPAPI already exists?
NPAPI plug-ins come with much more than just DRM. In addition to the Adobe Access DRM component, Adobe Flash Player comes with an entire ActionScript runtime, a broad set of APIs, a graphics stack, a media stack and a networking stack. Likewise, in addition to the PlayReady DRM component, Microsoft Silverlight comes with a CLI virtual machine, a broad set of APIs, a graphics stack, a media stack and a networking stack. Driven in major part by Mozilla, the Open Web Platform is growing to match almost all the functionality that Adobe Flash Player or Microsoft Silverlight provide—with one big exception being DRM, which is necessarily non-open. The use of NPAPI plug-ins in most other situations is not as sustainable as it once was. As plugin owners start to migrate from supporting their plugins (for example, Microsoft appears to be ending Silverlight support and Adobe has discontinued Flash for Android), Firefox cannot continue to rely on NPAPI plug-ins for providing video DRM (and thereby allow users to watch movies from major Hollywood studios).
The new CDM integration point is a much more focused plug-in API than the NPAPI. It permits a third-party component to provide the one function that an Open Source implementation of the Open Web Platform cannot provide to Hollywood’s satisfaction: decrypting and decoding video while aiming to make it very difficult for the end-user to tamper with the process. The browser’s media stack and the associated HTML5 APIs can be used for everything else. Since a CDM has less functionality than NPAPI plug-ins, it is easier to sandbox a CDM and easier to port it to new platforms.
Why isn’t DRM dying together with NPAPI plug-ins?
Mozilla’s competitors don’t appear to be letting DRM die together with NPAPI (or ActiveX) plug-ins. In fact, the Encrypted Media Extensions API was developed by Microsoft, Google and Netflix and Microsoft and Google have already implemented EME in their respective browsers.
Netflix operates a massively popular (where available) online service that allows end-users to watch movies from major Hollywood studios and they are already serving content to Internet Explorer and Chrome OS using EME with Microsoft’s and Google’s own DRM schemes (PlayReady and Widevine).
If Mozilla didn’t enable the possibility of installing the Adobe Access CDM for use with EME, we’d be in a situation similar to the one we were in when we did not support the H.264 codec in HTML5 video. Instead of moving away from H.264, Web sites still delivered H.264 video to Firefox users—but did it via the NPAPI using Adobe Flash Player or Microsoft Silverlight rather than via the <video> tag.
Similarly, if Mozilla didn’t enable the use of a Hollywood-approved DRM scheme with HTML5 video using EME, Firefox users would need to continue using Flash, Silverlight or another NPAPI plugin to view Hollywood movies on Windows and Mac. As noted in the previous answer, the long-term future of that capability is in doubt, and the experience (both in terms of installation and in terms of performance) would be worse than the experience in Chrome and IE with their bundled EME CDMs. On other operating systems, Firefox users would be locked out of viewing Hollywood movies (as is the case today), but other browsers, for example Chrome on Linux and Android, would be in a position to support them.
The ability to watch movies from major Hollywood studios is a feature users value. Netflix alone accounts for fully 1/3 of bandwidth usage in North America during the evening peak time. We expect that many users around the world would switch browsers in pursuit of this ability, or of a better experience, if Firefox provided either no experience or a worse experience (depending on operating system).
How will Firefox facilitate the installation of the Adobe Access CDM?
The user experience for EME in Firefox is still being considered. Users will have choice whether to enable use of the CDM.
What does this mean for interoperability of the EME specification?
The Adobe Access CDM as used with Firefox will support ISO Common Encryption (CENC). This is a way of encrypting individual tracks within an MP4 container using 128-bit AES–CTR such that the MP4 file declares the key identifiers for the AES keys needed for decryption but doesn’t contain the keys themselves. It is then up to the CDM to request the AES keys by ID from a key server that knows how to talk with the CDM. (The communication between the CDM and the key server is mediated through the EME API and a JavaScript program that can relay the EME messages to the key server over XMLHttpRequest.)
It follows that a site can serve the same MP4/CENC files and the same JavaScript program to different browsers that have CDMs for different DRM schemes, as long as the site runs a distinct key server for each DRM scheme, since each DRM scheme has its format for the EME-mediated messages between the CDM and the key server.
So there is expected to be interoperability on the level of media files and on the level of JS code served to different browsers, but CDMs from different vendors are expected to acquire keys using mutually incompatible protocols. (The EME API sees byte buffers whose contents are opaque to EME.)
Whether EME+CENC is an interoperability improvement depends on what you compare it to. When a content provider operates a full array of key servers for the various DRM schemes that different players may support, it will be an interoperability improvement compared to video delivered via Adobe Flash Player or Microsoft Silverlight, or via apps written for a small set of specific mobile platforms. However, if a content provider doesn’t operate a full array of key servers and caters only to a subset of the EME-relevant DRM schemes, interoperability may not be as good as that provided by current plug-ins. And no DRM scheme can provide the full interoperability benefits of DRM-less HTML5 video.
Won’t having to support multiple key servers with mutually incompatible DRM protocols (in order to get cross-browser support) make Web publishing prohibitively expensive for independent publishers?
DRM is a requirement imposed by the major studios onto services that license movies from them. Independent video publishers can avoid the cost of DRM by not imposing a DRM requirement on themselves.
Which streaming services will be supported?
This is a new agreement with Adobe and it’s too early to be certain exactly which streaming services will support it.
Since the Adobe Access CDM contains an H.264 decoder, does this mean that the decoder can be used for non-DRM content?
Yes. The CDM component could also be used to provide non-DRMed H.264 and/or AAC support in the <video> tag. It is not yet determined for certain where, when and if this capability will be used—that depends on the availability of other options (such as OpenH264).
The market conditions regarding the need for H.264 support in the browser have not changed significantly since Mozilla made the decision in 2012 to provide support for it (via OS libraries or third party software). Mozilla continues to believe that patent un-encumbered codecs are best for the web, and encourages video producers to use open codecs (WebM for example) without the use of DRM.
What does this mean for downstream users of the Firefox code base?
The solution consists of three parts: the browser, the CDM host and the CDM.
The CDM host is an executable distinct from the browser that communicates with the browser using an inter-process communication (IPC) mechanism. The CDM is a shared library loaded by the CDM host. The CDM host drops privileges, such as disk and network access, before calling into the CDM.
Mozilla will develop the CDM host and is planning on making its code open source as is the norm for Mozilla-developed code. However, the CDM will refuse to work if it finds itself in a host that isn’t identical to the Mozilla-shipped CDM host executable. In other words, downstream recipients of the source code for the CDM host won’t be able to exercise the freedom to modify the CDM host without rendering it useless (unless they also make arrangements with Adobe).
This leaves downstream users of the Firefox code base with the following options:
- Not supporting the Adobe Access CDM.
- Distributing their own browser build that retains Firefox’s IPC behavior and distributing a copy of Mozilla’s CDM host executable.
- Distributing their own browser build that retains Firefox’s IPC behavior and distributing a self-built CDM host executable that is bit-identical to Mozilla’s CDM host executable. (I.e. this requires doing the work to achieve deterministic builds for the CDM host.)
- Making arrangements directly with Adobe to get a non-Mozilla CDM host executable recognized by the CDM.
Do I have to run proprietary software in order to use Firefox?
No. The Adobe Access CDM is entirely optional. However, we expect Hollywood studios, via their video streaming partners, to deny you access to view their content using the <video> tag if you choose not to use it.
Does this mean applying DRM to HTML?
No, this is about enabling DRM to be applied to video and audio tracks when played using HTML facilities. The DRM doesn’t apply to the HTML document that contains the video or audio element, to page images, or anything else other than video and audio tracks. There are no plans to support DRM for captioning data, for example. Mozilla strongly opposes any future expansion in scope of the W3C EME specification.
Why is DRM supported for the <audio> element?
“Audio” is a subset of “video with audio,” so if we restricted DRM to the <video> element, those who wished to use DRM with audio would just use a “video-less video.”
Also, even though record labels gave up on DRM for music files which are sold to users, they still require DRM for music subscription services (that is, services where the user loses the ability to play the music upon terminating the subscription). Support for EME in the <audio> element helps move those services move off NPAPI plug-ins.
About Andreas Gal
Dr. Andreas Gal is Chief Technology Officer and VP Mobile at Mozilla, leading technical decision making, representing Mozilla externally on technology, and managing R&D programs. Dr. Gal co-founded the Boot to Gecko open mobile ecosystem and is driving its continued evolution as Firefox OS. Previously, he worked as a project scientist at the University of California, Irvine, working in the Secure Systems and Languages Laboratory of Professor Michael Franz. His background is in secure systems, type-safe languages, dynamic compilation, and VMs. He holds a Ph.D. in Computer Science from the University of California, Irvine.
466 comments