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

Hi Rigo,

OK, this takes care of issues raised with respect to the internal 
consistency of the spec, I agree. But I think it still leaves open some 
issues regarding how this will actually play out.

I've already raised my concerns regarding how this would work in an 
opt-out consent world. There is simply no longer any basis for consent 
to track.

Even in a pure contract law context, if the user sends a DNT-1 and a 
server sends back 'we refuse to acknowledge this DNT-1', maybe this 
means that there is no 'user expression of a preference not to be 
tracked' but at the same time, I think it would fail the minimal to 
provide even the minimal 'notice' required under the notice/consent 
model, since it leaves no consensus on the tracking term of whatever 
contract you are relying on for notice. Typically (and this is most 
developed in scenarios where standard form contracts are exchanged that 
have 1-2 conflicting terms), conflicting terms cancel /each other/ out. 
This would mean there is no longer any 'notice' to the user she is being 
tracked. This makes sense to me, since it is reasonable to believe that 
any user sending a DNT-1 (whether by default or otherwise) would presume 
they are not being tracked.

At the end of the day, I still think it is sub-optimal to design a spec 
that allows people to ignore facially valid signals while claiming 
compliance. There's a number of ways you can remedy this. The obvious is 
to retain the 'MUST NOT turn DNT on by default' prescription but define 
'compliant' as respecting facially valid signals. Another is to require 
UAs to elicit a user preference with respect to DNT at the outset. Yet 
another: if there is a conflict between server/UA, a mechanism can be 
incorporated to prompt the user to verify their preference. Will try and 
think of other possibilities....

Best,
Tamir

On 6/22/2012 10:18 AM, Rigo Wenning wrote:
> 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".