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

On 08/13/2016 05:05 PM, Paul Cotton wrote:
>
> Note that I am responding to an email and proposal from Harry from
> earlier in this thread.
>
> https://lists.w3.org/Archives/Public/public-html-media/2016Aug/0005.html
>
>  
>
> >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."
>
>  
>
> This request would appear to be (at least partially) covered by the
> existing text in the EME CR:
>
> http://www.w3.org/TR/encrypted-media/#navigator-extension-requestmediakeysystemaccess
>
>  
>
> *3.1.1 Methods*
>
> *requestMediaKeySystemAccess*
>
> Note
>
> Calling this method may have /user-visible effects/, including
> requests for user consent. This method should only be called when the
> author intends to create and use a *MediaKeys*
> <http://www.w3.org/TR/encrypted-media/#idl-def-MediaKeys> object with
> the provided configuration.
>
> Requests access to the specified Key System
> <http://www.w3.org/TR/encrypted-media/#key-system>. When
> supportedConfigurationsis specified, the configuration specified by at
> least one of its elements must be supported. The resulting
> *MediaKeySystemAccess*
> <http://www.w3.org/TR/encrypted-media/#idl-def-MediaKeySystemAccess>
> will correspond to the first such element.
>
> Any permission checks or user interaction, such as a prompt, MUSTbe
> performed before resolving the promise.
>
> Were you aware of this text in the EME specification?  Can you live
> with the current text since changing this text to be normative and
> changing it to a MUST (I believe) would be a “breaking change” and
> would require that we re-publish another EME CR?
>
>  
>
> /paulc
>
> HME WG Chair
>

Paul,

Thanks for noting 'use-visible effects' but it does not either
explicitly 1) require a user-visible effect for fully informing the
user" and "gaining their consent" as well "turning off EME by default".
Simply put, the text you are noting says MAY have user-visible effects
and as so is too weak to include in a test-suite or support EME being
off by default. So, it does not cover my objection, which normatively
requires much stronger text, including "off by default". So, no I can't
live with that text and require the change (or a semantically equivalent
one) that I suggest in the github repo and e-mail list:

https://github.com/w3c/encrypted-media/issues/304

Thus, my formal objection still stands.

  cheers,
      harry

>  
>
>  
>
> *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 <mailto: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/
>
>  
>