Re: tracking-ISSUE-150: DNT conflicts from multiple user agents [Tracking Definitions and Compliance]

As I understand protocols they can be either ACK based or NAK based (if
there's a problem).

So in your example below the server is compliant (implemented all the MUSTs
and SHOULDs) if they EITHER do not respond or respond with a NAK.

So the client sends a DNT:1 - the server is compliant, but detects a problem
(not sure what the problem could be) but anyway decides NOT to respond or it
sends a NAK.

Lets take the first case:
* Does NOT respond ­ so what exactly is the server doing at this stage?
> * My guess is that it's tracking you
* Does respond with a NAK
> * Exactly where does this NAK go to?
>> * My guess is back to the browser ­ what happens then I have no idea
>> * And if in the case of a NAK what exactly is the server doing?
>>> * My guess is tracking you
So unless I'm completely misunderstanding this, the browser can send a valid
DNT:1 header, the server can be 100% compliant (def above) and it can choose
to ignore the DNT header (but then it wouldn't be compliant ­ I get it). If
that's the case then how does the user verify that a DNT signal has actually
been received and acknowledged as valid.

The server has rejected the header ­ doesn't the customer have a right to
know that it's been rejected?

And a follow up question. If the NAK acknowledgement is "outside" the scope
of this protocol and to be left to the 3rd parties to implement how do we
intercept a NAK? Which of course also begs the question if the server just
decides not to honor anything and not send a NAK how do we verify that with
3rd party tools?




Peter
___________________________________
Peter J. Cranstone
720.663.1752







-----Original Message-----
From: Rigo Wenning <rigo@w3.org>
Organization: W3C
Date: Friday, June 22, 2012 8:18 AM
To: Tamir Israel <tisrael@cippic.ca>
Cc: David Singer <singer@apple.com>, W3 Tracking <public-tracking@w3.org>,
Matthias Schunter <mts-std@schunter.org>, Justin Brookman <justin@cdt.org>
Subject: Re: tracking-ISSUE-150: DNT conflicts from multiple user agents
[Tracking Definitions and Compliance]
Resent-From: W3 Tracking <public-tracking@w3.org>
Resent-Date: Fri, 22 Jun 2012 18:50:00 +0000

> Tamir, 
> 
> On Thursday 21 June 2012 20:34:25 Tamir Israel wrote:
>>  My concern is that in this 'exchange' users will inevitably lose
>>  out  since servers will have the more or less final say in all
>>  instances. Taking a pure contractual analysis stance for a
>>  moment, under what terms could you enforce /any /DNT-1 against a
>>  server that has decided to ignore it (and has told you so)?
> 
> This is my central argument in this debate since weeks. Ian Fette
> seems to be on the same page. It seems that some techies still have
> trouble understanding that. The question remains how this is wrapped
> into messages and into DNT marketing and politics.
> 
> For the moment, "honoring the DNT-Header preference" is called "DNT-
> compliant" in the market place. Those market semantics are at odds
> with typical specification and standardization semantics. There,
> "DNT-compliant" means: "Has implemented all the MUSTs and SHOULDs".
> 
> A site that does not respond or responds with NACK has "implemented
> all the MUSTs and SHOULDs", but does NOT "honor the DNT-Header
> preference". Such a site is "compliant" according to the classic
> semantics and "non-compliant" according to the market semantics.
> 
> A way out is to define those two things in a conformance section.
> And to rename them. An addition to the TPE Specification would read:
> 
> Conformance section
> 
> 1. An implementation of this Specification that implements all the
> MUSTs and SHOULDs relevant for it is called "Specification
> complete". 
> 
> 2/ An implementation that confirms to follow users' Tracking-
> Preferences as defined by section 4 and 5 of this Specification  is
> called "DNT-compliant".
> 
> This way, the semantic odds are cleared. And it is clear that while
> a site has a perfect right to reject the header, it can't call that
> behavior "DNT-compliant".
> 
> Best, 
> 
> Rigo
> 
> 
> 

Received on Friday, 22 June 2012 19:08:05 UTC