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

> On Aug 16, 2016, at 11:41 , Harry Halpin <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.

Happily, clearkey can be analyzed and critiqued, since it’s publicly documented. And browser implementations are as critiquable as the rest of the browser — open-source browsers that implement EME with clearkey will presumably leave all of this in open-source, and so on.

> 
> 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.

No, really, this feels like playing with words in an attempt to confuse. The interface to something is not that something, and I refuse to believe that any engineer actually has that confusion.

>> 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.

If people want to provide and use operating systems with no safeguards or consent requirements on loading and installing random software, it is indeed none of the W3C's business. 

> 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*.

Why should the user’s choice to install 3rd party software on their system be something that’s part of the *browser*?  This makes no sense.

The browser can use fonts that the user chose to install. We don’t have anything stopping you using fonts until you enable ‘give my browser access to the fonts I chose to install’.  Some browsers support user style-sheets. The user chooses to install it, and it works; we don’t insist on a second step.  

When web plug-ins were common, one simply chose (or not) to install them; you didn’t have to separately enable the interface to plug-ins; the (reasonable) assumption is that if you chose to install something, you intended it to be usable.

>> 
>> 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.

And where is the *user risk* in innovation or lack of it?

> 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/

Actual letter here: <http://macdailynews.com/2007/02/06/apple_ceo_steve_jobs_posts_rare_open_letter_thoughts_on_music/>  You’ll note that ‘DRMs are a risk to end-users’ is not a part of it, as far as I can see.

> 
>> 
>> 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.

Why?  You’re completely failing to say why.

> 
>> 
>> 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,

No, you’re asking for additional matters on EME. Please stick to the subject. The browser interface to a plug-in is not the plug-in. I’m addressing EME, which is what is in the W3C scope.

> 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] .

"We set out to examine whether current, DRM-based online offerings of music and movies accord with consumers' current expectations regarding the personal use of copyrighted works by studying the behavior of six music, and two film online distribution services. We find that, for the most part, the services examined do not accord with expectations of personal use. The DRM-based services studied restrict personal use in a manner inconsistent with the norms and expectations governing the purchase and rental of traditional physical CDs, DVDs, and videocassettes. If adopted by consumers the DRM systems stand to alter the norms governing personal use of copyrighted content and create pitfalls of legal liability for unsuspecting consumers. In conclusion, we present technological and legal considerations which may help current and future DRM system designers better accommodate consumers' expectations of personal use.”

This is not a risk of harm.  This is a restriction on what you can do with the content.

> 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.

You have so far failed to enumerate risk or harm in EME per se.

Look, I don’t know anyone who *likes* DRM, but I don’t know anyone who has come up with a viable alternative. I am not a content owner, and I refrain from telling content owners “just trust the public, give away your content unprotected”. I get you don’t like DRM. Perhaps you should say that on your system, you won’t load any DRMs and so your choice will be to avoid such content.

>  Furthermore, EME is both a DRM system
> due to clearKey and an interface to specific CDMs, so the concerns
> around DRM naturally encompass EME.

No, clearkey is not the same level of problem as true DRMs, as noted above.


> 
>   cheers,
>         harry
> 
> [1] http://dl.acm.org/citation.cfm?id=947391
> 
>> 
>> 
>>> On Aug 16, 2016, at 10:36 , 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. 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
>>>>> 
>>>>>>> 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.
>>>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
>> 
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 16 August 2016 19:12:22 UTC