ACTION-114: Send revised header proposal

Relevant:
ISSUE-47
ISSUE-48
ISSUE-51
ISSUE-76
ISSUE-90
ISSUE-106
ISSUE-107
Resolved:
ISSUE-45

Tracking Response Header
========================

Header Specification
--------------------

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] [ opt-in-flag ] [CFWS] [ reason-code ]
DNT-Status = no-dnt / not-tracking / first-party / service-provider
no-dnt = 0
not-tracking = 1
first-party = f
service-provider = s
opt-in-flag = 1
reason-code: ALPHA
~~~

`no-dnt` indicates that this party does not comply with [Tracking Definitions and Compliance]().

`not-tracking` indicates that:
- this party complies with [Tracking Definitions and Compliance][], and
- this party will process this request according to the specification for 3rd parties in [Tracking Definitions and Compliance][].

`first-party` indicates that:
- this party complies with [Tracking Definitions and Compliance][],
- that this resource is intended to be served as a first party, and
- this party will process this request according to the specifications for 1st parties in [Tracking Definitions and Compliance][].

`service-provider` indicates that:
- this party complies with [Tracking Definitions and Compliance][],
- this resource is intended to be used in a service provider context, and
- this party will process this request according to the specifications for service providers in [Tracking Definitions and Compliance][],


### Opt-in Flag ###

If the opt-in-flag is included, the server believes that the user has affirmatively consented to allow this party additional permission to track them. Unless the opt-in-flag is included, the server asserts that will act in responding to this request as if the user has not affirmatively consented to allow this party additional permission to track them. If the opt-in flag is included, the the user SHOULD be able to understand and manage their opt-in by visiting the well-known URI indicated below.

### Well-knownm URI ###

- Information about the request SHOULD exist at `/.well-known/dnt?status=[DNT-status]&opt-in=[opt-in-flag]&r=[reason-code]`.
- If a [reason code] is specified in the response, a corresponding URI MUST exist.
- This URI MAY provide additional information about this party's privacy practices and practices surrounding Do Not Track.


Discussion
----------

### Features ###

- User-agents can confirm that the server with which they are communicating has received their DNT request.
- User-agents can determine which class of practices the server intends to follow when processing this particular request.
- User-agents can determine if a server believes that the user has out-of-band consented to let them do additional tracking, and may be able to review or modify that consent.
- Servers make a clear promise about how they will process data gathered from this particular request.
- Servers have a well-known place to point to more information about their tracking/privacy practice.
- Servers can provide customized information to clients if desired.

### Pending ###

At this time, the working group has not provided any suggestions as to the format, contents, or structure of the resource at the well-known URI. We anticipate that certain machine-readable or semantically-marked-up components may be valuable. For instance, it may be valuable for this page to semantically tag a link to a locations where a user can control or modify their consent and opt-in/out preferences.

### Implementation Notes ###

Implementers should use caution when allowing caching of resources on which a opt-in flag is included. If caching is not carefully managed, there is a risk of sending a response intended for opted-in users to users who haven't opted in.

Implementers should carefully choose the cache properties of the items at the well-known URI. The content at these locations must be correct for the entire cache duration, otherwise users who load stale cached copies of these resources may be unfairly mislead.

Any party can use the `not tracking` response: this response just indicates a behavior. If a first party complies with the third-party definition, they are free to send this response. However, the `first-party` and `service provider` responses indicate both a behavior and an intention about that party's status. It would be deceptive to send the `first-party` header on a resource which is only ever embedded as a third party.

The `no-dnt` response should not be used on requests which are processed in accordance with [Tracking Definitions and Compliance][]. An entity which implements DNT should not use this response.

When embedding content from other sites, consider how that site expects their content to be used. If you embed/hotlink to an object on another site, it's possible that the resource will send a `first-party` response even though it is now in a third party context because the designer of that site never intended that object to be embedded. If a resource always sends a `third-party` response, there is no risk of this inconsistent response. Only the first-party out-sourcer of `service-provider` objects should ever embed them.



[Tracking Definitions and Compliance]: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
[1]: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#TypesofTrackingOutsourcing