Re: ACTION-258: Propose 'should' for same-party and why

Roy, 

thanks for trying a dozen times. I appreciate you taking the time. It is 
understood that a simple TSR can be loaded once, cached, not put into 
the user's face. That a simple TSR may have better performance values 
than a header response. This is not my point. My point is that the 
browsers will kill the protocol if they ignore the answer to the DNT:1 
question sent by the UA to the service. See below.

On Thursday 21 March 2013 10:27:07 Roy T. Fielding wrote:
> Rigo, I have already explained this a dozen times.  No response is
> ever necessary in order for this protocol to work its entire
> benefit for privacy.  Either the server conforms to the user's
> preference or it does not -- neither option has anything to do
> with the response.  If you can't trust the server to comply, you
> can't trust a response from the server either.

If this would be true, we would not need any TSR, but just a one byte 
response in a header for all headers: Either you do DNT or you don't. 
Why then is the TSR much more complex? Are we all so misguided that we 
have created much ado about nothing?

IMHO, from the above I could draw the conclusion that Adrian and You 
have not fully factored in the legal dimension of the protocol. Let me 
give you one example: 

Shane wants to be able not to honor certain requests under DNT:1 . There 
is agreement that this must be transparent and that the service has to 
send back "D" in this case. This was on the call yesterday. You're 
telling me that we don't need all that as either the thing can do DNT or 
not. Are you winding me up? Or is Shane's usecase: I will ignore all of 
user-agent xyz, which isn't expressed by one "D" in the static resource.
> 
> The only thing a response does is make it easier to see deployment
> than reading a privacy policy or making one additional request to
> the server, and that task (seeing deployment) is not and
> has never been in the critical path.

In your mind model that might be true, see above, it breaks things 
seriously and does not correspond to the fact that I may honor your 
DNT:1 request or not. As a user of a browser, a browser that ignores the 
feedback from the server is like driving with a black opaque windshield 
and without seat belts. "I told you I ignore your DNT:1". "Oh right, but 
my damn browser did ignore your message". 

If this is about control and communication, it needs some user side 
implementation. Or we can all go home and prepare for the arms race by 
cookie blocking, DNT-store blocking extensions, TOR or crowd-sourced 
blocking lists. A few clicks and the ad-model was yesterday. I think we 
are here to avoid that. 

> It is only of interest to the
> privacy advocates and regulators in the WG, a total of maybe 200-300
> people in the entire world, and does not justify adding even a
> single byte to the many trillion responses per day that occur
> over HTTP.

If DNT is only interesting for privacy advocates and regulators, we 
would not need a technical steam factory that does nothing. We could 
just write down a policy and the regulator would audit your service from 
time to time. This is what the Europeans tried for so long. Has it 
worked? No. Unfortunately, Privacy is more complex than that and 
interests more people like just 3 or ten paranoid privacy nerds and some 
regulators. DNT is of interest for many people. And transparency is a 
very very big part of the cake. Browsers ignored that in 2002. If they 
ignore it again, we can also blame them for the next round of privacy 
disturbance in the market. The cost will be much higher than 
implementing transparency into a browser. A "verifying" browser is just 
an overstatement to justify ignoring the feedback loop. In fact, the 
browser doesn't verify anything. 
> 
> In contrast, the advantage of a well-known resource
> is that it can be INDEPENDENTLY verified and monitored to whatever
> extent advocates and regulators might want, without interfering
> with the implementation of any existing resources or the
> performance of any given user's request, and a browser that is
> truly interested in verification can retrieve the TSR before
> making any real request of the server that might contain their
> individual tracking information.

There is no "true verification" and I'm not attacking the TSR model. 
Adrian tells you that it doesn't work because only getting feedback is 
more of a performance hog that he could accept. The problem is that your 
assumption of a uniform reaction on all requests is only true if you 
believe the internet is static. The use case "D" above shows you that it 
isn't static. It may be that your intended implementation of DNT is 
static per site. But there are other very important use cases. 

The feedback mechanism is a cornerstone in the entire legal construct. 
If the protocol is not capable of generating transparency on whether for 
a certain request DNT:1 was honored, it is not fit for purpose and does 
not reflect the use case where I want to reject a single DNT:1 request. 
I think your protocol is able to do it. But Adrian says, it is not fit 
for purpose and that's why he is not implementing it. 

> 
> It is, in all respects, a far superior solution than header fields
> alone.  More importantly, it won't break the Web in the way that a
> dynamically produced, user-specific header field on every response
> would break the Web's caching properties.

Maybe the TSR is superior, but looks like Adrian thinks otherwise. He 
thinks it is just a waste of time. So if it is so superior, why is it so 
unimportant? Perhaps the policy people have lost the technical people 
over the discussion? Maybe. I just find it very very sad, if a browser 
can not give me very important information that is out there, namely 
whether is site is tracking me or not. Without the TSR, a browser is not 
better than any of the DNT:1 -header spawning DSL-routers. This is like 
a phone with a microphone but without a speaker. 

 --Rigo

Received on Thursday, 21 March 2013 18:36:50 UTC