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

Shane, Vinay, John, 

out of the trenches I strongly believe that live is complex and that 
we can't predict all and every situation a server may face in DNT 
space. So apart from the fact that there may be politics around 
certain user agents showing the preference-selection to the user in 
a certain way, I can imagine a gazillion situation where a service 
may have all and every reason to not apply DNT limitations. I think 
it is just presumptuous to think that such a situation could never 
exist. 

There are two ways to react. Either not sending a response header at 
all. In which case the UA can not assume that DNT is followed. Or by 
sending a (small) signal back allowing the UA to understand that the 
service is DNT enabled, but doesn't like the concrete signal. Which 
one to chose is a matter of taste and discussion. I'm leaning 
towards an active signal (see my email to Roy). 

Rigo

P.S. I'm more concerned about cheap 30-line tools senselessly 
spawning DNT-headers for a short term privacy claim. Those have 
nothing to do with "self-determination" and serious privacy 
considerations but rather riding a wave. 


On Thursday 01 November 2012 17:11:41 Shane Wiley wrote:
> 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 10:53:35 UTC