- From: Rigo Wenning <rigo@w3.org>
- Date: Sun, 16 Sep 2012 22:56:32 +0200
- To: public-tracking@w3.org
- Cc: "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com>, David Wainberg <david@networkadvertising.org>, Ed Felten <ed@felten.com>
Brooks, with all due respect: I only hear "get past EU consent mechanism" from non-EU folks. Looks like the US participants really like those UK cookie banners. This seems the latest design hit. I must have missed that trend. And I sometimes wonder if we all understand "consent" or whether we play "haunted house" by citing and re-citing "specific and informed consent" and "having been provided clear and comprehensive information". Nobody said that the DNT-token provides "clear and comprehensive information". I would not expect the machine readable well-known location status information to provide that either. "Specific and informed" can just mean that a user is supposed to know that she uses a certain website. So far about "specific". And if she sends DNT:unset, because she is uninformed, the server can trigger an exception and explain things. And suddenly, it rather looks like common sense and not like "haunted house". Maybe we get there. I'm inclined to try. Rigo On Wednesday 12 September 2012 15:37:10 Dobbs, Brooks wrote: > It may be helpful to finally put the "DNT:0 == specific and > informed consent * having been provided clear an comprehensive > information *" out to pasture. If this has been the goal, it is > a silly one. Having no solution to a problem does not make the > closest possible alternative a defacto solution – particularly > where the alternative demonstrably does not meet the > requirements. There are lots of uses for cookies that could not > by any stretch of the imagination be considered tracking, e.g. > favteam=Falcons, and which still need specific and informed > consent under the "cookie directive". The cookie directive is > not simply about "tracking cookies". There is no definition of > DNT: 0 which would both accommodate non-"tracking" functionality > (or even the "tracking" practices of infinite potential parties) > and still be even laughably specific. > > I think David's reasoning makes a great deal of sense. > > -Brooks > > -- > > Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of > the Wunderman Network (Tel) 678 580 2683 | (Mob) 678 492 1662 | > kbmg.com > brooks.dobbs@kbmg.com > > [cid:653D3A86-E16D-4BD6-9042-983849E839A4] > > This email – including attachments – may contain confidential > information. If you are not the intended recipient, do not copy, > distribute or act on it. Instead, notify the sender immediately > and delete the message. > > From: David Wainberg > <david@networkadvertising.org<mailto:david@networkadvertising.org > >> Date: Wednesday, September 12, 2012 9:35 AM > To: Ed Felten <ed@felten.com<mailto:ed@felten.com>> > Cc: "<public-tracking@w3.org<mailto:public-tracking@w3.org>>" > <public-tracking@w3.org<mailto:public-tracking@w3.org>> Subject: > Re: ACTION-253 ISSUE: 119 and ACTION 208 ISSUE-148 Response > signal for "not tracking" and definition for DNT:0 Resent-From: > <public-tracking@w3.org<mailto:public-tracking@w3.org>> > Resent-Date: Wednesday, September 12, 2012 9:36 AM > > Hi Ed, > > My understanding is that there was in the group a desire to > distinguish unset from an explicit exception. Others can probably > better talk to the rationale and use cases, but I can imagine > that it might be desirable for a party to know that it has > received an explicit exception from the user rather than passive > disregard -- "hey, she really likes us!" > > One other rationale may have been to address EU consent needs. I'm > a little confused on where we stand with that, but I think the > most recent statements from EU participants is that we're not > going to be able to address that with this. If we are indeed > trying to do that, if we're trying to shoehorn into the DNT > standard a broader consent beyond DNT on or off, then my points > below apply. > > -David > > On 9/11/12 7:08 PM, Ed Felten wrote: > 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<mailto: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 Sunday, 16 September 2012 20:56:57 UTC