- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Thu, 1 Nov 2012 17:11:41 -0700
- To: Vinay Goel <vigoel@adobe.com>, Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, John Simpson <john@consumerwatchdog.org>
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