Re: Today's call: summary on user agent compliance

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