- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 1 Jun 2012 10:56:06 -0700
- To: Rigo Wenning <rigo@w3.org>
- Cc: public-tracking@w3.org
On Jun 1, 2012, at 9:45 AM, Rigo Wenning wrote: > Roy, > > On Tuesday 29 May 2012 18:23:19 Roy T. Fielding wrote: >>> This means you assume that a browser can send DNT;1 into the wild and >>> expect that to work. >> >> No, it doesn't. It means that the response has no impact whatsoever >> on whether DNT:1 works or not. > > In this case, the question is: Which semantics prevail, the header or the > response? What is binding the server? The status or the header sent? The header states the user's preference. If the server conforms to the DNT standard, then it behaves according to that preference and the sole purposes of the response are to enable discoverability for preflight avoidance (something only the WKL can accomplish), to measure deployment (something which is far more efficient with a required WKL), and to enable dynamic coloring (or otherwise highlighting) the elements of a page that do not express support for DNT. If the server does not conform to the standard, then it is irrelevant what the server says in response. We are writing a Recommendation, not a law. The protocol exchange is no more binding to the server than it would be for a person on the street being asked for the current time to be sure they have an accurate watch. What binds the server are other things, like the data protection laws in EU and the false/misleading statement laws in the US. Those apply regardless of whether the statement of DNT compliance is made in protocol messages, resource representations, privacy policies, or press releases. > If the status prevails, no need anymore to send a header, right? If the > response has no impact on DNT;1, why send it anyway, we could just spare > that entire section as it is meaningless according to you. Yes, that's what I said in response to the first I-D at the Prague IETF. There is no need for a response. There is, however, at least three expressed desires for a response, and the other fields in the tracking status representation provide value beyond DNT. For example, the control link is specifically to enable compliance with EU laws (and WH policy initiatives) that demand a mechanism for user control over the consent mechanism and past data collected. There is also no need for the request header unless it is known to be an accurate expression of the user's preference. If any general-purpose browser sends it by default, then this entire protocol serves no useful purpose. Sending DNT:1 does not improve privacy at all. The choice by a server to comply with DNT:1 might improve privacy, but only if there is a reasonable chance that it expresses the user's choice. If a server cannot determine that, then it will ignore DNT or require specific consent from all users, whether or not they already decided to configure that setting. If we cannot let each user make that choice on their own, then we shouldn't have the protocol at all --- we should just have data protection laws that preserve privacy by default (and are applied equally to all of industry) instead of inefficient protocol exchanges of invalid data that are only obeyed by a few good companies that adhere to Web recommendations as standards. ....Roy
Received on Friday, 1 June 2012 17:56:33 UTC