Re: ACTION-253 ISSUE: 119 and ACTION 208 ISSUE-148 Response signal for "not tracking" and definition for DNT:0

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
>
>