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

While I appreciate the time that the W3C has put into trying to address my
objection to how EME enables DRM systems and thus causes concrete privacy
and security damage, I am not satisfied with this response by the W3C and
am saddened that all attempts to defend both security researchers from EFF
and CDT were more or less ignored. Indeed, the Director could have used the
same logic that was used over the EFF covenant to state that there was 'not
consensus' to *not* give EME Recommendation status as the number of formal
objections to EME as a Recommendation have been unprecedented.

On the technical side, although I understand the W3C likes to think it's
only a technical standards body, my purely both technical and in-scope
objection to simply have EME "off by default" was ignored [1], despite the
fact that this would give users who are concerned over privacy and security
more protection while simultaneously allowing those who want to use
DRM-enabled systems the ability to easily do so.  Why not empower users to
make their own decision? While it's enjoyable to read the wishful thinking
in the "CDM constraints" and "Messages and Communication" section, the
primary defense of EME is that somehow it 'sandboxes' the CDM. Now, as it's
illegal to inspect the CDM under the DMCA and equivalent laws harmonized
with the DMCA, it is *by definition* impossible to determine if the CDM
follows the constraints in the EME spec. Second, the flaws of CDM systems
are iterated in the spec itself in Section 10, but there's some belief
amongst EME advocates and the W3C that a 'sandbox' solve these problems,
and somehow the 'sandbox' is enforced on a per origin basis. This logic,
followed by W3C staff and EME supporters, seems to overstate what a
'sandbox' means.

There's been a lot of handwaving around how sandboxing magically solves the
problems in DRM, but there's more sand than box in 'sandboxing' on the Web.
It's true that browsers are sandboxed from the rest of the computer in the
same way any other computer program, but origins are not defended
adequately from each other *inside* the browser, which is the root of the
problem. Although Javascript is constrained per origin in terms of explicit
use, *security flaws* are not constrained per origin. In modern web
browsers, there are a limited number of content processes (I believe
Firefox recently went up to 4 or 5, while mobile browsers often have one).
Normally, each origin does not have its own content process, as that would
cause a performance slowdown and so each content process shares memory.
Therefore, if there is a flaw in the underlying CDM or EME, it's access
will not be limited to the origin, but to the entire shared memory space of
the content process. As security flaws are simply more likely in a CDM that
can't be inspected to see if it has flaws or follows the EME spec's
'guidelines', and by default this CDM will be sharing a content process,
therefore the CDM is *not sandboxed* in any actual sense of the word. I
don't honestly see the security or privacy advantages of this design that
outweigh the likely problems of causing DRM to be shipped by default with
all major browses and without protection, so we need to keep EME/DRM off by
default until the creators of the CDM allow or the DMCA itself is changed
to allow security researchers to inspect the underlying CDM.

I'd like to note that given the large amount of formal objections, a
equally - if not more reasonable path - would have been to delay the
Recommendation until suitable protections were put into place, as I
outlined in my objection to the Security Disclosure Best Practices
document. Given that the W3C actually has legal staff and its members do,
it's not unreasonable to ask that W3C members simply invest legal resources
in fixing their *actual existing* responsible disclosure policies to cover
the case of security researchers and users to inspect a CDM. That's just as
in scope as patent disclosures and licensing, and while it would require
real legal and technical work, it's the W3C's responsibility to actually
figure out a solution rather than pretend the problem doesn't exist via
making minor edits to the spec. It should not take a Turing Award to figure
out that this problem of DRM on the Web is not going to go away, but will
continue in other areas of standardization like digital publishing, and I
still believe the W3C and the Director are capable of using their
considerable weight to tackle this problem. I look forward to seeing some
announcement from the W3C during this next two week period.

      cheers,
        Harry


[1] https://github.com/w3c/encrypted-media/issues/386
[2] https://github.com/w3c/security-disclosure/issues/3

On Thu, Jul 6, 2017 at 12:51 AM, Philippe Le Hégaret <plh@w3.org> wrote:

> 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
>
>
>