site-specific user-agent generated identity via DNT

[michael-oneill]

This is an idea I had a while ago and have discussed with some in and outside the WG.

There are are a (small) number of implementation aspects to it, but I want to discuss the general idea first and the main use cases.

The TPE allows for site-specific consent i.e. a user is asked for consent to their data being shared between a first-party and particular third-party sub-resources. Users are far more likely to agree if the data sharing is restricted in this way, and the request is not just a Trojan Horse for web-wide exposure. The data will only be shared within that context so it is important to show how this is being enforced.

When we talk about data sharing in a webpage context we usually mean UID sharing i.e. a high entropy selector encoded in user agent storage, e.g. cookies.

HTTP Cookies are not a good solution to this because 1) they are scoped to an origin and once accepted in one context will be available everywhere else (where the same third-party is embedded), and 2) are often blocked by default exactly for the reason they enable cross-domain tracking, see 1). The draft ePrivacy Regulation even asks (sensibly in my view) that this default becomes the norm.

What is needed is for an efficient way to communicate a UID amongst a group of origins but only within the context of a first-party site (an issue would be whether this should be generalised to descendant origin sub-resources but I will leave that for now).

There has been talk of "double keyed" cookies and there is some activity in Mozilla on this but as far as I know this had not become a W3C issue. There is some discussion about referring to them in the replacement for the IETF cooke standard (RFC 6265bis https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-00)

That's where we come in.

The DNT header already has the "context" issue licked, via the site-specific API, and already envisages extensions (beyond the first character in the header).

What I propose is that we describe the format of a UID as a DNT extension, and allow it to be set when the site-specific exception is stored. We automatically get continuous revoke and expiry and more important the exact tie up to user consent. The header is only communicated to the origin "targets", and the extension is only present when the DNT-field-value is "0"

The UID would be created by the user agent, i.e. not set by the API caller. Its value would be returned in the resolution to the Promise. Once it was revoked it would be gone forever, and only apply to the given context.

The obvious use case is online publishing. Advertising is an important revenue stream for them. Though it does not have to be behavioural there are still personal data protection issues with attribution. If the data sharing needed for this ( and behavioural or even re-targeting) could be better explained, i.e. it would only ever apply within the first-party context, users (i.e. subscribers) would be more likely to give their consent. This would be a boon to the online publishing ecosystem.

What do you think of it so far?

[michael-oneill]

Here is slightly extended rationale for this: https://github.com/w3c/dnt/blob/master/site-specific%20id%20and%20audience%20selector%20in%20DNT%20extensions

[michael-oneill]

Here is a Respec document expanding the rationale and adding technical meat. https://w3c.github.io/dnt/sitespecificconsent.html

[cpedigo]

Hi all - we support this idea and would like to see it included in the final product. With the ePrivacy Regulation and GDPR coming in the EU, it's clear that gaining consumer consent will be a key requirement in the EU. I've run Mike's idea by several of our members (both in the EU and here in the U.S.) and all have said this proposal would be useful. As Mike notes above, this would enable publishers to ask for and register site-specific tracking consent in a way that's more privacy friendly and persistent than using cookies.

Chris Pedigo Digital Content Next