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

On 08/16/2016 08:52 PM, Mark Watson wrote:
>
>
> On Tue, Aug 16, 2016 at 11:41 AM, Harry Halpin <hhalpin@w3.org
> <mailto: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. 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/
>     <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
>     <http://dl.acm.org/citation.cfm?id=947391>
>
>     >
>     >
>     >> On Aug 16, 2016, at 10:36 , Harry Halpin <hhalpin@w3.org
>     <mailto: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
>     <mailto: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_Act#Criticisms
>     <https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act#Criticisms>
>     >>>>
>     >>>>>> On Aug 16, 2016, at 4:28 , Harry Halpin <hhalpin@w3.org
>     <mailto: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/2016Aug/0005.html
>     <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
>     <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
>     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
>     <https://github.com/w3c/encrypted-media/issues/304>
>     >>>>>>
>     >>>>>> Thus, my formal objection still stands.
>     >>>>>>
>     >>>>>> cheers,
>     >>>>>>     harry
>     >>>>>>
>     >>>>>>> From: Harry Halpin [mailto:hhalpin@w3.org
>     <mailto:hhalpin@w3.org>]
>     >>>>>>> Sent: Tuesday, August 2, 2016 5:00 AM
>     >>>>>>> To: public-html-media@w3.org <mailto: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
>     <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
>     <https://dev.w3.org/html5/status/formal-objection-status.html>
>     >>>>>>>
>     >>>>>>> From: Harry Halpin [mailto:hhalpin@w3.org
>     <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
>     <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
>     <https://en.wikipedia.org/wiki/Digital_rights_management#Opposition_to_DRM>
>     >>>>>>> [3]
>     https://en.wikipedia.org/wiki/Digital_rights_management#Shortcomings
>     <https://en.wikipedia.org/wiki/Digital_rights_management#Shortcomings>
>     >>>>>>> [4]
>     https://www.w3.org/TR/geolocation-API/#implementation_considerations
>     <https://www.w3.org/TR/geolocation-API/#implementation_considerations>
>     >>>>>>> [5] https://w3c.github.io/encrypted-media/
>     <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.
>     >
>     >
>
>
>
>

Received on Tuesday, 16 August 2016 18:56:52 UTC