- From: Rigo Wenning <rigo@w3.org>
- Date: Thu, 21 Mar 2013 19:36:23 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Adrian Bateman <adrianba@microsoft.com>, "public-tracking@w3.org Working Group" <public-tracking@w3.org>
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