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

Vinay,

I agree a non-compliant UA is most likely not going to go out of its way to tell its users that a Server feels its non-compliant.  I believe this is more associated with Issue-143 whereby 3rd parties that are overriding the UA DNT signal would represent who they are to the Server.  In this case, the Server could respond to the UA that a 3rd party tool that is sending the DNT signal is non-compliant ("invalid").  The same argument could be made that 3rd party tools that are willfully non-compliant would hide who they are from the UA, but we've generally agreed we're building this standard for good actors, not bad actors.  Are willfully non-compliant UAs/3rd Parties/Servers good actors?  That's a different discussion...

- Shane

-----Original Message-----
From: Vinay Goel [mailto:vigoel@adobe.com] 
Sent: Thursday, November 01, 2012 4:48 PM
To: Rigo Wenning; public-tracking@w3.org
Cc: Roy T. Fielding; John Simpson
Subject: Re: ACTION-212: Draft text on how user agents must obtain consent to turn on a DNT signal

I must be missing something, but I don't understand how most users would benefit from a return header stating that the server is ignoring DNT signals from non-compliant UAs.  If the UA is non-compliant, they've already taken active steps to not implementing its UA per the spec.

Do we expect a non-compliant UA to build in a functionality that tells its users that this UA is non-compliant?  If we don't, then would the typical consumer really benefit from having servers respond with  a specific value in a return header?  While not ideal, I would expect a server to tell its visitors its DNT compliance policy within its Privacy Policy.  While many consumers don't read Privacy Policies, more consumers would likely read a privacy policy than scour through http headers to see the return header.

-Vinay



On 11/1/12 7:28 PM, "Rigo Wenning" <rigo@w3.org> wrote:

>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 Friday, 2 November 2012 00:12:35 UTC