- From: Rigo Wenning <rigo@w3.org>
- Date: Thu, 21 Jun 2012 19:36:59 +0200
- To: David Singer <singer@apple.com>
- Cc: Tamir Israel <tisrael@cippic.ca>, public-tracking@w3.org, Matthias Schunter <mts-std@schunter.org>, Justin Brookman <justin@cdt.org>
+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