- From: Rigo Wenning <rigo@w3.org>
- Date: Mon, 19 Nov 2012 10:37:13 +0100
- To: public-tracking@w3.org, rob@blaeu.com
Rob, On Sunday 18 November 2012 20:12:09 Rob van Eijk wrote: > I am also still at the position that there is no consensus on > server side rejection of DNT signals coming from e.g. IE10. The principle Roy is invoking goes far beyond the IE 10 bickering. (and whether a shown pre-ticked field is still a default and what a default is anyway and how many millions it will cost). It is the mere question on whether a server can signal his unwillingness or inability to honor a DNT:1 signal. => What if failure? We have three ways to react here: 1/ send no status back (if you have a well known location, you're mainly screwed, I remain a fan of headers) 2/ send a signal back indicating that the DNT signal is not honored and indicate why (at least Shane and me favor this) 3/ Write some legalese somewhere and claim it overwrites all of DNT (I had my fingers crossed behind my back) and hope that some judge will buy into it. (I'm sure there is one, but there are also others who will consider it as "venire contra factum proprium). > A > rejection on the server seriously breaks the (semi-automatic) > granular dialog between the user and a site. It doesn't as the reject is a part of that dialog. > It also endangers > interoperability. In addition to this, it also carves out > credibility, because the server can still claim to be DNT > compliant and shift the burden of proof to the user. This is a serious concern IMHO as one could abuse the marketing message. IMHO this is the elephant in the room. Some believe that IE is overselling the "privacy solution" and others believe that claiming DNT compliance means "privacy". But if Shane suggests to send a URI with explanations with the reject header, this allows people to find out. If people don't care, the preference set in the first place wasn't one initially. It doesn't solve the IE issue immediately, but it creates a conduit to let the market/authorities decide (transparency). > If a server > is rejecting a DNT signal, than that organization IMHO has to > make clear and specific representations to the user. If it would > be up to me: in real time with a clear banner or window shade. The clear indication could be provided via the URI that Shane suggested in the response header. Your suggestions are browser UI requirements, and we know that those don't work. The fact that you raise it shows that we are on the right track with the response signal. A browser can then react in many ways, including starting the tor-bundle. (If you don't play well, I will neither..) This makes crystal clear why DNT failing leads to severe damages for the Web and what the arms race is, we are fearing. But concluding that a service can't reject a signal (that may even contradict another user action) goes beyond what I still would consider good technical design. I agree with Roy here and hope for the comprehension of others to distinguish between the marketing problem and the technical problem. Rigo
Received on Monday, 19 November 2012 09:37:39 UTC