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 <singer@apple.com> 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.
>
>
>