- From: イアンフェッティ <ifette@google.com>
- Date: Tue, 5 Jun 2012 23:04:52 -0700
- To: David Singer <singer@apple.com>
- Cc: Tamir Israel <tisrael@cippic.ca>, "public-tracking@w3.org protection wg" <public-tracking@w3.org>
- Message-ID: <CAF4kx8ee8_=c0oQRyvjbe27OMDjg6Sw+M9uNiZgwFEsXS4D4aQ@mail.gmail.com>
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. > > >
Received on Wednesday, 6 June 2012 06:05:22 UTC