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

On 10/31/12 4:11 PM, Shane Wiley wrote:

> If Servers feel the UA did not meet this bar, they should feel free to
> ignore the signal from that UA.  Similarly, if a Server claims user

I feel that the time spent on the perceived risk of misconstrued
non-consent of users may not be the best way to get a working standard
going.

A UA that sets a DNT:1 by default is a UA chosen by the user. One can
debate endlessly that the user may or may not know the implications of
its choice for that particular UA. Given the lack of information
available to the users for (implicitly) consenting to be tracked by not
using the DNT signal at all or DNT:unset or DNT:0 I would consider those
signals to be way less likely an expression of informed consent than the
opposite. In light of that Microsoft's initial decision to put DNT:1 on
by default should be applauded instead of vilified.

I am fine with a standard that says that DNT should be unset by the UA
by default and that the UA should force an explicit choice by the user
for setting it.

I am very much _not_ ok with a standard that says that if there is a
chance that DNT:1 does not reflect the users preference because not all
users of a particular UA have been forced to make such an explicit
choice that it can ignore DNT:1 at will.

To give a very real-life example: regardless of the default settings of
the UAs shipped by Mozilla, Microsoft, Apple etc, it is to be expected
that DNT:1 will be set per corporate policy in quite a few large
organisations on this side of the Atlantic prior to their deployment to
users' desktops. Because browsing habits in itself can divulge
information that corporations consider confidential. Moreover, employers
do have an obligation to protect the privacy of their employees.

Would you argue that any DNT:1 signal received from IP-ranges of such
organisations can be ignored at will?

As it stands now, the standard allows for a much greater risk of users
not wanting to be tracked to be tracked nonetheless already, let's not
amplify this risk any further.

Regards,

 Walter

Received on Wednesday, 31 October 2012 19:31:53 UTC