Re: Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection

True, having watched people argue that gorillas are (or are not) natural persons, nothing surprises.  nonetheless, it might diminish the power of that argument if we were to make the statement that it’s not intended to be, become, or be viewed or treated as, a gorilla.

> On Aug 4, 2016, at 2:55 , Joe Feely <joe.feely@googlemail.com> wrote:
> 
> Hi All,
>       I'm not sure if I have a great understanding of the issue, but, I would guess that if some party wanted to use the DMCA they would describe their target in such a way that it would apply, irrespective of what description someone else may have given it.
> 
> Joe
> 
> On 3 August 2016 at 20:12, Mark Watson <watsonm@netflix.com> wrote:
> Ok, I stand corrected.
> 
> Paul, I think you are right that Wendy's proposal would address Harry's concerns too.
> 
> However, the two proposals have very (very) different effects, so I think it's best to keep them separate.
> 
> ...Mark
> 
> On Wed, Aug 3, 2016 at 11:58 AM, Mark Watson <watsonm@netflix.com> wrote:
> Hi Paul,
> 
> IIUC, Wendy's proposal applies to the EME specification, whereas Harry's concerns are about the CDM (which we constrain in some ways but do not specify). Harry would like to mitigate his concerns about the CDM by requiring user consent to use the EME API, since using the latter may cause use of the former.
> 
> But, as I said, I may have misunderstood Wendy's proposal, so input from her would be very useful.
> 
> ...Mark
> 
> On Wed, Aug 3, 2016 at 11:37 AM, Paul Cotton <Paul.Cotton@microsoft.com> wrote:
> Wendy’s issue states:
> 
>  
> 
> > The specification should explicitly state that implementations MUST not be construed as "technological measures" or interfaces to technical protection measures in the meaning of DMCA Section 1201 or similar copyright laws in other jurisdictions.
> 
>  
> 
> And DMCA Section 1201 states:
> 
>  
> 
> > No person shall circumvent a technological measure that effectively controls access to a work protected under this title.
> 
>  
> 
> So if EME is NOT a “technological measure” then I believe the latter part of Harry’s motivation below about the “anti-circumvention provision of the DMCA” does NOT apply:
> 
>  
> 
> > Such a content decryption module can serve as both a technical security risk, as it puts a highly privileged process in the user's computer outside their direct control by design, and as a legal risk subjects any inspection of the DRM-enabled system on their computer due to the anti-circumvention provision of the DMCA or local equivalent.
> 
>  
> 
> This is why I thought the two “issues” were related.
> 
>  
> 
> It would be VERY useful to have input from Harry and/or Wendy on this thread.
> 
>  
> 
> /paulc
> 
>  
> 
> From: Mark Watson [mailto:watsonm@netflix.com] 
> Sent: Wednesday, August 3, 2016 11:19 AM
> To: Paul Cotton <Paul.Cotton@microsoft.com>
> Cc: Harry Halpin <hhalpin@w3.org>; public-html-media@w3.org; wseltzer@w3.org
> 
> 
> Subject: Re: Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection
> 
>  
> 
> Paul - I think they are different issues, depending perhaps on the answer to the question I just posted on #288.
> 
>  
> 
> If Wendy's proposal applies in the narrow sense to implementation of the EME APIs defined in the specification and not to the CDM, then I expect Harry's concerns regarding the CDM still apply.
> 
>  
> 
> ...Mark
> 
>  
> 
> On Wed, Aug 3, 2016 at 7:52 AM, Paul Cotton <Paul.Cotton@microsoft.com> wrote:
> 
> > Can you please open an EME GitHub issue for your proposed change indicating exactly where in the specification you wish this text to be added?
> 
>  
> 
> We have now received a new EME issue that is proposing a very different approach to the question of  whether EME offers “a legal risk subjects any inspection of the DRM-enabled system on their computer due to the anti-circumvention provision of the DMCA or local equivalent.”  See https://github.com/w3c/encrypted-media/issues/288
> 
>  
> 
> I would to recommend that we fold your proposed change into the ISSUE-288 discussion since it is unlikely that we  would accept both proposed changes.
> 
>  
> 
> Comments?
> 
>  
> 
> /paulc
> 
>  
> 
> From: Paul Cotton [mailto:Paul.Cotton@microsoft.com] 
> Sent: Tuesday, August 2, 2016 9:55 AM
> To: Harry Halpin <hhalpin@w3.org>
> Cc: public-html-media@w3.org
> Subject: RE: Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection
> 
>  
> 
> > The text I would add to the EME spec would be similar: 
> 
> >"A conforming implementation of this specification MUST ensure that this API cannot be used without the user's express permission due to the inherent risks in the activation of a CDM in a user agent. The API MUST be disabled by default, and should only be activated when the user gives express consent and is fully informed on a per-origin basis."
> 
> Can you please open an EME GitHub issue for your proposed change indicating exactly where in the specification you wish this text to be added?
> 
>  
> 
> /paulc
> 
>  
> 
> From: Harry Halpin [mailto:hhalpin@w3.org] 
> Sent: Tuesday, August 2, 2016 5:00 AM
> To: public-html-media@w3.org
> Subject: Re: Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection
> 
>  
> 
>  
> 
>  
> 
> On 08/02/2016 03:00 AM, Paul Cotton wrote:
> 
> > An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection;
> 
> http://www.w3.org/2015/Process-20150901/#WGArchiveMinorityViews
> 
>  
> 
> Before I record your formal objection at [1] I would like to ensure that your “proposed change” for your objection is understood.
> 
> > There is prior art in HTML for similarly powerful and privacy-invasive features such as the Geolocation API [4]. Thus, there should be no procedural problem in requiring user consent and disabling EME by default in all browsers. 
> 
>  
> 
> The reference you provide as a “prior art” precedent in [4] is in a non-normative section of Geolocation API and it does NOT disable the Geolocation API by default.  Can you explain why you think this reference is useful here?  Are you suggesting similar text be added to EME?  If so could you suggest exact text that would remove your formal objection?
> 
> 
> The exact phrasing is " A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available through this API without the user's express permission" 
> 
> To clarify, I agree that the spec should have used capitalization: " A conforming implementation of this specification MUST provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available through this API without the user's express permission."
> 
> However, I do believe that all browsers *do* indeed ask for user consent before using the Geolocation API and that it is disabled by default, which is clear prior art for EME. This is indeed the case on the browsers I use, but if others activate Geolocation API without user consent, please do inform me, as I don't use Microsoft products. 
> 
> The text I would add to the EME spec would be similar: 
> 
> "A conforming implementation of this specification MUST ensure that this API cannot be used without the user's express permission due to the inherent risks in the activation of a CDM in a user agent. The API MUST be disabled by default, and should only be activated when the user gives express consent and is fully informed on a per-origin basis."
> 
> Given there is already a place where user consent MUST be asked in the EME spec (" User agents must ensure that users are fully informed and/or give explicit consent before Distinctive Identifier(s) are exposed, such as in messages from the Key System implementation"), there is no reason why this MUST can't be broadened. I would also remove the "or." The user must be fully informed AND give explicit consent. 
> 
> Furthermore, given this normative, testing for express user consent on a per-origin basis should be part of the test-suite. 
> 
>        cheers,
>                harry
> 
> 
> 
>  
> 
> /paulc
> 
> HME WG Chair
> 
>  
> 
> [1] https://dev.w3.org/html5/status/formal-objection-status.html
> 
>  
> 
> From: Harry Halpin [mailto:hhalpin@w3.org] 
> Sent: Monday, August 1, 2016 6:42 PM
> To: public-html-media@w3.org
> Subject: Formal objection to Encrypted Media Extensions progressing to Proposed Recommendation without greater user protection
> 
>  
> 
> [Note this is a formal objection as an individual in a private capacity, not on behalf of my organization]
> 
> I'd like to fill a formal objection against Encrypted Media Extensions progressing to Proposed Recommendation status without adequate protection for users. 
> 
> I believe that this work is so problematic given the well-known and well-documented problems with DRM,  it should not happen as a standard at all at W3C. That being said, for reasons which I do not agree with and hope he reconsiders, the Director has approved both the scope of the charter and the move of the Working Draft to Candidate Recommendation. 
> 
> If it does happen, then it seems given the well-documented problems, some harm mitigation should be pursued. The security research community has broad support for the EFF covenant being a normative requirement [1]. However, it appears consensus is not forthcoming on either EME itself or the EFF covenant, with the Technology and Policy IG also failing to gain any consensus for even further discussion (as it failed to even get chartered). 
> 
> To myself, the danger of EME is that over the last year suddenly over millions of people had a content decryption module installed without their explicit consent on their computer. For many users, such as those of Firefox, the DCM was installed via a silent update they had no control over. Such a content decryption module can serve as both a technical security risk, as it puts a highly privileged process in the user's computer outside their direct control by design, and as a legal risk subjects any inspection of the DRM-enabled system on their computer due to the anti-circumvention provision of the DMCA or local equivalent. Thus, regardless of whether or not one agrees with EME, it seems the *least* the W3C should do is warn the user about the installation and activation of a CDM on their machine - and that the CDM should not be installed and EME should not be activated without explicit user consent. Thus, in all configurations, EME should be *de-activated by default.*
> 
> There is prior art in HTML for similarly powerful and privacy-invasive features such as the Geolocation API [4]. Thus, there should be no procedural problem in requiring user consent and disabling EME by default in all browsers.  While it can be argued many users will want to watch protected videos and will turn them on, just as many users will want to use Google Maps with Geolocation APIs, there does not seem to be a reasonable case for having such 
> powerful and possibly dangerous features enabled by default. 
> 
> Current language in the spec is so weak as it may not be enforced and so EME does not have to be disabled by default: " User Agents have some flexibility to determine whether consent is required for a specific configuration and whether such consent may also apply to other configurations. For example, consent to one configuration may also imply consent for less powerful, more restricted configurations. Equally, a denial of consent for one configuration may imply denial of consent for more powerful, less restricted configurations."
> 
> The only place where the spec [5] makes normative statements around consent, but due to how DRM (i.e. Key Systems) are designed, it is unclear how the user agent should interpret these statements
> 
> "If a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured, the user agent should ensure that users are fully informed and/or give explicit consent before loading or invoking it."
> 
> "User Agents should ensure that users are fully informed and/or give explicit consent before a Key System that presents security concerns that are greater than other user agent features (e.g. DOM content) may be accessed by an origin..."
> 
> " User agents must ensure that users are fully informed and/or give explicit consent before Distinctive Identifier(s) are exposed, such as in messages from the Key System implementation."
> 
> Although these statements show some progress towards trying to mitigate the dangers of DRM, given that DRM systems work in conjunction with anti-circumvention legislation that prevents a developer from knowing whether or not they can sufficiently sandboxed (or 'otherwise secured') and whether a Distinctive Identifier is used by the DRM system, so the use of EME will *always* present security concerns that are greater than the rest of the user agent features involving the Open Web Platform. 
> 
> Is the Working Group amendable to having EME and associated DRM systems (i.e. "Key Systems") *normatively* disabled by default in order to protect users? 
> 
>    cheers,
>        harry
> 
> [1] https://www.eff.org/deeplinks/2016/03/security-researchers-tell-w3c-protect-researchers-who-investigate-browsers
> [2] https://en.wikipedia.org/wiki/Digital_rights_management#Opposition_to_DRM
> [3] https://en.wikipedia.org/wiki/Digital_rights_management#Shortcomings
> [4] https://www.w3.org/TR/geolocation-API/#implementation_considerations
> [5] https://w3c.github.io/encrypted-media/
> 
>  
> 
>  
> 
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 4 August 2016 22:06:38 UTC