Align normative text on user consent for Distinctive Identifiers with privacy section

[mwatson2]

The non-normative Privacy sections states (Section 11.4.2):

"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."

However, the option to provide information has been dropped in the normative procedures (Section 3.1.2.1, Step 15):

"If there is no persisted consent covering accumulated configuration for the origin, it is recommended that implementations request user consent to use Distinctive Identifier(s)."

The Privacy text has been stable for some time and we have not discussed recommending consent in all cases. Whether explicit consent is necessary is a matter for user agents.

I propose modifying the text in 3.1.2.1 to the following:

"If explicit user consent for the use of Distinctive Identifiers is required and if there is no persisted consent covering accumulated configuration for the origin, it is recommended that implementations request user consent to use Distinctive Identifier(s)."

[jdsmith3000]

I agree with Mark's analysis, and his proposed change. I believe we've not previously reached a decision that user consent is required to use distinctive identifiers, and the current spec language seems to suggest.

[ddorwin]

This text was added six months ago to address bug 27165 from the TAG.

[mwatson2]

The TAG bug referred to the case of unclearable identifiers. We have done better than the TAG asked by making those non-compliant. This issue is not about that.

This issue is about the case of clearable (site-specific) identifiers, where the Privacy section has always required either that users are fully informed or that they give consent.

However, the normative procedures refer only to the case of explicit consent.

[ddorwin]

The bug summary refers to "unclearable identifiers", but the description refers to "identifiers that cannot be cleared along with regular cookies and site data." The spec text related to "cookie-like" clearing uses SHOULD and RECOMMENDED, so there would appear to be scenarios where the intent of the bug is not met (even with the current text recommending obtaining user consent).

If you want to make a proposal tying all of these together, that's fine. However, my reading of your current proposal is that it would recommend requesting consent if consent is required. That doesn't make sense - it's not actually required when required. You could drop RECOMMENDED, making it required when required, but you'd need to define when it is required.

"Fully informed" is also very broad and ambiguous. If your concern is that the recommendation in section 3.1.2.1 is too braod because it doesn't allow for the "fully informed" case, we may need to further clarify that that means.

[ddorwin]

Adding @domenic, filer of the original bug.

[domenic]

Yes, the intent of that bug was "identifiers that cannot be cleared along with regular cookies and site data." If "unclearable identifiers" is not the correct term for that, I apologize for the misleading phrasing.

[mwatson2]

The user interface mechanism for clearing EME distinctive identifiers is up
to User Agents implementors. We require that it must be possible for the
user to clear them. I'm not sure it's useful - or that the TAG intended -
for us to spend time on the case where a User Agent designs this mechanism
so as not to fall under the phrase "along with regular cookies and site
data". Is that the case you're concerned about ? I think it would be hard
for us to define in the spec which user interfaces met that requirement and
which did not.

I get what you are saying about the MUST / SHOULD mismatch. What I think
this section should say is that if the User Agent decides that consent is
needed and not previously obtained, it must be sought at this point in the
procedures, not at some later time.

The decisions on whether consent is needed, what kind of user interface
that is, exactly how the consent request is worded, or what kind of
information is provided as an alternative to consent are matters for User
Agent implementors: these are necessarily going to be "broad and ambiguous"
in our specification. Just the requirement to "obtain consent" is broad and
ambiguous: for what, exactly ? How will it be described so it is meaningful
to users ? How scary / friendly is the UI ? etc. We know these things are
all up to the User Agent.

If you think the Privacy section should be stronger with respect to when
consent is required and when informing users is sufficient, that's
something we could discuss, but I think that's a separate issue. Here I
just want to procedures to align with the Privacy section.

Revised suggestion for the procedural text:

"If the User Agent requires explicit user consent for the use of
Distinctive Identifiers and if there is no persisted consent covering
accumulated configuration for the origin, request user consent to use
Distinctive Identifier(s)."

On Mon, Jun 1, 2015 at 2:30 PM, Domenic Denicola notifications@github.com
wrote:

Yes, the intent of that bug was "identifiers that cannot be cleared along
with regular cookies and site data." If "unclearable identifiers" is not
the correct term for that, I apologize for the misleading phrasing.

—
Reply to this email directly or view it on GitHub
#63 (comment).

[ddorwin]

I agree that one intent of this text is to standardize the point at which UAs request/check consent. However, the text is also generally recommending that user agents obtain such consent for Distinctive Identifiers. If we are going to remove that general recommendation, we should have specific conditions that eliminate the need for such a recommendation.

The concern that led to the original bug was about standardizing access to semi-permanent client IDs into the (pluginless) web platform. There was also an example of silently abusing such identifiers in a DRM system exposed by a popular plugin. As such abusable capabilities are pulled into the web platform, it seems reasonable to at least recommend, if not require, mitigating such abuses.

The decisions on whether consent is needed, what kind of user interface
that is, exactly how the consent request is worded, or what kind of
information is provided as an alternative to consent are matters for User
Agent implementors...

There is precedent for a web spec to require user agents to acquire "the express permission of the user" "through a user interface".

Just the requirement to "obtain consent" is broad and
ambiguous: for what, exactly ? How will it be described so it is meaningful
to users ? How scary / friendly is the UI ? etc. We know these things are
all up to the User Agent.

That spec also contains (minimal) requirements on how the permission is acquired, what is shown in the UI, and that the permission to be revocable.

The user interface mechanism for clearing EME distinctive identifiers is up
to User Agents implementors. We require that it must be possible for the
user to clear them. I'm not sure it's useful - or that the TAG intended -
for us to spend time on the case where a User Agent designs this mechanism
so as not to fall under the phrase "along with regular cookies and site
data". Is that the case you're concerned about ? I think it would be hard
for us to define in the spec which user interfaces met that requirement and
which did not.

Converting the contents of https://w3c.github.io/encrypted-media/#allow-identifiers-cleared to an algorithm seems like a good start.

[mwatson2]

On Mon, Jun 1, 2015 at 5:07 PM, ddorwin notifications@github.com wrote:

I agree that one intent of this text is to standardize the point at which
UAs request/check consent. However, the text is also generally recommending
that user agents obtain such consent for Distinctive Identifiers.

​That recommendation is something we have never agreed, so it should be
removed on that basis.

What we have agreed is reflected in the Privacy section and is different,
giving more flexibility to User Agents.

If we are going to remove that general recommendation, we should have
specific conditions that eliminate the need for such a recommendation.

The concern
https://lists.w3.org/Archives/Public/www-tag/2014Oct/0106.html that led
to the original bug was about standardizing access to semi-permanent client
IDs into the (pluginless) web platform. There was also an example of
silently abusing such identifiers in a DRM system exposed by a popular
plugin. As such abusable capabilities are pulled into the web platform, it
seems reasonable to at least recommend, if not require, mitigating
such abuses.

​Absolutely. And I proposed such mitigations when I originally proposed the
Privacy section.​ That section has been strengthened since then.

Dominic's mail you link you says "We should consider requiring or strongly
recommending that user agents prompt or inform the user if an EME
implementation brings along identifiers that cannot be cleared along with
regular cookies and site data (similar to Mark’s “more privacy sensitive
than regular cookies” bar). Ideally we would require that such identifiers
be clearable along with cookies etc.---perhaps we should also strongly
recommend that?"

In fact, what the Privacy section does is already stronger than what
Dominic asks for: We require that user agents prompt or inform the user
if an EME implementation brings along identifiers that can be cleared
along with regular cookies and site data. And we require that identifiers
can be cleared. And we have plenty of recommendations around "can be
cleared along with regular cookies* and site data*" which could be made a
requirement as far as I am concerned, if you can define that.

I just want the normative procedures to align with what's in the Privacy
section.

The decisions on whether consent is needed, what kind of user interface
that is, exactly how the consent request is worded, or what kind of
information is provided as an alternative to consent are matters for User
Agent implementors...

There is precedent
http://www.w3.org/TR/geolocation-API/#privacy_for_uas_ for a web spec
to require user agents to acquire "the express permission of the user"
"through a user interface".

​Ok. If you would like this specification to follow that precedent you
should raise an issue for that and we can discuss it.​

Just the requirement to "obtain consent" is broad and
ambiguous: for what, exactly ? How will it be described so it is meaningful
to users ? How scary / friendly is the UI ? etc. We know these things are
all up to the User Agent.

That spec also contains (minimal) requirements on how the permission is
acquired, what is shown in the UI, and that the permission to be revocable.

​Good. Same point, though.​

The user interface mechanism for clearing EME distinctive identifiers is
up
to User Agents implementors. We require that it must be possible for the
user to clear them. I'm not sure it's useful - or that the TAG intended -
for us to spend time on the case where a User Agent designs this mechanism
so as not to fall under the phrase "along with regular cookies and site
data". Is that the case you're concerned about ? I think it would be hard
for us to define in the spec which user interfaces met that requirement and
which did not.

Converting the contents of
https://w3c.github.io/encrypted-media/#allow-identifiers-cleared to an
algorithm seems like a good start.

​I've no objection to that. We make the right recommendations there and if
UA implementors agree to have those strengthened, that's fine.

What I'm talking about here is the option for user agents to inform users,
rather than prompt, if that's what they feel is appropriate. This option
has been stable in the privacy section and was explicitly suggested in the
TAG comments, so it should be reflected in the normative procedures too.

—
Reply to this email directly or view it on GitHub
#63 (comment).

[mwatson2]

Following on from our discussion on the call, suppose we introduced an algorithm "Is explicit consent for use of Distinctive Identifiers required ?"

If that algorithm returns YES, the UA MUST prompt for explicit consent.

If that algorithm returns NO, the UA must either prompt for explicit consent or inform the user (if they have not already been informed).

What would that algorithm say ?

One option would be to say that the answer will be YES unless all the recommendations of the Privacy section are implemented, but I think that may be too strong. It's also a new proposal which I still think should be addressed as a separate issue from this one.

[mwatson2]

I created a Pull Request with a proposal for this issue. Consent is required if the recommendation for clearing identifiers together with cookies are not supported by the user agent or if the user agent so determines for other reasons. Otherwise, informing the user is an option.

I think this aligns more precisely with the TAG guidance.

[plehegar]

#66

[ddorwin]

@mwatson2, thanks for creating the PR. I've left comments there. Overall, the direction looks good.