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

Hi Harry,

I would  like to keep open the possibility for any risks to be mitigated to
the extent that consent is not necessary. I would also like sites to be
incentivized to choose options which don't incur additional risks (for
example additional tracking surface) and the absence of consent prompts
provides such an incentive.

In several cases I don't see a practical difference from a review and
research perspective between the CDM and the rest if the browser code. If
the browser/CDM vendor is offering financial reward for disclosure of
vulnerabilities, it seems unlikely researchers would be concerned about
legal risk from the same browser/CDM vendor (but this is something I've
suggested the W3C could usefully study).

I understand you disagree. Just explaining why I think a blanket
requirement for consent would be harmful.

...Mark


On Tue, Aug 2, 2016 at 1:48 AM, Harry Halpin <hhalpin@w3.org> wrote:

>
>
> On 08/02/2016 01:56 AM, Mark Watson wrote:
>
> Hi Harry,
>
> This may not be the right list for discussion of in-principle objections
> or the covenant proposal, but I wanted to quickly respond to a couple of
> mis-conceptions about our work below:
>
> On Mon, Aug 1, 2016 at 3:42 PM, Harry Halpin <hhalpin@w3.org> wrote:
>
>> [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.
>>
>
> ​A large amount of effort has been devoted to this, yes.​
>
>
>> 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
>>
>
> ​I don't believe this is the case. The CDM - at least in Firefox's case -
> is highly sandboxed and the sandbox is open source code. So what the CDM
> can and cannot do on the user's computer is constrained and those
> constraints are open and verifiable.​ It certainly does not have access to
> the filesystem, for example and the handling of identifiers is very
> precisely constrained by the specification to avoid an increase in tracking
> surface.
>
>
> I disagree. While of course sandboxing helps and should be encouraged,
> research in the security community shows that browser sandboxing is *never*
> perfect [1]. Thus, the security of the sandbox is *always* relative to the
> code running in the sandbox. Also, I am not aware of any actual formal
> verification or even thorough independent analyisis of Firefox's sandbox
> regarding the CDM, or any other browsers. If you have links, please share.
>
>
>
>
>
>> 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
>>
>
> ​If such installation / activation exposed the users to any privacy or
> security risks, then yes, they should be asked to give consent.​
>
> To all of the points below, the User Agent is the user's agent and it is
> User Agent implementors who ultimately decide when consent / information is
> required to protect user security and privacy. If they choose not to do so,
> it is because they do not believe there are any additional security or
> privacy risks. We expect User Agent implementors to take this
> responsibility seriously and not to integrate with CDMs where they do not
> have sufficient information / insight to provide users with the guarantees
> they expect / deserve. The DMCA does not prevent CDM vendors sharing
> details of their product with their browser-implementing customers.
>
>
> However, as *is already* the case with the Geolocation API, the spec can
> quite easily specify that it's mandatory to ask users for consent before
> usage of EME.  I think 'we expect user agent implementers to do the right
> thing' is not protection enough for end-users.  The issue re the DMCA is
> that it prevents sharing details of their CDM products to the security
> research community and customers, who have shown again and again to be able
> to discover flaws and security vulnerabilities that the browser implementer
> community has missed [2].
>
>
> It is actually a *better* outcome if the CDM is so constrained that no
> consent is necessary (because there *are* no additional risks), than if
> there are additional risks and consent is therefore required.
>
>
> As a CDM *always* creates additional risks (by design due to the
> anti-circumvention clause of the DMCA), I believe that consent *must* be
> necessary and so must disabling the CDM by default. As the arguments
> offered here do not convince me and this change of the spec is clearly
> within scope of the Working Group, I am not satisfied with the response and
> my formal objected is still filed.
>
>
> ...Mark
>
>
> cheers,
>
>     harry
>
> [1] http://arxiv.org/abs/1502.07373
> [2] http://in.bgu.ac.il/en/Pages/news/CSRC-Chrome.aspx
>
>
>
>> - 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/
>>
>
>
>