Purpose Level Preferences

[shanewileyaz]

As industry has engaged further on preparations for GDPR compliance - and possible extensions of that compliance by drafts of ePR - a new likely requirement has emerged to allow DNT to be a viable solution in the EU marketplace - purpose level preferences. To date, it was thought by the TPWG that preferences tracked at the user / publisher / 3rd party levels would cover our needs. These are expressed in the current CR as a User Granted Exception at the site-wide level with a duple domain containing the first party domain (publisher) and the third parties domain (or web-wide with just the 3rd party domain). With the growing understanding now that a purpose tier will likely need to be added it is requested that the DNT standard be updated to support this critical element to be a viable option in the EU marketplace.

Purpose level consent maps to specific forms of data processing that each require individual consent from a data subject. For example, possible purposes could be "interest based advertising" or "cross-device mapping".

How to address this in the TPE? One path to support would be to add a purpose array to the UGE API calls. The current duple structure would be expanded to allow for the purpose array: (origin domain, 3rd party domain, purpose array). This would allow the following result:

Site-Wide: User / Publisher / 3rd Party / Purpose Web-Wide: User / 3rd Party / Purpose

While it would be "nice" to have the full consent scope returned in the page request header (DNT:0|1, 2, 4) this is not a hard requirement. As long as the purpose array can be client-side queried by local JS prior to calling the 3rd party ad server, then this can be passed along as part of the ad call.

This is only one possible example of a path to fulfill the market need. There are likely many other possible technical options to consider to support the same purpose level preference so hopefully this is the start of those discussions.

• Shane

Shane Wiley VP, Privacy Oath: A Verizon Company

[rvaneijk]

We should take the EU use case for a web wide opt-out for the purpose of audience measurement (aka web analytics) into account. We discussed the opt-out on many occasions, e.g. the global considerations taskforce in Berlin (2013). The current development is that the approach for web analytics is a carefully balanced one. The text of the LIBE compromise amendments for the ePR is as follows:

Article 8 Protection of information transmitted to, stored in, related to, processed by and collected from users’ terminal equipment

1. The use of processing and storage capabilities of terminal equipment and the collection of information from users’ terminal equipment, including about its software and hardware, other than by the user concerned shall be prohibited, except on the following grounds: (...) (d) if it is technically necessary for measuring the reach of an information society service requested by the user, provided that such measurement is carried out by the provider or on behalf of the provider, or by a web analytics agency acting in the public interest including for scientific purpose; that the data is aggregated and the user is given a possibility to object; and further provided that no personal data is made accessible to any third party and that such measurement does not adversely affect the fundamental rights of the user; Where audience measuring takes place on behalf of an information society service provider, the data collected shall be processed only for that provider and shall be kept separate from the data collected in the course of audience measuring on behalf of other providers; or (...)

See also the thread on public-tracking-comments: https://lists.w3.org/Archives/Public/public-tracking-comments/2017Oct/0022.html

[michael-oneill]

You mean we should have a generic purpose category of "exempted analytics"? For the purposes discussion this would require some purposes to be generic (say purposes 0 through 7 in my taxonomy) and others capable of being locally administered (declared in each domain's TSR).

[rvaneijk]

No, I mean we need extensions for DNT:1 as well as for DNT:0. Not sure yet about the solution, just marking the need for this functional requirement.

[royfielding]

@rvaneijk please add a new issue for that

[rvaneijk]

@royfielding ok, done.

[michael-oneill]

We could extend the API to be able to specify the header in the UGE store call, i.e. a DNTVal string property as suggested in Issue #6 and Issue #20. This could also meet some of the requirements for issue # 65.

It would let a first-party specify the header to be received (either itself web wide, or site specifically by targeted sub-resources). The DNTValvalue would be parsed in the storeTrackingException handler, and the UGE rejected unless either: 1) It simply contains the value "1", or 2) It contains a value of the form "0&p={any UTF8 string}", where anything after the first "0" is optional.

The first form is for registering DNT:1 in the case that the DNT general preference was unset, to indicate objection to web audience measurement (web-wide or site-specific) e.g. for Issue #65

The second form is for registering purposes as per this Issue.

After the first character (0 or 1), the value is structured as a list of zero or more attributes as name-value pairs separated by "&", which is a widely used convention for encoding cookie values. We only specify the "p" attribute for now, but other extensions could be supported in future and this format would allow them to be contained in the header in any order. A zero length attribute list would simply consist of "0", which would also be the default if the DNTVal property was null or undefined.

The value encoded in the "p" attribute can be opaque, agreed at least between the controllers of the sub-resources and the origin registering the UGE. We should extend the definition of the "policy" property to require that the page referenced by the returned Uri be dynamically created to show the particular purposes the user has agreed to as indicated in the "p" attribute (in the DNT header) in the request for the TSR.

[michael-oneill]

A first stab at text for the Purposes extension has been added to a snapshot of the current TPE draft as /drafts/purposes-snapshot.html. Here is the gh-pages view of it: https://w3c.github.io/dnt/drafts/purposes-snapshot.html#exception-javascript-api-store The sections to look at are : 5.2 DNT Header Field for HTTP Requests 6.6.1 API to Store a Tracking Exception 7.5.10 Purposes Property

[michael-oneill]

Here is the document I was asked to generate in the last call, extracting the purposes extensions into its own document.

https://w3c.github.io/dnt/drafts/PurposesAddendum.html

I have added some more descriptive text and responded to concerns expressed about fingerprinting by limiting the API to a site-specific call, when the API call is made within a user gesture, and the browsing context is secure.