Re: issues and questions in the latest TPE draft

Hi David

many, many thanks for the careful read.  Here are some comments:

> Singling out 3rd parties. If DNT is to single out 3rd parties, it should be made clear earlier in the doc. The first indication that the spec applies specially to third parties is in the definition of "user-granted exception." To me, that seems to come out of the blue a bit, and more explanation up top would be helpful.

This one looks like we might address it editorially; I agree, general concepts (party, 1st, 3rd, permission, exception, and so on) should be introduced early. The group decided, long ago, by the way, that there were fewer restrictions on sites the user visits and interacts with.

> In Section 4.1 there is a table that shows DNT value and associated "meaning." It is for the compliance document to define the meaning of a DNT signal. Shouldn't these definitions should be removed from the TPE, and instead reference the other doc?
This one, and others like it, is waiting for a harmonization with a more stable compliance spec.:

> In 6.4.1, under the description of the "granted" parameter, do we intend to use "indicated targets" vs "specific targets" for values of 0 or 1, respectively? 
On 6.4.1, I tried to write it that 0 means "whatever you asked for, you got the answer 'no' (it might have been site-wide, it might have been a specific list)", that 1 means "you asked for, and got, a grant for a specific list of targets (not site-wide)" and 2 means "you got a site-wide grant, either because you asked for one, or because you asked for a specific list but the UA upgraded you to site-wide".  Perhaps clearer wording is needed?

> Finally, section 6.7 includes non-normative language that states that UA's may implement exception management as they see fit, and gives an example of a UA prompt to allow a requested exception. Although this is non-normative, I have concerns about the impact. In my view, the requesting party (i.e. the publisher) should control the messaging of the request, and the UA should provide only a simple yes/no confirmation. The example given will create a terrible user experience, as the user will be presented with multiple and possible conflicting explanations of the request. Let's not encourage this. Canit we please remove it?
> 

I agree with you on the model of the exceptions -- that the site's pages should explain what's going on, and that the API call and resulting UI should be a confirmation.  I wonder if, if that is the case, we need all the explanatory parameters to the API, and I agree that re-writing 6.7 in the light of that model would be good.

> The introduction to the TPE is too editorial, especially the 4th paragraph, and especially the last sentence of the 4th paragraph. I wonder if we need this at all in the TPE. It is at least better suited for the TCS doc, but even in that doc, I'd raise the same concerns. 
I think the current introduction was the result of a consensus process, and yes, it'll need editing to be in line with the compliance document in future, but I think we're hesitant to touch it now.
> 

> Similarly, the introductory language to Section 3 states, "The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server." It is not each server, but rather third party servers. If first parties have little to no responsibilities under DNT, that should be made clear. Alternatively, we might make the TPE more neutral, using language like "covered party" or some such term, to avoid this problem.
> 

There are rules for first parties under DNT:1 -- looser than the 3rd party rules, but they do exist.  So the preference is expressed to each server.

> I know this has been discussed a lot, but I just don't get how it is going to work. I worry about the language regarding implicit decisions to set DNT: "A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent." Who will judge this and how? I know there will be clear cut cases, but there will also be many, many gray areas.
> 

My personal read is that people will evaluate and complain about UAs that they feel don't meet this.  The initial court will be public opinion.

> 5.2 tracking status value "N": I raised this on the call last week. I can't find where or how this was closed. I believe it is, and should be, still an open issue.
> 

If there is a missing link to an issue (and maybe a missing issue) we are happy to insert it.

> Again, forgive me if I'm missing background on this, but Section 6.8 states that "User agents may instantiate NavigatorDoNotTrack.requestSiteSpecificTrackingException even when navigator.doNotTrack is null." Shouldn't this be a MUST? Sites will rely on this being present. What's the rationale for making it optional?
> 

Current matter of debate.  I see little difference, as said in another email, between (a) no API (b) an API that always says no and (c) a user that always says no.  I am hesitant to design products, rather than protocols, here.  If people stop using a browser because they can't visit sites, because those sites require an exception and can't get one with their current browser, that's a product issue.


David Singer
Multimedia and Software Standards, Apple Inc.