Re: Formal objections to Encrypted Media Extensions

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.