RE: ISSUE-43, ACTION-60: let the user know their options when arriving with Do Not Track

David,

In our draft language for SiteSpecificExceptions (perhaps this is now SiteSpecificExemptions) I suggested that a 1st party receive a DNT:2 signal to let them know that SiteSpecifcExceptions/Exemptions exist for their site.

DNT:<null>  (user has not yet expressed a preference)
DNT:0 (user expressly allows tracking)
DNT:1 (do not track)
DNT:2 (do not track but site-specific exceptions/exemptions exist for this party)
DNT:3 (web-wide exception/exemption exists for this party)

- Shane

From: David Singer [mailto:singer@apple.com]
Sent: Monday, January 30, 2012 8:29 AM
To: Nicholas Doty
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: ISSUE-43, ACTION-60: let the user know their options when arriving with Do Not Track

I think that there was a bad idea (which I shared) at one time that the DNT header sent to a first party had two functions:
* like any party, tell the first party how it was supposed to behave;
* warn the first party that the user is DNT-aware and may be using DNT with its third parties.

I think it best if these two are separated as much as possible.  Ideally, the second question is answered through javascript, but it seems rather complex.  We could require that some kind of DNT header must be sent to the first party, if a DNT header is sent to any party; but then we're overloading, and we'd (logically) need to be able to say "some third parties are getting DNT, but you may behave as if I had sent you no DNT header", which is a mess.

So, summary: I have an open puzzle over how the 1st party should be made aware of whether DNT is in use at all.


On Jan 30, 2012, at 15:15 , Nicholas Doty wrote:


In Brussels there was some doubt about what ISSUE-43 ("Sites should be able to let the user know their options when they arrive with Do Not Track") meant and whether it was a duplicate or otherwise already resolved. Here are my interpretations and my suggested resolution.

Per ISSUE-50, which was closed way back on September 22nd, we agree that a Do Not Track header should be sent to the first party so that the publisher is aware of the user's preference and can provide options in case the publisher needs the tracking for monetization of content, for example. We also need to send the DNT header to the first party since there will be some minimal restriction even on first parties (of the form, "don't share this data with arbitrary third parties to effectively work around my DNT preference"). I elaborate on reasons we should still send DNT:1 on the first request here: http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0242.html

In addition, the JavaScript API (either the DOM property mirroring the header or the siteSpecificTrackingExceptions described in the Site-Specific Exceptions chapter) will give further visibility to the first party. And ISSUE-111 tracks the question of whether the first party should receive a different DNT value if it's in the situation of having some associated site-specific exceptions.

I suggest we keep ISSUE-43 closed. We could re-open if someone believes publishers will somehow not have enough visibility into this status or if changes to the spec would affect whether DNT:1 is sent to the first party or its JavaScript visibility.

David Singer
Multimedia and Software Standards, Apple Inc.