- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 16 Aug 2016 20:56:33 +0200
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <f587671b-3f7d-9833-f58d-ec7cf7349de3@w3.org>
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