Re: Revised Response Header

When a site complies with DNT, there are a set of restrictions on their
data practices, like "Third parties must not collect or retain data
about users except for data collected for <certain particular
purposes>.", and so on. As Shane said yesterday, the "exceptions" are
part of this set of rules, not separate things.

Opt-in is fundamentally different. When a user has engaged in an
out-of-band opt-in, the user has said "Even though I'm sending you a
DNT:1 signal, I permit you to do <these things> which are otherwise
prohibited by my DNT:1 signal.". This is a "dangerous" state, because it
means that the site is *not* following the rules of DNT, but instead
following some different set of rules which has been agreed between the
site and the user. Unless the user can tell that a site is following an
alternate ruleset agreed between them, it would look like the site says
that it is complying with DNT but is in fact not following the DNT
rules. Only and individualized "I see that you have sent me a DNT:1
signal, but I know that you want me to do some things which are
prohibited by that signal." message allows users to distinguish those
two states.

   ---

Could you let me know which states you think are redundant duplicates of
each other? I think that these states are all distinct, and I suspect
that knowing which things you think are the same would help us to
identify and resolve our mis-communication.

First parties are not exempt from DNT. First parties and third parties
have different obligations under DNT. First parties are not permitted to
share any information gathered from a user sending DNT:1 (except...). A
first party would return `c` when they follow DNT, but the user has
specifically requested that they generally share information about the
user's visits with someone outside that party. However, when I am
browsing Twitter, I would not expect to see `c` because I do not
generally wish for my actions to be shared with anyone other than
Twitter. For actions like sending a tweet which are self-evidently
communicative, no `c` response is needed.

If a first party intends to directly share information with a third
party, then *both* of those parties need permission to break their DNT
obligations. The first party needs permission to share the information
(a prohibited practice), and the third party needs permission to collect
the information (a prohibited practice). However, if a third party
simply wishes to collect information directly from the user then only
the third party needs permission.

   ---

As for "xxx most of the time, but yyy only some of the time", I think
that most logical servers that don't run widgets or have out-of-band
opt-in will only be in one state, pretty much all of the time. There's
no need to use any server-side logic to work out which response header
to send to a particular request, you just hard-code the -- for instance
-- service-provider response, and everyone who hits that server gets
that signal.

There are some servers which need to use more than one header. Widgets
like +1, Like, Tweet This, &c would need to send third-party on general
resource loads, but switch to first-party when they respond to user
interaction. Servers that allow users to engage in an out-of-band opt-in
would likewise need to return the non-opted-in header unless a user has
opted in.


On 01/25/2012 10:47 PM, Kevin Smith wrote:
> Tom,
> 
> Can you repeat why you wanted (or it sounded like it was a requirement for your initial proposal) the opt-in exception to be called out differently than other exceptions?  You said something about xxx most of the time, but yyy only some of the time, but I did not quite grasp it.  This still has the redundancy issue I brought up earlier.  I may try to take a pass at it to see if the redundancy can be removed and still maintain your current functionality, but I want to make sure I understand the reasoning first.
> 
> Also, what is an example of when a server would return a "c" (first-party-opt in).  Since the first party has a default exception, what does an opt-in even mean.  Opt-ins are for 3rd parties in correlation to a 1st party, but I do not think you would say that the 1st party has an opt-in.  That would seem to imply that the 1st party is going to share your data with a 3rd party not on the request, otherwise the opt-in should come from the 3rd party - is that the purpose?  Or perhaps it might make sense with a sitewide opt-in, basically saying all 3rd parties on my site share this opt-in.
> 
> -----Original Message-----
> From: Tom Lowenthal [mailto:tom@mozilla.com] 
> Sent: Wednesday, January 25, 2012 5:12 PM
> To: public-tracking@w3.org
> Subject: Revised Response Header
> 
> ACTION-90 ACTION-87
> ISSUE-48 ISSUE-76 ISSUE-90 ISSUE-105 ISSUE-106 ISSUE-107
> 
> Behold, the bikeshed has been re-painted.
> 
>    ---
> 
> Non-normative Discussion
> ------------------------
> 
> This response header has the following features:
> 
> - Servers state whether they think that they are a first or third party.
> - Servers may state that they think that a user has explicitly opted back in to data collection by that site (not catchable).
> - There is a response for catchable, static, or otherwise not-relevant-to-tracking objects.
> 
> Everything fits within two characters: one for status and one for explanations. With the exception of "you have opted in" almost any logical server should only ever exist in one of these states, so dynamic generation is not needed. The user also has a way to query a server to discover that server's tracking policies, without that request causing tracking.
> 
> 
> Normative Text
> --------------
> 
> If a server receives a request with a DNT header, the response to that request MUST include a DNT-response header. If a server receives a request without a DNT header, the response to that request MAY include a DNT-response header. If sent, a DNT-response header MUST be accurate.
> The DNT-response header is as follows:
> 
>> DNT-Response = "Tk:" [CFWS] DNT-Status [CFWS] [ reason-code ] 
>> DNT-Status = no-dnt / full-dnt-1 / full-dnt-3 / except-dnt-1 /
> except-dnt-3 / opt-dnt-1 / opt-dnt-3 / dnt-cached
>> no-dnt = 0
>> not-tracking = 1
>> static-untracked = u
>> first-party = f
>> third-party = 3
>> service-provider = s
>> first-party-opt = c
>> third-part-opt = p
>> reason-code: 1*alphanum
>> alphanum = ALPHA / DIGIT
> 
> If a reason code is specified, an *explanation* MUST exist at /.well-known/dnt?r=reason-code . Whether or not a reason code is specified, a *general policy* regarding Do Not Track SHOULD exist at /.well-known/dnt . The structure and requirements for *explanations* and
> *general-policies* is described in section $FIXME of this document.
> 
> *no-dnt* indicates that this party does not comply with [Tracking Definitions and Compliance](). Servers MUST NOT use this response.
> 
> *not-tracking* indicates that:
> - this party complies with [Tracking Definitions and Compliance](),
> - does not engage in tracking, and
> - that any information gathered by the party as a result of this request will be treated as if this party is a third party.
> 
> *static-untracked* indicates that:
> - this a resource -- such as a cached resource -- on which tracking does not occur, and
> - that any information gathered by the party through requests to this resource will be treated as if the server is a third party.
> 
> *first-party* indicates that:
> - this party complies with [Tracking Definitions and Compliance]() and
> - believes it is acting as a first party in responding to this request.
> 
> *third-party* indicates that:
> - this party complies with [Tracking Definitions and Compliance]() and
> - believes it is acting as a third party in responding to this request.
> 
> *service-provider* indicates that:
> - this party complies with [Tracking Definitions and Compliance]() and
> - believes it is acting as an outsourced third party service provider under section [3.6.1.2]() of [Tracking Definitions and Compliance]().
> 
> *first-party-opt* indicates that:
> - this party complies with [Tracking Definitions and Compliance](),
> - believes it is acting as a first party in responding to this request,
> - believes that the user has affirmatively consented to allow this site additional permission to track them, and
> - the appropriate *explanation* describes these additional permissions and allows the user to revoke or modify them.
> All responses with this state must be marked as uncacheable.
> 
> *third-part-opt* indicates that:
> - this party complies with [Tracking Definitions and Compliance](),
> - believes it is acting as a first party in responding to this request,
> - believes that the user has affirmatively consented to allow this site additional permission to track them, and
> - the appropriate *explanation* describes these additional permissions and allows the user to revoke or modify them.
> All responses with this state must be marked as uncacheable.
>