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

What I'm trying to get at is what statement the user is thought to be
making by sending DNT:0 rather than sending nothing.   Maybe the difference
is that DNT:0 and unset say the same thing about the user's (non-)request
to the current server, but DNT:0 implies that the user might treat *other*
servers differently.  But I'm not sure what the rationale is for having
users tell one server in a non-specific way what their general policy is
toward other servers.

To put it another way: If I am a User Agent, why would I bother to
implement DNT:0 if it is so close in meaning to unset?   Why wouldn't I
just use a two-state approach with DNT:1 and unset?

On Wed, Sep 12, 2012 at 9:35 AM, David Wainberg <
david@networkadvertising.org> wrote:

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