Re: ACTION-212: Draft text on how user agents must obtain consent to turn on a DNT signal


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. 


Received on Monday, 19 November 2012 09:37:39 UTC