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

+1

Rigo

On Thursday 21 June 2012 10:12:51 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).
> 
> * 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.

Received on Thursday, 21 June 2012 17:37:29 UTC