- From: David Singer <singer@apple.com>
- Date: Thu, 27 Oct 2011 17:05:58 -0700
- To: "Aleecia M. McDonald" <aleecia@aleecia.com>
- Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
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)? ") 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')." 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. On Oct 26, 2011, at 11:44 , Aleecia M. McDonald wrote: > > Based on what we discussed in Boston, plus the conference call today, here is where I think we are for Issue-4: > > It is out of scope for the TPWG to decide to make DNT opt-in or opt-out. That is a purely political question that may be country-by-country. However, as Roy notes, we need a technical specification that is clear to implement. > > What we are trying to support is the idea that DNT decisions may be implicit. For example, installing a proxy or a specialized privacy-protective browser is, itself, a user decision for privacy even in the absence of explicitly understanding that DNT happens to be one of the mechanisms used. What we are trying to avoid is a case where an ISP tells advertisers "I'm turning on DNT for all of my users, regardless of their actual privacy preferences, unless you give me a cut of advertising revenue." The basic concept here is that DNT is the user's voice, and must be the user's preference. > > Proposed text to react to: > > A compliant user agent must offer users a minimum of two choices: on, and off. When DNT is on, the user agent sends an HTTP header of “DNT: 1”. When DNT is off, the user agent sends an HTTP header of “DNT: 0”. If the user has not expressed a privacy preference, neither the user agent nor any service may send a DNT header on the user’s behalf. For example, neither a browser nor an ISP may inject “DNT: 1” on behalf of all of their users who have not selected a choice corresponding to “DNT: 0”. However, a user may make a choice for privacy that then implicitly includes a DNT setting. For example, a user choosing something like “Privacy settings: high” in a user agent might include a bundle of responses, including turning on DNT. That is acceptable. Similarly, users installing a browser plugin that advertises itself as protecting privacy could also have DNT turned on. Users need not understand the technical mechanisms for DNT and we do not address user interface presentation. The basic principle here is that DNT reliably expresses users’ choices. > > DNT should only and exactly send a signal of a user's preference. In the absence of user choice, there must be no DNT signal sent. In some cases users will not have DNT preferences, including while using older user agents that do not support DNT. Consequently, services (websites and others) would be wise to assume some users will not send a DNT expression. 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. > > Aleecia David Singer Multimedia and Software Standards, Apple Inc.
Received on Friday, 28 October 2011 00:06:24 UTC