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