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

On Thursday 01 November 2012 15:32:31 Roy T. Fielding wrote:
> Please understand that it is necessary, for the survival of the
> Web, that a server have the ability to disregard protocol
> elements that do not adhere to their assigned semantics.  

And this principle is not limited to DNT and the dispute over 
defaults. This principle is generic as far as I understand you. 

> It is
> one of the very few aspects of the Web that allow it to survive
> the tragedy of the commons. I cannot emphasize enough that this
> principle is far more important than anything the W3C has worked
> on, including DNT.

I always wondered how you could do otherwise. But maybe people can 
explain how they want to handle this issue if they want to always 
react, even on invalid protocol steps. 
> 
> If automated transparency is desired, then the solution is to
> provide a means for the server to say that it won't comply with
> an invalid signal. In order for that to be required, it must be a
> mechanism usable by servers that have no direct access to the
> GUI, including redirect handlers and beacons, which means it must
> be in the tracking status value.

This is my preferred solution
> 
> If no protocol mechanism is provided, then it is likely that users
> will be notified via the privacy policy, assuming that the server
> adheres to any DNT signals.

See, I have trouble with this generic privacy policy notification 
where it says in 35 pages that "we may ignore your DNT-signal if we 
believe it was wrong". Unfortunately, the user agent cannot detect 
when this is the case. The end of the story is that a user can't 
know whether his DNT signal is honored or not. This is as bad as 
having no DNT at all. 

If the service sends status back and the browser doesn't show, the 
lacking transparency is the browsers fault. So IMHO, a service must 
have the ability to say no, but also MUST indicate that. We do not 
contradict the "must understand" of web services in general service 
conditions either. We need a status IMHO.. As you do this on a per-
request basis (you can't know whether the next request comes from a 
bogus DNT implementation), you can only do so economically by 
returning a header IMHO, but I won't teach http to Roy...

Rigo

Received on Thursday, 1 November 2012 23:28:45 UTC