- From: Rigo Wenning <rigo@w3.org>
- Date: Thu, 07 Jun 2012 21:23:39 +0200
- To: David Singer <singer@apple.com>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
On Thursday 07 June 2012 09:30:51 David Singer wrote: > > If the TPE allows you to send an NACK ("No, I won't" full > > stop), then it is compliant to say No. It may not be privacy > > enhancing, but it is compliant. If the TPE contains no way to > > (explicitly or implicitly) say "No, I won't" then we go into > > very troubled water, socially and legally! > > I think you need to explain this. Ok, long response. If you're in a hurry just read the first para after quote. Ian Fette said in http://lists.w3.org/Archives/Public/public- tracking/2012Jun/0119.html <quote> There's other people in the working group, myself included, who feel that since you are under no obligation to honor DNT in the first place (it is voluntary and nothing is binding until you tell the user "Yes, I am honoring your DNT request") that you already have an option to reject a DNT:1 request (for instance, by sending no DNT response headers). </quote> Count me into that class with the exception that I want a defined failure mode: A server response in that protocol saying, "not this request" and a definition what that means (NACK-header). This implements the protocol (thus compliant) but is not privacy enhancing for the request where DNT;1 was refused. As we do not send headers anymore (see how dangerous your WKL can get?) Ian's scenario doesn't work anymore. Johnny Service can't opt out, thanks to Roy having thrown out the headers. We don't know how to refuse a single DNT;1 request because there is no context. Not sending a header is not an option anymore, as there are no headers. The WKL doesn't allow you to do that kind of distinction. I exaggerate a bit to make it clear. If we re-introduce context by re- establishing headers, we basically have a choice of not sending a header and telling the UA that we do not understand DNT (which is wrong and a semantic hack) Or we positively tell the other side that we know DNT, but do not honor DNT for "this" request (NACK). Ian says don't send a header and I say send NACK (in whatever code we may decide). > > It's a choice to implement DNT (on either end), but once you do, > your obligations -- what you signed up for -- should be clear > (for both ends). "Yes, we implement DNT and comply with the W3C > specifications" should mean that both ends should know what to > expect of the other. Like Ian, you say, I stop here and quit the protocol. But the protocol currently doesn't define failure. By failing we push people into the undefined space. This way, the user agent doesn't know (WKL aside) that the site was capable but refused. And there is a message to this. Because it is stating a preference from the Service (and not only from the user). Not being able to selectively say no also forces sites into all-or-nothing paradigms. (see below) > > Defining that "I'll stop tracking unless I don't feel like it" as > *compliant* makes it basically unpredictable what will happen. This would be only true in a context-less interaction. I have to declare NOW that I will honor all DNT:1 requests for the future. But in this case, tell me how you would NOT implement DNT for single resources or in specific situations so that you don't have to honor DNT:1? Your WKL always tells "I'm compliant" and thus forces you to honor the DNT:1 request, whether it fits or not, is default or not. The granularity of the all-site options do not stand the reality check IMHO. And because you and Ian say nobody can be forced to honor DNT, it is basically unpredictable anyway what will happen unless you received an ACK from the Service. WKL is uncontrolled bulk ACK. Without ACK, sending DNT doesn't mean anything. Sending DNT to the CIA isn't forcing them to not track you anymore. Unless they promise to. > > It means that the user can force the > > preference on the server. > > Nobody is forcing anyone to implement DNT, but once they do, it > should be clear what is expected of them: and that needs to be > more than "exercise their own judgment over what to do and what > not to do". Saying: "if you implement DNT, you have to honor whatever comes down the pipe" allows users to force a state. If "compliance" can only mean "I honor DNT:1" than our protocol would be way too complicated. In this case, we could forget the header and just have DNT:1 in the WKL for those sites that do not track. And the reduction to a per-site granularity doesn't scale. I may have log-in states and other things on my server that are not compatible with "Not tracking". I receive a DNT;1, I tell NACK or trigger an exception request to receive DNT;0 for that part. What is that other than sending NACK in the first place? So in theory, I can send NACK and be compliant with the Specification. I'm not privacy enhancing though. -> branding prob. > > The only option is then that the server > > can silently give up compliance which could be seen as > > misleading. If I would be a server in this situation, I would > > give up compliance immediately for all DNT because this is > > legally untenable. > These are strong words, which I don't see supported. > > Imagine a function > > "Y = SQRT(X) In legal terms having no NACK and no granular "I don't support the protocol for this request" is rather a function that looks like "Y = SQRT (X/0)" So please divide X by 0 before doing your function. Silence as agreement is in the legal world approximately the same thing than dividing by 0 is in the mathematical world. By making compliant only those who honor DNT:1 upon request without an option to refuse, you force the services into a fictional silence that counts as an agreement. You divide by 0. Saying "non-compliant" mainly consists of letting the failure of the protocol to achieve agreement undefined and hope that the successes can be labeled "do not track". It is a branding issue. Trouble is that one can't handle exceptions (like DNT;1 defaults) with this undefined failure mechanism. Because in this case one doesn't have defined failure states that are communicated back like the response header would do. The user has no prob. He doesn't suffer from sending DNT;1 by default. The Service has the problem. And the Service is the right party to react. Just saying "non-compliant" doesn't allow the Service to react with something else than completely opting out of the technology. (Or trying to get a proscribed behavior of a user agent defined in the Specification that can never turn bad, good luck) Realistically (and overcoming WKL limitations) the divide we are having is between "is compliant but invasive (NACK header is compliant)" vs "do not send header back: undefined failure mode makes failure to agree non-compliant" I still fail to see how you would communicate your non-compliance as a service other than completely refusing any DNT messaging, including removing your WKL. In case of defined failure, we need to come up with a branding messaging for the success (sent DNT;1 and got accepted, service behaves accordingly) In case of failure to agree, a NACK could overwrite the WKL. > > This returns the square root of X, unless the system has reason to > believe that the caller didn't need a square root at this time, > whereupon it returns something else." > > Seriously, this is a useful definition? > > > Shane argued many times in other areas that if we fail to > > honor, we can do so, but have to alert the UA. > > *That* I agree with. At the moment, it's even hard to detect > whether the server claims one or more permissions, or believes it > has an exception grant from the user. See, it burns down to the DNT as a marketing term. We have to get intelligently out of that by defining the terms accordingly. Nobody prohibits us from saying in the spec that the "do not track"-status is only the status where DNT:1 requests are honored. The other status would be e.g. "confirmed tracking" or "normal web logs" or "only aggregated analytics" and if we go too far, we end again in P3P. > > > Overall, the way to get good behavior in any protocol is to strive > to be *more compliant* than the other end. At the moment, people > are arguing that they should be allowed, encouraged even, to be > *less compliant* (because you would ignore a DNT signal from > users who did, in fact, mean it). This is a race to the bottom, > and a recipe for something worthless. And I want to give them a means in the Spec to compliantly say "no", because it is mainly a fundamental right to say "no" (for users and services alike BTW) Rigo
Received on Thursday, 7 June 2012 19:24:08 UTC