- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 16 Aug 2016 10:46:49 -0700
- To: Harry Halpin <hhalpin@w3.org>
- Cc: David Singer <singer@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CAEnTvdDCZJG3pqk6d3avp4nLdZDp76kwTkgOJsfrNq0MUQMnrQ@mail.gmail.com>
On Tue, Aug 16, 2016 at 10:36 AM, 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. Unless the browser implementor takes additional measures to compensate for that difficulty / possible illegality. > 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. > > > > >> 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 > >> > >>> > >>>> 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/ > 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 > >>>>> > >>>>> 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- > 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/ > >>>>> > >>> David Singer > >>> Manager, Software Standards, Apple Inc. > >>> > >> > >> > > David Singer > > Manager, Software Standards, Apple Inc. > > > > >
Received on Tuesday, 16 August 2016 17:47:20 UTC