W3C home > Mailing lists > Public > public-html-media@w3.org > July 2017

Disposition of Comments for Encrypted Media Extensions and Director's decision

From: Philippe Le Hégaret <plh@w3.org>
Date: Thu, 6 Jul 2017 07:51:06 -0400
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <df20ad7d-9f47-ad10-218c-29e3d388700f@w3.org>

On March 16, the W3C solicited a review from its Advisory Committee of 
the Encrypted Media Extensions on its advancement to Recommendation:


This review followed extensive technical work and open discussions 
within the Web community over the past four years. While some had 
disagreed with W3C’s decision to work on EME, the W3C determined that 
the hundreds of millions of users who want to watch videos online, some 
of which have copyright protection requirements from their creators, 
should be able to do so safely and in a Web-friendly way. Compared to 
previous methods of viewing encrypted video on the Web, EME has the 
benefit that all interactions happen within the Web browser and it moves 
the responsibility for interaction from plugins to the browser. As such, 
EME offers a better user experience, bringing greater interoperability, 
privacy, security and accessibility to viewing encrypted video on the 
Web. While EME does not overcome the fact that the user needs to 
interact with a content decryption module (CDM), it is an improvement 
over the pre-EME situation and a step towards future improvements as 
well. To ensure that the community appreciates these advantages, we are 
providing a backgrounder to provide additional information about these 
advantages [1].

Several objections were raised during the latest review. The substantive 
content of the dissent is summarized in the seven points below:
1. Inadequate protection for users;
2. Difficulties in supporting the specification in free software projects;
3. Lack of definition for CDM implementations;
4. Lack of a covenant regarding anti-circumvention regulations;
5. Challenges for adaptation for people with disabilities;
6. Challenges for new market entrants and inadequate specification for 
the Open Web;
7. Archiving of content.

The Director looked very carefully at these objections and also 
discussed with experts and the general public. In some cases, the 
Director found that the objections had already been addressed, but asked 
the Working Group to further clarify how these issues were addressed in 
the document. In other cases, objections were overruled. Based on that, 
and the fact that EME improves the user experience compared to today's 
solutions (mentioned above), the Director reached a decision to publish 
the revised EME specification as a W3C Recommendation. Please look at 
the current Editor's Draft [2] and a diff [3] for changes.

While this disposition of comments deals with the formal W3C Process of 
progressing EME to Recommendation, many important practical, cultural, 
and societal considerations can be also found in the Director's blog 
post [4].

The Disposition of Comments follows.

1. Inadequate protection for users

The aim of the Working Group and specification was always to protect the 
user: from network attacks, and tracking, as well as protecting 
information stored on the user device. For example, conforming CDM 
implementations are restricted in various ways by the specification, 
including that they are prevented from making out-of-band network 
communications and are required to provide the ability to clear 
persistent data. In light of the objections and further discussion with 
the Working Group and the specification editors, the Director concluded 
that while security and privacy requirements were covered in the 
specification, the requirements related to CDM were spread in different 
sections of the specification, making it difficult to understand the 
specification. So the Director asked the editor to reorganize the 
exposition. The networking constraints, previously present in Section 2 
of the specification, were moved to section 8.2 "Messages and 
Communication". As now mentioned in the introduction, implementers 
should pay attention to the mitigation of the security and privacy 
threats and concerns described in the specification. In particular, the 
specification requirements for security and privacy cannot be met 
without knowledge of the security and privacy properties of the Key 
System and its implementation(s). The new section 8.1 "CDM Constraints" 
now summarizes the constraints expected to be followed by underlying CDM 
implementations while recognizing that those constraints could be met 
using various techniques, including sandboxing the CDM:

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

2. Difficulties in supporting the specification in free software projects

The EME specification itself can be implemented in open source [5] and 
free software projects. EME mandates support for the Clear Key common 
key systems to provide a common baseline level of functionality. The EME 
specification 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. A browser not implementing EME will not have the benefit of 
enhanced access to protected content, but will otherwise be able to 
perform like any other browser for non-protected content.

Given all of these considerations, the Director feels that this 
objection was addressed.

3. Lack of definition for CDM implementations

Attempts to come up with common interface between CDM implementations 
were made by the Working Group in the past. It was not however felt to 
be in scope for the first version of the specification. The 
specification does allow for future CDM interfaces and implementations.

Accordingly, the Director would like to have this issue open when/if 
there are future releases of the specification, but overrules it as a 
blocker to the first release of EME.

4. Lack of a covenant regarding anti-circumvention regulations

The Director was supportive of ideas to address the negative impacts of 
anti-circumvention regulations; including member discussions of 
proposals for a nonaggression covenant. Since EME directly interacts 
with CDMs, it may appear that the W3C specification sanctions the notion 
that research into EME may be deemed "circumvention" under copyright 
anti-circumvention laws. For that reason, W3C has attempted several 
times to determine if consensus and support of W3C Members for such a 
covenant; or variations to the EFF proposal [6] could be gained. Despite 
much work those efforts were not successful and consensus among the W3C 
Membership was not achieved.

We recommend organizations involved in DRM and EME implementations 
ensure proper security and privacy protection of their users. We also 
recommend that such organizations not use the anti-circumvention 
provisions of the Digital Millennium Copyright Act (DMCA) and similar 
laws around the world to prevent security and privacy research on the 
specification or on implementations. We invite them to adopt the 
proposed best practices for security guidelines [7] (or some variation), 
intended to protect security and privacy 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. In 
addition, the prohibition on "circumvention" of technical measures to 
protect copyright is broader than copyright law's protections against 
infringement, and it is not our intent to provide a technical hook for 
those paracopyright provisions.

Given that there was strong support to initially charter this work 
(without any mention of a covenant) and continued support to 
successfully provide a specification that meets the technical 
requirements that were presented, the Director did not feel it 
appropriate that the request for a covenant from a minority of Members 
should block the work the Working Group did to develop the specification 
that they were chartered to develop. Accordingly the Director overruled 
these objections.

5. Challenges for adaptation for people with disabilities

Although issues were raised about support for people with disabilities, 
the Director found that EME actually provides a better alternative for 
people with disabilities. 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 directly benefits from all of the built-in 
functionalities included in the HTML specification, including control of 
the video playback rate and timeline. Read more in the Backgrounder on 
Encrypted Media Extensions (EME) [8].

For the specific issues raised in the formal objections, our analysis 
and testing of EME has shown no barriers to accessing captions [9], 
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. Additional clarifications were provided in section 8.9.3 
"Unencrypted In-band Support Content" to clarify that accessibility 
information is available in usable form:


6. Challenges for new market entrants and inadequate specification for 
the Open Web

In the past new market entrants needed to support the plugin API and 
request their users to install plugins in order to get encrypted 
content. The EME specification isolates the decryption code and provides 
a better integration with the Web Platform. Existing browsers, including 
latest market entrants not involved in the Working Group, were able to 
provide support for EME and one of the popular CDM implementations. This 
substantially reduces the security and privacy exposure for users 
compared to the alternative of installing a plugin.

Accordingly, the Director feels that this objection was addressed.

7. Archiving of content

To counter obstacles to archiving of content for posterity, as suggested 
[4], anyone copyrighting a movie and distributing it encrypted in any 
way ought to deposit an unencrypted copy with a set of copyright 
libraries. While the Director is in total agreement with the issue 
raised in this objection, he views it as an issue with DRM and copyright 
law rather than being an issue with the EME specification. Since the W3C 
scope is limited to the actual EME recommendation, this objection is 
ruled out of scope (and therefore overruled).


After consideration of the issues, the Director reached a decision that 
the EME specification should move to W3C Recommendation. 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. We encourage W3C Members and the community to work in 
both technical and policy areas to find better solutions in this space.

This announcement follows section 6.6 and 7.1.2 of the W3C Process Document:

Thank you,

For Tim Berners-Lee, W3C Director,
Philippe Le Hégaret, Project Management Lead;

[1] https://www.w3.org/2017/07/EME-backgrounder.html
[2] https://www.w3.org/2017/07/eme-rec-draft.html
[3] https://www.w3.org/2017/07/eme-diff.html
[4] https://www.w3.org/blog/2017/02/on-eme-in-html5/
[7] https://w3c.github.io/security-disclosure/
[8] https://www.w3.org/2017/07/EME-backgrounder.html#accessibility
[9] https://www.w3.org/2017/03/eme-accessibility.html
Received on Thursday, 6 July 2017 11:51:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:20 UTC