- From: Ed Felten <ed@felten.com>
- Date: Tue, 11 Sep 2012 19:08:52 -0400
- To: David Wainberg <david@networkadvertising.org>
- Cc: "<public-tracking@w3.org>" <public-tracking@w3.org>
- Message-ID: <CANZBoGiuqC2bqQFM0RMNrJpg2UBrUp7pqOyM4hW_2t8=vE3qjQ@mail.gmail.com>
Hi, David. Thanks for taking the time to explain your proposal in detail. I'm still a bit unclear on your proposed meaning for DNT:0. In particular, I don't quite understand how DNT:0 would be different from leaving DNT unset. You say this: "*Although in most cases, [DNT:0] is functionally the same as DNT unset, it indicates an affirmative exception granted to the recipient, rather than, for example a UA that does not implement DNT, or a user that does not use DNT:1 at all." *What I don't understand is what the server is allowed/expected to infer from the fact that the UA does or doesn't implement DNT, or that the user sends DNT:1 to other sites but not this one. To put it another way, the text I quoted above talks about *why* a user might end up sending DNT:0 instead of unset, but it doesn't quite say what the presence of DNT:0 is supposed to communicate to the server. If I'm understanding you correctly, you don't want DNT:0 to be interpreted as granting the user's consent to track. (If DNT:0 was an explicit grant of consent, that would make it different from DNT unset.) What could the server do or not do on receiving DNT:0, that would be different from if it received DNT unset? * * On Tue, Sep 11, 2012 at 6:16 PM, David Wainberg < david@networkadvertising.org> wrote: > Hi All, > > I am combining these issues because the problems with both are similar. I > am proposing a) that we drop altogether the idea to have an "absolutely not > tracking" response, and b) that the meaning of DNT:0 should be limited to > "not DNT:1." > > Both ideas, because they create distinct, parallel, and barely defined, > policies within a policy, create ambiguity and confusion. The result will > be reluctance to adopt the standard because of the ambiguous legal risk it > creates. They are also both designed to accomplish aims that are beyond the > DNT mechanism we are working to define. > > First, we should avoid including these policies in the standard just as a > matter of good drafting. When the point of the standard, and almost all of > the content in it, pertains to one thing -- the meaning of a user's > preference not to be tracked (DNT:1) -- tacking on a new definition > pertaining to something else -- a user's affirmative consent for something > that may or may not be tracking -- just can't be good. Same goes for > creating a new state of "not tracking" or "anonymous" that has a meaning > apart from the meaning of DNT. > > On last week's call we already agreed that defining "not tracking" without > defining "tracking" would be a problem. (It also would be a problem if we > defined both but with some delta between them; that would be exceedingly > confusing to implementers and users.) > > We would also create confusion by defining DNT:0 as something more than > not DNT:1, because it creates a mismatch between what is regulated under > DNT:1 policy and what is then allowed under DNT:0 policy. This is going to > cause serious heartburn. > > One solution that has been proposed for the status flag is that we go with > a term that does not include "tracking," such as "anonymous." But this > raises similar issues. The standard addresses tracking. Under the standard, > users express a preference not to be tracked, and servers honor that > preference per the standard. There are two states: tracking and not > tracking. There's no other state required, and to create a third state will > degrade the clarity of the policy, and will create confusion for > implementers and users. > > Moreover, how are we going to define "anonymous" or "pseudonymous" or > "foo"? Given that this is an unnecessary appendage anyway, and that we > can't even define "tracking" in a "do not track" standard, why do we want > to create the problem of now having to define some other state. To include > it without a definition would be unacceptable. > > Aside from the problems of ambiguity and confusion, both proposals go > beyond what the TPWG was chartered to accomplish. The not tracking signal > would create a mechanism to aid a small number of sites who, as part of > their marketing efforts, are making assertions with regard to their privacy > practices. Although it may be laudable that they are doing this, it's not > for this standard to get involved in promoting such efforts; they can do so > in their marketing materials and in their privacy policies. > > Similarly, the DNT:0 definition that has been proposed goes too far. It > creates a wholly new policy, beyond DNT:1, and purports to grant consent > for practices (e.g. personalization of content) that aren't expressly > addressed under the DNT:1 policy. Does this imply that those practices > actually are or should be addressed in the standard? Why aren't they called > out explicitly? > > The TPWG is developing a mechanism for users to express a preference, not > a general purpose tool for communicating privacy practices, and not a tool > for promoting certain practices over others. The DNT header simply > communicates a user's preference not to be tracked. Although we are going > slightly beyond that in providing for some indications of whether or how > the recipient is honoring the DNT signal, those indications are directly > tied to specific aspects of compliance with the DNT:1 signal. These > proposals go beyond that. > > So, for that reason, and because of the ambiguity and confusion I've > explained, we should drop the "absolutely-not-doing-foo" proposal, and we > should use the following as a definition for DNT:0. > * > **"DNT:0 means not DNT:1, an express choice that DNT:1 should not apply > to the recipient server. Although in most cases, this is functionally the > same as DNT unset, it indicates an affirmative exception granted to the > recipient, rather than, for example a UA that does not implement DNT, or a > user that does not use DNT:1 at all."* > > If you've gotten this far, thanks for taking the time to plow through my > long-winded post. I'm sure everyone will let me know if they have questions. > > -David > >
Received on Tuesday, 11 September 2012 23:09:36 UTC