- 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>
All, On March 16, the W3C solicited a review from its Advisory Committee of the Encrypted Media Extensions on its advancement to Recommendation: https://lists.w3.org/Archives/Public/public-html-media/2017Mar/0016.html 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: https://www.w3.org/2017/07/eme-rec-draft.html#cdm-constraint-requirements 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: https://www.w3.org/2017/07/eme-rec-draft.html#unencrypted-in-band-support-content 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). Conclusion 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: https://www.w3.org/2017/Process-20170301/#rec-publication https://www.w3.org/2017/Process-20170301/#ACReviewAfter 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/ [5] https://dxr.mozilla.org/mozilla-central/source/obj-x86_64-pc-linux-gnu/dom/bindings/HTMLMediaElementBinding.cpp?q=setMediaKeys#2195 [6] https://www.w3.org/Member/wiki/EME_Covenant#EFF.27s_version_of_the_covenant [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