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

I agree.  No matter what you do, be clear and communicate what you are doing.

Another important principle is that each end behaves 'better' than the other.  If you truly believe that the other end is non-compliant, or has made a mistake, then the correct response is to notify them, so that the responsibility both for advising the rest of the system or the user (or the tool author) of the error now lies clearly at that end -- both the error (if it is one) and the notification now belong clearly at the UA end.

We agreed in principle to have a tracking value "other reason for being tracked" which would require a URL to explain the reason (at least, I don't recall any push-back).  (It's theoretically possible, for example, that the server is under a court order to keep detailed records, and must 'track' according to our definitions.)

Whether the response is, itself, compliant, would have to be indeterminate (it depends on how good your reason is, whether it conflicts with the spec., how well explained, and so on).

Should we take an action to add to the response values "tracking for other reason explained at <this url>"?


On Nov 2, 2012, at 4:45 , Craig Spiezle <craigs@otalliance.org> wrote:

> This is very balanced and reasonable.  I would like to see that develop, where a user could then make a value judgment on continuing to use the site or service. 
>  
> From: Justin Brookman [mailto:jbrookman@cdt.org] 
> Sent: Thursday, November 01, 2012 7:19 PM
> To: public-tracking@w3.org
> Subject: Re: ACTION-212: Draft text on how user agents must obtain consent to turn on a DNT signal
>  
> What constitutes non-compliance with this part of the spec is going to be a subjective determination.  A user agent might believe in good faith that it is compliant with the spec while a third party ad network might legitimately disagree.  If we are going to grant to third parties the authority to individually judge and dismiss the legitimacy of users' DNT intention (setting aside for the moment the question of whether that standard results in a meaningful, universal DNT standard in the minds of regulators and users), then there needs to be some sort of machine-readable and -detectable messaging back to the browser that the signal is being rejected.  Manually searching through third party privacy policies isn't scalable for users, but user agents can be configured to process and respond to standardized signals.  The key is meaningful transparency.
> From: Vinay Goel [mailto:vigoel@adobe.com]
> To: Rigo Wenning [mailto:rigo@w3.org], public-tracking@w3.org [mailto:public-tracking@w3.org]
> Cc: Roy T. Fielding [mailto:fielding@gbiv.com], John Simpson [mailto:john@consumerwatchdog.org]
> Sent: Thu, 01 Nov 2012 19:47:59 -0500
> 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
> >
> >
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.