- From: David Wainberg <david@networkadvertising.org>
- Date: Mon, 20 Aug 2012 18:34:27 -0400
- To: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <5032BB73.5050608@networkadvertising.org>
Hello all, Since we seem to be getting close on the TPE, I just took a thorough read through the whole doc and I've spotted a few things I want to raise. Apologies if I'm rehashing stuff that was covered some time ago, when I was not a participant. * 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. * If DNT is to single out 3rd parties, it should be made clear earlier in the doc. The introduction makes it sound like DNT is widely applicable to any party on the net. 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 at that point, and more explanation up top would be helpful so that readers, especially casual readers, do not misconstrue the nature of the spec. * 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. * 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. * 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. * 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? * 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 look forward to your input on these. Thanks to Roy and David for putting so much work into this draft! Cheers, David
Received on Monday, 20 August 2012 22:34:56 UTC