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

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
>>> <https://www.law.cornell.edu/uscode/text/17/1201> or similar copyright
>>> laws in other jurisdictions.
>>>
>>>
>>>
>>> And DMCA Section 1201 <https://www.law.cornell.edu/uscode/text/17/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 <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/
>>>
>>>
>>>
>>>
>>>
>>
>>
>