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

Ok, except (see inline):

On 6/21/2012 1:12 PM, David Singer wrote:
> Guys
>
> I proposed a way to deal with this already, and no-one objected; Shane had a suggestion which I incorporated into this tex:
>
> * * * *
>
> In particular:
>
> A] We seem to agree that it should not be compliant for a server to respond to a compliant DNT:1 request by continuing track you for some reason of its own devising.
>
> B] We also seem to agree that the user-agent/user needs to know the answer to the simple question "is this site possibly tracking me, or not?".
>
> C] I would also guess that we all think we have our hands full answering the question of what constitutes compliant interaction. Adding to our workload specifying how the two ends may deal with non-compliant behavior, and expecting to maintain schedule, is probably optimistic.
>
>
>
> I therefore suggest:
>
> * We add to both documents that they specify how compliant end-points react and behave with other compliant end-points, and the handling of non-compliant behavior is currently, for the most part, unspecified.
>
> * We re-examine the response header and well-known resource.  At the moment it's easier to determine "is this a first or third party?" than the more important "am I being tracked?".  I would suggest that the signal be clearer:
> - I am not tracking (though I may be engaging in Permitted Uses);
> - I am or may be tracking you, and then optionally add:
>   - because I didn't see any DNT header from you at all (it's also acceptable not to respond at all in this case)
>   - because I am a first party
>   - because I think I received inline exception from you (DNT:0)
>   - because I think I have an out-of-band exception from you
>   - for some other reason that is explained in more detail at the following URL
>    [so, for Ian and Rigo, it would then be technically possible to respond "I am or may be tracking you" with one of these 'becauses']
>
>   We add a note saying "this recommendation does not state whether the last response (some other reason) is compliant, or the circumstances in which it may be used"
>
> * that we require what you say you are doing and what you do must match under all circumstances (even when faced with a non-compliant end-point, so this is one of the few places we'll talk about how to respond to non-compliant behavior).

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)?

> * and we then say that it is not compliant for a third party to respond to a compliant DNT:1 signal by tracking, unless they have an exception
>
>
>
>
> On Jun 21, 2012, at 8:14 , Tamir Israel wrote:
>
>> Rigo -- designing the spec in a manner that lets servers expressly invalidate a DNT-1 within the context of the spec seems a bad idea. I'd actually prefer to leave it as is (not necessarily in a fog, but leave it to the server's discretion whether they think they can ignore a valid-seeming signal or not instead of giving them the right to capacity to invalidate a signal).
>>
>> Unless you want to take the further (and highly complicated) step of providing a mechanism for UAs to confirm 'non-compliant' DNT signals with the user and respond with a re-affirmation....
>>
>> Best,
>> Tamir
>>
>> On 6/21/2012 10:55 AM, Rigo Wenning wrote:
>>> Tamir,
>>>
>>> DNT is a communication channel, not a privacy law. If a country
>>> wants to prohibit services from refusing a DNT:1 header, they have
>>> to create the appropriate rule that coerces the service into a
>>> certain behavior. W3C does not have the status to create such
>>> coercive rules.
>>>
>>> Ian Fette already said: Do you want to know whether they ignore you
>>> or be left in the fog?
>>>
>>> There are multiple ways to react on a refusal to service DNT:1. One
>>> being to fake the UA string. My browser has even a per-site
>>> configuration to circumvent site designs that are doing stupid
>>> browser sniffing things.
>>>
>>> The rest is wording and making of compliance classes in the TPE
>>> Specification. Our problem is the use of "DNT compliant" as a
>>> marketing term for better privacy. A conformance section could say
>>> e.g. that servers responding with NACK can claim to be "DNT Protocol
>>> compliant" but not "DNT compliant".
>>>
>>> Rigo
>>>
>>> On Wednesday 20 June 2012 23:34:28 Tamir Israel wrote:
>>>> I'm not quite sure that allowing servers to reject DNT-1s
>>>> unilaterally  deemed non-compliant will enhance trust in the
>>>> standard. Users may well be quite frustrated to find that some
>>>> servers (but not others) simply do not respect their signals.
>>>> Also, many had mentioned a desire to avoid reinstating the pop-up
>>>> mania of earlier days. I think this would further that mania.
> David Singer
> Multimedia and Software Standards, Apple Inc.
>