RE: ACTION-212: Draft text on how user agents must obtain consent to turn on a DNT signal

I probably misunderstand DNT, but have a concern that the UA is not
able to control being tracked, even if it expresses DNT:1 when sending
a request to a server that follows the DNT protocol.   For example:

1. UA sends a request and expresses the preference: DNT:1

2. Server receives the request, and conforms to the DNT protocol, but
decides (for any reason) that it will not respect the DNT:1 request, and
'tracks' the user, and returns a Tk:1 response to the UA.

3. UA receives Tk:1, blocks the loading of the resource, but the user has
been tracked.  UA adds server to a blacklist.

I recognize that a server that does not implement the DNT protocol
would continue to silently track the user, and such resources would
need to continue to be managed by an access list. But after all the
work on DNT has nothing improved?

Consider another example with 'active' tracking:

1. UA sends a request and expresses DNT:1

2. Server receives the request and implements the DNT protocol and
respects the preference, responding with TK:3, but sends monitoring
codes that are designed to probe UA state and send it back to the server
(not technically tracking yet).

3. UA receives the resource, notes the Tk:3 response, and loads the resource,
and executes the monitor codes which probes the user and generates a new
XHR request that is sent to the server.  The UA adds a DNT:1 header to the
new request.

4. Server receives the request with 'active' tracking information probed by
the monitoring code, notes the DNT:1 header but this time decides it will
not respect it, tracks the user, storing the probed state, and responds
with Tk:1.

5. UA receives the Tk:1 response, and blocks the response, but the
monitoring code continues to run (its not technically tracking), and the
user continues to be probed and tracked!  The UA appears to need to
add the server to a blacklist to block continued tracking.


cheers
Fred

> From: rigo@w3.org
> To: public-tracking@w3.org
> CC: fielding@gbiv.com; john@consumerwatchdog.org
> Date: Fri, 2 Nov 2012 00:28:05 +0100
> Subject: Re: ACTION-212: Draft text on how user agents must obtain consent    to  turn on a DNT signal
> 
> On Thursday 01 November 2012 15:32:31 Roy T. Fielding wrote:
> > Please understand that it is necessary, for the survival of the
> > Web, that a server have the ability to disregard protocol
> > elements that do not adhere to their assigned semantics.  
> 
> And this principle is not limited to DNT and the dispute over 
> defaults. This principle is generic as far as I understand you. 
> 
> > It is
> > one of the very few aspects of the Web that allow it to survive
> > the tragedy of the commons. I cannot emphasize enough that this
> > principle is far more important than anything the W3C has worked
> > on, including DNT.
> 
> I always wondered how you could do otherwise. But maybe people can 
> explain how they want to handle this issue if they want to always 
> react, even on invalid protocol steps. 
> > 
> > If automated transparency is desired, then the solution is to
> > provide a means for the server to say that it won't comply with
> > an invalid signal. In order for that to be required, it must be a
> > mechanism usable by servers that have no direct access to the
> > GUI, including redirect handlers and beacons, which means it must
> > be in the tracking status value.
> 
> This is my preferred solution
> > 
> > If no protocol mechanism is provided, then it is likely that users
> > will be notified via the privacy policy, assuming that the server
> > adheres to any DNT signals.
> 
> See, I have trouble with this generic privacy policy notification 
> where it says in 35 pages that "we may ignore your DNT-signal if we 
> believe it was wrong". Unfortunately, the user agent cannot detect 
> when this is the case. The end of the story is that a user can't 
> know whether his DNT signal is honored or not. This is as bad as 
> having no DNT at all. 
> 
> If the service sends status back and the browser doesn't show, the 
> lacking transparency is the browsers fault. So IMHO, a service must 
> have the ability to say no, but also MUST indicate that. We do not 
> contradict the "must understand" of web services in general service 
> conditions either. We need a status IMHO.. As you do this on a per-
> request basis (you can't know whether the next request comes from a 
> bogus DNT implementation), you can only do so economically by 
> returning a header IMHO, but I won't teach http to Roy...
> 
> Rigo
> 
>