Re: Formal objections to Encrypted Media Extensions

Yes, David is correct. I should have been more careful with my description.
What I mean is that we do require consent in some cases, for example some
cases involving Distinctive Identifiers. The exact details of when consent
is required at buried in the specification.

...Mark

On Wed, Sep 7, 2016 at 5:37 PM, David Dorwin <ddorwin@google.com> wrote:

> On Wed, Sep 7, 2016 at 7:57 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> There are certainly cases where there are privacy concerns - in particular
>> when distinctive identifiers are used - and we do require prompts in those
>> cases.
>>
>
> The spec is not as clear-cut in this area as the above statement implies.
>
> Specifically, per the relevant algorithm
> <https://w3c.github.io/encrypted-media/#get-consent-status>:
>
>    - There is no explicit requirement to "prompt." The language used is
>    "request user consent," though I'm not sure what implementations other than
>    a prompt might satisfy this.
>    - Permission/prompt/consent is *not* required for *all* uses of Distinctive
>    Identifiers
>    <https://w3c.github.io/encrypted-media/#distinctive-identifier>.
>       - Consent is only *required* if the implementation "does not
>       support the recommendations of Allow Persistent Data to Be Cleared
>       <https://w3c.github.io/encrypted-media/#allow-persistent-data-cleared> with
>       respect to Distinctive Identifier(s)."
>       - Those recommendations are basically allowing the identifiers to
>       be cleared using the same clearing and "clear browsing history" features as
>       other site data, including per-origin.
>    - Thus, *if* those recommendations are implemented, no consent is
>    required to use a Distinctive Identifiers, even one that, for example, is
>    obtained by providing a Distinctive Permanent Identifier to an
>    individualization server.
>
>
> The spec *does* *require* that the user be *informed* about the use of
> Distinctive Identifiers:
>
>    - The same algorithm as above says, "If the distinctiveIdentifier
>    member of accumulated configuration is not "not-allowed", return
>    InformUser," which will cause the user agent to "Inform the user that
>    accumulated configuration is in use in the origin including, specifically,
>    the information that Distinctive Identifier(s) and/or Distinctive Permanent
>    Identifier(s) as appropriate will be used..."
>    - https://w3c.github.io/encrypted-media/#privacy-prompts says, "User
>    agents MUST ensure that users are fully informed and/or give explicit
>    consent before using Distinctive Identifier(s) and Distinctive Permanent
>    Identifier(s)."
>
> However, there is no specification of what informing the user or ensuring
> the users is "fully informed" means.
>
>
> Returning to security, while there is no requirement for consent, two
> sections in the Security section already say user agents "SHOULD ensure
> that users are fully informed and/or give explicit consent before" using a
> Key System "that cannot be sufficiently sandboxed or otherwise secured" or
> "that presents security concerns that are greater than other user agent
> features (e.g. DOM content)."
>
> However, again, there is no concrete definition of "sufficiently sandboxed
> or otherwise secured" or "presents security concerns that are greater than
> other user agent features." Also, these are currently SHOULDs rather than
> MUSTs. (I filed https://github.com/w3c/encrypted-media/issues/312 for
> discussion.)
>
>
> On Wed, Sep 7, 2016 at 8:47 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>> I think the two points are:
>> - non-ClearKey Key Systems may be pre-installed in some User Agents, or
>> automatically installed by the User Agent
>>
>
> For completeness: The Key System may also be part of the platform or
> provided or installed by the OS.
>
> - one could argue that consent should be per-origin
>>
>
> I think another/related point is that while there are many ways that Key
> Systems may come to be present on the user's client, prior to EME, they
> (and their privacy and security properties) were not generally exposed to
> the entirety of the web. That is, their use often depends on installation
> of a separate application or other software with a more limited purpose and
> accessibility. (Plugins are an exception, but they are also not a good
> benchmark.)
>
>
>> Indeed, where there *is* a genuine privacy risk, consent should be
>> obtained and should be per origin. This is what we require for some
>> distinctive identifier cases, for example.
>>
>
> See above. For Distinctive Identifiers, consent is not always required but
> informing the user is. For security concerns, though, neither is
> *required*.
>
>
>> So, the argument is basically whether there *always* exists risks of this
>> kind or whether we believe User Agents can mitigate those sufficiently (or
>> at least should be given an opportunity to do so).
>>
>
> This is similar to previous discussions of security and privacy concerns
> where we debated easy-to-explain-and-observe requirements vs. relying on
> the user agent or Key System to mitigate the concern.
>
> There is also the question of whether user agents *will* mitigate such
> risks or follow the recommendations. Evaluation of current implementations
> against the existing recommendations and requirements, such as those above,
> may give some indication.
>