opened
steelejoe
username_0
Section 9.4 contains the following text:

"Such implementations should not use identifiers for a device or user of a device in the individualization process."

This is too broad. I proposed instead the following:
"Such implementations should not directly provide identifiers for a device or user of a device in any messages sent during the individualization process. "

This allows for implementations which generate unique identifiers not directly associable with the device or user by digesting a mixture of device identifiers. These identifiers can have the security property that two different devices are unlikely to generate the same identifier, but also have the privacy property that it is very difficult to match an identifier to a user+device.

David suggested looking for guidance to [this email thread](https://lists.w3.org/Archives/Public/public-html-media/2014Oct/0092.html).

Original bug was [Bug 27168](https://www.w3.org/Bugs/Public/show_bug.cgi?id=27168).
Individualization text regarding device identifiers is overly broad and restrictive
issue
created
ddorwin
username_1
The point is to prevent tracking, especially across origins and after the user clears Distinctive Identifier(s) and other state. I believe "not directly provide" is too vague to cover the privacy concerns. Specifically, data passed to the application should be be reversible (i.e. just XORing the origin) and data/identifiers provided to the application after the user clears the previous identifiers must be different and not reversible or otherwise correlatable with the previous value.

It appears that @username_4's [description of Firefox's implementation](https://lists.w3.org/Archives/Public/public-html-media/2014Oct/0092.html) (search for "ingredients") meets these requirements, and the spec text is not intended to prevent such implementations.

I see how the current text could prohibit the first ingredient, so we should figure out how to place appropriate restrictions on the use of such ingredients.
comment
created
steelejoe
username_0
I agree that we should add some specific text that references this requirement. Is this text specific enough in your opinion?

"Such implementations which use Distinctive Identifier(s) for a device or user of a device during the individualization process must apply a non-reversible data transformation to the identifiers which includes per-origin information (e.g. a cryptographic hash algorithm)."
comment
created
jdsmith3000
username_2
@username_0 This language appears to allow a non-origin specific Distinctive Identifier that is permanently modified with origin specific information.  That would appear to make it an origin specific identifier in actual use, though one apparently derived from a single non-origin specific root identifier.  Is that your intent?  Does this actually need to be stated as such in the EME spec?
comment
created
ddorwin
username_1
We'll need a clear definition of Distinctive Identifier (issue #117) before we can decide on text that references it.
comment
created
ddorwin
username_1
Let's re-triage this after blocking bug #117 is resolved.
comment
created
jdsmith3000
username_2
Reviewed by the editors (@username_1, @username_3, @jdsmith).  We believe this issue may resolve when issue #117 is completed.  We will confirm back with @username_0 then.
comment
created
ddorwin
username_1
The language referenced in the original report was probably intended to prevent permanent/indelible values from being passed to the application. This is still disallowed. However, a Distinctive Identifier is not a permanent identifier, so the language may not be appropriate. Because Distinctive Identifiers are per-origin, clearable, non-associable, etc., it should be okay to pass them to the application for Per-Origin Individualization just as they are passed to 

One way to look at this might be that the hash of the ingredients is a Distinctive Identifier that is passed to the application to generate a new Distinctive Identifier.

I believe the changes for #117 address the issue of associability and "non-reversible data transformation."

It seems we want to allow (the new definition of) Distinctive Identifiers while prohibiting exposure of permanent/indelible/associable values.

I will make a PR for review and discussion.
comment
created
ddorwin
username_1
I created PR #234. Please review so I can move forward with related issues.
comment
created
mwatson2
username_3
LGTM with the small comments I made in the PR.
comment
created
mwatson2
username_3
The present text appears to class such identifiers as "Distinctive Identifiers" even if they are not associable by any entity across clearing by the user or across origins.

Isn't the definition of Distinctive Identifier supposed to be those that are associable by some entity ?
comment
created
ddorwin
username_1
I interpreted the original point as the requirement that "Such implementations MUST NOT use Distinctive Identifier(s)" was too restrictive. This allows Distinctive Identifiers to be used, but the resulting values are still Distinctive Identifiers.

As noted in https://github.com/w3c/encrypted-media/pull/234#discussion_r66361853, this is due to the current definition of Distinctive Identifier. We don't have a definition for which types of derivations are acceptable. See also #219.
comment
created
ddorwin
username_1
I believe PR #234 significantly improves the state of this section, which was out of date, and brings us much closer to addressing this issue. In the interest of the timeline and conflicting PRs, should we remove "Fix" from the commit summary, merge the PR, and continue to work on this issue with a new more-relevant base?
comment
created
mwatson2
username_3
Yes, that makes sense.
comment
created
hsivonen
username_4
If any random tracking script can initiate an EME flow and get back a stable (until cleared by explicit user action), even if origin-specific, identifier without ever talking to an indiv or key server (i.e. not continuing the EME flow beyond initial poking at the API to elicit the initial message), this adds a new, and illegitimate in the light of the purpose of EME, repeat visit tracking mechanism.

In the indiv case, it would be problematic if tracking tech could trigger indiv in a way that exposes a Distinctive Identifier visibly to the JS and not only to an indiv server is possession of some secret to decrypt the indiv request and the same Distinctive Identifier was exposed on a subsequent visit. Then tracking tech could elicit indiv messages and never forward them to an indiv server as a way to track repeat visits to a site.

Obviously, if the site actually has a key server or indiv server for the Key System, then, technically, the site/app gets to see a Distinctive Identifier as unwrapped by the server, but at least tracking tech has the barrier of obtaining and operating such a server as well as potentially the licensing terms for such server.
comment
created
jdsmith3000
username_2
Issue #246 carries forward some discussion topics for EME during CR.  Issue #110 is closed.
comment
closed
jdsmith3000
username_2
issue
created
ddorwin
username_1
@username_4, I hope the following is helpful. Please let us know if you still have concerns or if you have suggestions for improvement. For general issues not related to App-Assisted Individualization, it might help to file separate issues.

I agree with the concerns in your first paragraph. For Distinctive Identifiers, we essentially only require consent if the value cannot be cleared like a cookie and other site data. See #246. Otherwise, the implementation must "Inform the user that... Distinctive Identifier(s) and/or Distinctive Permanent Identifier(s) as appropriate will be used..."  What form "informing" takes is left up to the implementation, but it is certainly not as strong as obtaining consent.

For all other identifiers or potentially identifying/trackable values, there is no requirement except that they must be [clearable](https://w3c.github.io/encrypted-media/#allow-identifiers-cleared) and SHOULD be [clearable along with cookies and other site data](https://w3c.github.io/encrypted-media/#allow-persistent-data-cleared). Thus, it is possible to get a "cookie-like" tracking value, though not necessary that it be as easy to clear as a cookie. (Perhaps the "SHOULD" should be a "MUST" if there is no consent or informing.)

https://w3c.github.io/encrypted-media/#encrypt-identifiers addresses some of the concerns in your second paragraph:
- Distinctive Identifiers MUST be encrypted.
- "The encryption MUST ensure that the ciphertext cannot be used as a proxy for the actual identifier, even given the same plaintext."
- "The CDM MUST verify that the encryption key belongs to a valid server for its Key System."

However, other types of values only SHOULD be encrypted. We could make that a MUST, but we would need to define "identifier" since nearly anything exposed to the application could be used as an identifier (just like cookies and other site data). The question is where to draw the line given the existence of many other types of persistent data. Allowing all types of data to be cleared together seems important as does ensuring values (other than Distinctive Identifiers and Permanent Identifiers, which have separate considerations) are no worse than other types of data seems important. See my third paragraph above.

Specific to the"indiv case," I'm not sure this is much different from generating a request where such individualization is not necessary. In both cases, a message with an identifier may be generated. If there are differences, we may want to address them. Note that no message can be sent to the application (and neither type of provisioning may occur, though I'm not sure this is explicitly stated) without going through `requestMediaKeySystemAccess()`, so all the _opportunities_ for a user agent to _choose_ to get consent or otherwise inform the user are still available. (While it may not be obvious in the text, the individualization process can only use Distinctive Identifiers if the result of the `requestMediaKeySystemAccess()` call included `distinctiveIdentifier="required"`. See #248.)

Regarding your last paragraph, this controlling access to servers (and server certificates) is an important option for implementations, but I don't think we should assume all Key System vendors closely control them or they are only given to "good actors." Thus, the other privacy mitigations remain important.

Admittedly, the mitigations above depend on the implementations, including the CDM, which the user agent may not have great insight into. Even the ability to clear cookies depends on the user agent, though it is a much more well-established pattern.
comment