Re: Issue-4

On Oct 27, 2011, at 5:05 PM, David Singer wrote:

> I think you are maybe answering a different, and harder, question than I see Issue-4 raising.
> ("ISSUE-4: What is the default for DNT in client configuration (opt-in or opt-out)? ")

I think we came to a general group understanding that the best answer here is actually "neither opt-in nor opt-out" at the user agent level. So it is a response to the issue in a "the question is phrased wrong" sort of way.

> The protocol proper is between the user-agent and the server.  There is a user 'behind' the user-agent, and a service behind the server, for sure.  But they are 'beyond' the protocol.
> 
> In any protocol with an optional 'statement', one has to state what the other end understands from when the statement is not made.  Generally, the assumed (default) value is also a valid one to state explicitly, as well.  e.g.: "(The 'prato' value may take a value between 0 and 123 inclusive; if the 'prato' field is not supplied, servers must assume a value of 0 for 'prato')."

And I did try to address this as:
	In the absence of regulatory, legal, or other requirements, services are free to interpret lack of DNT header as they find most appropriate for their users, particularly in light of users’ privacy expectations and cultural circumstances.

So, if you want to run a website that interprets the absence of DNT to mean proceed with personalized behavior, that's fine. And if you want to interpret the absence of DNT to mean protect privacy, that's fine too. My guess is the text I wrote does not convey that crisply enough. Care to revise?

> The answer to the question stated in the issue is that we do not have a DNT signal value that says "the user's DNT preference is not expressed in this transaction", but THAT is the 'default' that the other end MUST assume.  Not that they gave DNT 0, or DNT 1 (rejection or permission), but that they said nothing.  Perhaps we need a value to say that explicitly.


Correct, my understanding in Boston was that we were not contemplating sending a specific signal of: users have not made a DNT choice. Instead, the idea was that the absence of a DNT signal conveys no user choice. So long as we are all clear that no DNT signal means no user choice, I think we do not need to send the extra bits. Does anyone have a use case that illustrates the need for a different approach?

	Aleecia

[…snip…]

Received on Tuesday, 8 November 2011 08:00:08 UTC