- From: Harry Halpin <hhalpin@w3.org>
- Date: Tue, 16 Aug 2016 21:05:11 +0200
- To: public-html-media@w3.org, Wendy Seltzer <wseltzer@w3.org>
- Message-ID: <879d53bc-4ec6-3ae8-9fc6-8a979273bb56@w3.org>
@Wendy - see question below provoked by Ruben's email.
On 08/16/2016 09:00 PM, Mark Watson wrote:
>
>
> On Tue, Aug 16, 2016 at 11:56 AM, Harry Halpin <hhalpin@w3.org
> <mailto:hhalpin@w3.org>> wrote:
>
>
>
> 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.
>
>
> I was referring to the DMCA language: '... technology that
> /effectively/ controls ...' IIRC. But, for sure, IANAL, as I said. If
> W3C would like to get a legal opinion on this than that might be
> useful. I expect if the opinion was that Clear Key rendered the EME
> specification itself subject to DMCA then we should consider removing
> Clear Key from the specification.
Precisely. Wendy, what's your take on it?
I agree it's not effective, but Ruben noted (to my surprise, but I think
he may be right) that clearKey may be 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 19:05:20 UTC