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 Thursday, 1 November 2012 23:48:31 UTC