RE: Revised Response Header

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.

Received on Wednesday, 25 January 2012 21:48:25 UTC