This would standardise an Application Programming Interface (API) to play audio-video content on a browser without the need to install plug-ins (see, W3C Information on EME). According to the three editors of the proposal (David Dorwin, Google; Adrian Bateman, Microsoft; Mark Watson, Netflix) a common API would allow for the provision of content with "a single application solution" for all consumer devices. More clearly, it was argued that "Developers who use[d] HTML5 for video [could] create play back video directly without external dependency on third party apps (like Adobe Flash or Microsoft Silverlight) and without inheriting security vulnerabilities from those third party apps." In addition, the EME would enable product protection for audio-video content providers and application developers.
The standard developing process on the EME specifications is still ongoing. Most recently, on 4th April 2016, the W3C published an Editor’s Draft, which as stated in the document, did not automatically imply endorsement by W3C Membership. Those who will implement the specifications are advised to continue taking part in the discussions in order to ensure any changes to the recommendations are compatible with them. The process however has been controversial, and the controversy has involved three types of actors – major browser vendors, large content providers and digital rights lobbyists.
Digital rights campaigners have been united in their demands against the proposed new specifications. In the US, the Electronic Frontiers Foundation (EFF), the Free Software Foundation and the Open Source Initiative became the most prominent civil society groups that opposed the introduction of EME in the updated HTML specifications. The organisations argue that the new specifications provide for the insertion of Digital Rights Management (DRM), or as they call it Digital Restrictions Management system into HTML, the everyday Web we use. According to the EFF, the proposals will provide companies such as Netflix the possibility to lock content rights, which new content providers will not be able to remove. The digital rights groups are thus linking the proposed EME specifications to wider anti-DRM campaigns. The EFF argues that the presence of EME in HTML will put at risk of prosecution “anyone who tampers with or removes digital locks, even for legal reasons”, in accordance with the Digital Millennium Copyright Act (DMCA) in the US and similar legislation globally. Having lost its campaign in 2013 to stop the W3C’s HTML Working Group to continue its work on EME, the EFF has proposed the W3C to adopt a ‘covenant’ under which its members would not pursue legal actions against those bypassing digital locks and making revelation about security caveats in protected products.
In relation to this, the EFF has recently called upon security researchers who work on browser software to support their campaign against the W3C’s work by recommending their covenant. The campaign has been accompanied by protests in front of the W3C premises in the US and around the world. Digital rights groups have also been backed by voices inside the W3C. Most notably, Harry Halpin announced on Twitter that he would resign from W3C if the organisation decided to recommend EME in HTML5, adding “DRM is not part of the web we wanted.” This side of the debate has been, from the outset, making the argument that the DRM mechanisms are not compatible with interoperability - the key to open (source) web, rather they block innovation by subduing it to prosecutable proprietary requirements.
The W3C however insists that EME is not a DRM specification and that it should not be drawn into wider campaigns against legislative acts such as the DMCA. In an explanatory statement on the EME in HTML5, the organisation has declared that the specifications does not “create nor impose a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.” In addition, the organisation has noted that the EME API is intended to be DRM neutral and that it does not prescribe a single DRM for content providers wishing to encrypt their premium content on the web. It also argues that the EME does not oblige browsers to support its specifications. As stated by the W3C, “if a browser does not support encrypted media, it will not be able to play encrypted media”.
For their part, it seems that browsers have no one specific view on the matter. For example, Mozilla’s Firefox was not formerly in favour of EME but has produced a sandboxed version of it (see, also W3C Information on EME), acknowledging that if they did not implement the DRM in a way “comfortable” to content providers, the latter would not make their content available to the browser. This, therefore, would result in a loss of users of the browser.