- From: Vinay Goel <vigoel@adobe.com>
- Date: Thu, 1 Nov 2012 16:47:59 -0700
- To: 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>
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 Thursday, 1 November 2012 23:48:31 UTC