- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 16 Aug 2016 11:50:46 -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: <CAEnTvdAsTyJufhZOgXcDrwpCdxcBxdXq0eBCuQBQfhXYT7rAwQ@mail.gmail.com>
On Tue, Aug 16, 2016 at 10:49 AM, Harry Halpin <hhalpin@w3.org> wrote: > > > On 08/16/2016 07:46 PM, Mark Watson wrote: > > > > 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. > > > 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. > But there are things that can be done to compensate for the risk that any such effects cause. Sandboxing and strict input / output validation is one thing. Funding additional security audits could be another. Actively encouraging independent security research into that component is another. > > >> > >> >> 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. >> > >> >> >> > >
Received on Tuesday, 16 August 2016 18:51:17 UTC