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

On Tue, Aug 16, 2016 at 11:56 AM, Harry Halpin <hhalpin@w3.org> wrote:

>
>
> On 08/16/2016 08:52 PM, Mark Watson wrote:
>
>
>
> On Tue, Aug 16, 2016 at 11:41 AM, Harry Halpin <hhalpin@w3.org> wrote:
>
>>
>>
>> On 08/16/2016 07:51 PM, David Singer wrote:
>> > I think you are confusing DRM and EME.  They are not the same.
>>
>> Actually, as pointed out by Ruben's email I just read, clearKey would
>> count as DRM and be covered by the DMCA - and is part of the EME spec. I
>> hadn't thought that through earlier but it's a very good point. The
>> addition of clearKey would likely made EME itself covered by the DMCA.
>>
>
> ​IANAL, but I think a case could be made that Clear Key is not an
> "effective" protection measure, since the key is available, well, in the
> clear. Certainly, no one would call it a "DRM".
>
>
> I think whether or not it is an 'effective' protection measure is
> separable from whether or not its covered by the DMCA.
>

​I was referring to the DMCA language: '... technology that *effectively*
controls ...​' IIRC. But, for sure, IANAL, as I said. If W3C would like to
get a legal opinion on this than that might be useful. I expect if the
opinion was that Clear Key rendered the EME specification itself subject to
DMCA then we should consider removing Clear Key from the specification.



> That's a legal question - if Netflix or any other company with a legal
> dept. (or W3C) would like to answer that question, I believe it would be of
> interest. The question Ruben provoked should probably be answered before
> the spec goes to Rec.
>
> ​
>
>
>>
>> Regardless of the clearKey specifics,  EME exists to enable access to a
>> CDM in a manner standardized across browser, and is thus part of a
>> DRM-enabled system.
>>
>> >
>> > EME can be shipped as an intrinsic part of the browser. The user will
>> be asked to install XYZ DRM by any operating system I can think of. If they
>> agree and consent to that, you’re asking for an extra step “do you also
>> agree to enable access to this module from your browser?’, when in all
>> likelihood that is the very reason they chose to install it.
>>
>> However, the OS is outside control of the W3C and does not have any
>> standards. Thus, we cannot guarantee there will be agreement and
>> consent. So I don't think you can just shove this step to the OS, but it
>> should be required by the spec and done in *browser*.
>> >
>> > It makes no sense to me. It doesn’t deal with any risk you have so far
>> enumerated.
>>
>> I would suggest just revisitng the Wikpedia page and following the large
>> number of links. Note they go beyond security research, including
>> problems with innovation. Accessibility concerns have also been raised.
>> These are not new issues, but well-known. Which is why Steve Jobs took a
>> stand against DRM:
>>
>> https://www.engadget.com/2007/02/06/a-letter-from-steve-jobs
>> -on-drm-lets-get-rid-of-it/
>>
>> >
>> > That security researchers haven’t assessed XYZ DRM is a risk to you is
>> not the same as whether the EME implementation is a risk to you.
>>
>> As EME opens the door for using (and MSE possibly installs) XYZ DRM, yes
>> it is.
>>
>> >
>> > I’m sorry to press on this, but we need to be clear, because risk
>> mitigation is based in being really clear what the risk is.  At the moment,
>> I don’t see any risk in parts of the browser that are the *interface* to
>> modules that the user may choose to load. They might be there, but
>> conflating the risk of the module itself with the interface is not helping
>> get clarity.
>>
>> If your argument is that DRM is not a risk to end-users, then there is
>> widespread disagreement from the independent security and legal
>> community on your point as evidenced by both Wikipedia and various
>> papers by well-respected acaemics that focussed on users  [1] . From my
>> individual perspective, it seems the only people who argue that DRM is
>> not a problem for end-users is people whose job it is to implement DRM,
>> groups whose income depends on revenue from DRM implementers,  and the
>> various groups that stand to make profit from DRM. Thus, it is unclear
>> if any of those viewpoints are sufficiently neutral to address the harm
>> to users that DRM could cause.  Furthermore, EME is both a DRM system
>> due to clearKey and an interface to specific CDMs, so the concerns
>> around DRM naturally encompass EME.
>>
>>    cheers,
>>          harry
>>
>> [1] http://dl.acm.org/citation.cfm?id=947391
>>
>> >
>> >
>> >> On Aug 16, 2016, at 10:36 , Harry Halpin <hhalpin@w3.org> wrote:
>> >>
>> >>
>> >>
>> >> On 08/16/2016 07:28 PM, David Singer wrote:
>> >>>> On Aug 16, 2016, at 10:22 , Harry Halpin <hhalpin@w3.org> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 08/16/2016 06:35 PM, David Singer wrote:
>> >>>>> I think you’ll need to explain why the choice of how much, and how,
>> the user is warned, needs to be made by you/us, and not by the browser
>> maker.  You also haven’t given details of the ‘user harm’ you talk about
>> for EME itself.
>> >>>> The details of 'user harm' are adequately explained by the concerns
>> over
>> >>>> the DMCA and the use of DRM that have been well-documented elsewhere
>> >>>> [1].
>> >>> No, those criticisms were almost exclusively focused on the risk to
>> security researchers. Not one of the sub-headings you link to appears to
>> apply to users.  Current politics notwithstanding, repeatedly stating
>> something doesn’t intrinsically make it true.
>> >> I don't agree.  Insofar as security researchers cannot audit the
>> >> security of DRM systems, then it is *users* who will face any harm due
>> >> to the lack of security audits. That is a unique feature of DRM that
>> EME
>> >> enables. EME can also, due to clearkey, be considered a DMCA-compliant
>> >> system itself (i.e. clearKey's Key System is equivalent to a CDM).
>> >>
>> >>>> Any installation or use of software that is compliant with the DMCA
>> >>>> can be considered a risk to users and security researchers as is
>> noted
>> >>>> on WIkipedia [1].
>> >>> Users and security researchers are not the same people.
>> >> See above.
>> >>
>> >>>> Although the FO is filed as an individual, one task of W3C is to
>> assure
>> >>>> there is representation of the interest of users and to ensure the
>> Web
>> >>>> is secure.
>> >>> Sure, but you need to say what the *user* harm is.
>> >> If there is a part of a browser that makes security research difficult
>> >> and possibly illegal,  then that part of the browser is rather
>> >> self-evidently dangerous to end-users. While I appreciate the effort,
>> >> sandboxing may help but there is no such thing as a perfect sandbox.
>> >>
>> >>>> So, I think the decision should be made by the Working Group
>> >>>> with the best interests of users in mind, not just the browser
>> makers.
>> >>>> While you can consider 'off by default' to be unreasonable, I think
>> if
>> >>>> one takes that this same approach has been adopted by similarly
>> >>>> controversial APIs (Geolocation API), I think it's quite reasonable.
>> >>>>
>> >>>>  cheers,
>> >>>>       harry
>> >>>>
>> >>>> [1]
>> >>>> https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A
>> ct#Criticisms
>> >>>>
>> >>>>>> On Aug 16, 2016, at 4:28 , Harry Halpin <hhalpin@w3.org> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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/2016A
>> ug/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-re
>> questmediakeysystemaccess
>> >>>>>>>
>> >>>>>>> 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 object with the provided
>> configuration.
>> >>>>>>> Requests access to the specified Key System. When
>> supportedConfigurations is specified, the configuration specified by at
>> least one of its elements must be supported. The resulting
>> MediaKeySystemAccess will correspond to the first such element.
>> >>>>>>> Any permission checks or user interaction, such as a prompt, MUST
>> be 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
>> >>>>>>> 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-t
>> ell-w3c-protect-researchers-who-investigate-browsers
>> >>>>>>> [2] https://en.wikipedia.org/wiki/Digital_rights_management#Oppo
>> sition_to_DRM
>> >>>>>>> [3] https://en.wikipedia.org/wiki/Digital_rights_management#Shor
>> tcomings
>> >>>>>>> [4] https://www.w3.org/TR/geolocation-API/#implementation_
>> considerations
>> >>>>>>> [5] https://w3c.github.io/encrypted-media/
>> >>>>>>>
>> >>>>> David Singer
>> >>>>> Manager, Software Standards, Apple Inc.
>> >>>>>
>> >>>>
>> >>> David Singer
>> >>> Manager, Software Standards, Apple Inc.
>> >>>
>> > David Singer
>> > Manager, Software Standards, Apple Inc.
>> >
>> >
>>
>>
>>
>>
>
>