- From: Rigo Wenning <rigo@w3.org>
- Date: Fri, 02 Nov 2012 11:52:56 +0100
- To: Shane Wiley <wileys@yahoo-inc.com>
- Cc: Vinay Goel <vigoel@adobe.com>, "public-tracking@w3.org" <public-tracking@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>, John Simpson <john@consumerwatchdog.org>
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