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

On Tue, Jun 5, 2012 at 12:11 PM, David Singer <> wrote:

> On Jun 5, 2012, at 9:47 , Tamir Israel wrote:
> > Thanks for this.
> >
> > I think I may still be confused here, and I apologize if I am rehashing
> things that have already been addressed.
> >
> > My confusion stems from two elements of the spec: how are non-compliant
> signals dealt with, and is there a difference betwen 'non-complaint' and
> 'altogether outside the scope of the spec'.
> Well, I think we're discussing something that is a little fuzzy to start
> with.  Let me see if I can explain something about conformance.
> The spec talks about a DNT signal that is formatted as "DNT" followed by a
> colon and either 0 or 1.  If a user-agent were to send "DNT;5", the server
> would see this as a non-compliant signal, and if it liked it could guess
> what was wanted, but we're clearly in the realm of someone not following
> the protocol.
> But here we have a case where the actual header sent is compliant, but
> there is some doubt over whether it truly "expresses the user's intent"
> (something that is not machine-determinable).  I'm trying but failing to
> think of protocols which allow you to do something else if you think the
> other end didn't actually mean what they said.
We do this all the time. Most browsers do sniffing of content types, for
instance, to see "You the server told me this was image/jpeg. I'm going to
look and see if it has the correct magic bytes at the beginning. Oh wait,
it looks like you're actually sending me a PNG. Hmm..."

> For example, in HTTP caching, a server can indicate on a supplied file
> "you can cache this until next monday, noon UTC", with the implication that
> it won't change before that time. Now, a cache could periodically check
> back with the origin server and notice that it did, in fact, change, before
> that time, and conclude that cache headers from this server can't be
> believed, and not cache anything - despite the fact that the cache header
> itself is well-formed.  I think that a complaint against the cache that
> it's not behaving to protocol would be justified; it has no way of knowing,
> for example, whether it's important that the revised version of the file
> get out there before next monday.
> > Specifically: What is the process for scenarios where a server deems a
> DNT-1 signal to be non-compliant with the spec where it is deemed to be
> injected by an intermediary?
> How does it 'know' it was injected by an intermediary?  Even if it knew,
> how does it know that the user didn't intentionally sit behind that
> intermediary?
> > Does this apply equally to DNT-1 signals deemed outside the scope of the
> spec (since they are sent by UA default)? Is there a mechanism for UAs and
> servers to discuss the legitimacy of a DNT-1 signal?
> As I say, I am not trying to defend a DNT-on-by-default, but I think this
> sort of second-guessing is quite dangerous; I still have no idea how you
> sift out users who chose the product because it had DNT on, and users who
> were unaware of the feature, for example.
> If a policeman is directing traffic at a junction, and he indicates you
> should turn right, and you are pretty sure he meant left, I'd still suggest
> you turn right on his direction and complain later...
> > Is there a UA obligation to notify the user that
> (…your sentence breaks off here…)
> David Singer
> Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 6 June 2012 06:05:22 UTC