- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 16 Aug 2016 19:49:54 +0200
- To: Mark Watson <watsonm@netflix.com>
- Cc: David Singer <singer@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <2d49595a-8699-e4c3-3b03-922a5dffdc12@w3.org>
On 08/16/2016 07:46 PM, Mark Watson wrote:
>
>
> On Tue, Aug 16, 2016 at 10:36 AM, 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.
>
>
> Unless the browser implementor takes additional measures to
> compensate for that difficulty / possible illegality.
I really do appreciate the work by this WG to compensate, but I do not
think they are sufficient without 'off by default.' We can agree to
disagree here, and let the WG make a decision and pass it to the
Director. In that case, the FO still stands.
>
>
> While I appreciate the effort,
> sandboxing may help but there is no such thing as a perfect sandbox.
>
>
> There is no such thing as a perfect security audit either. We're
> talking about different kinds of risk reduction.
>
Agreed. However, the DMCA provides a 'chilling effect' on security
audits and research on DRM systems in general, regardless of the
particular details of an audit or research.
>
> >
> >> 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.
> >
>
>
>
Received on Tuesday, 16 August 2016 17:50:33 UTC