- 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