5.5.2 Request-specific Tracking Status
If an origin server has multiple, request-specific tracking
policies, such that the tracking status might differ depending on
some aspect of the request (e.g., method, target URI, header
fields, data, etc.), the origin server MAY provide an additional
subtree of well-known resources corresponding to each of those
distinct tracking statuses. The Tk response header field
(section 5.4 Tk Header Field for HTTP Responses) can
include a status-id to indicate which specific tracking
status resource applies to the current request.
The tracking status resource space is defined by the
following URI Template [URI-TEMPLATE]:
/.well-known/dnt{/status-id}
where the value of status-id is a string of URI-safe
characters provided by a Tk field-value in response to a
prior request. For example, a prior response containing
refers to the specific tracking status resource
/.well-known/dnt/ahoy
Resources within the request-specific tracking status resource
space are represented using the same format as a site-wide
tracking status resource.
5.5.3 Representation
The representation of a tracking status resource shall be provided
in the "application/json" format [RFC4627] and MUST conform to
the ABNF for status-object (except that the members within
each member-list MAY be provided in any order).
The following example tracking status representation
illustrates all of the fields defined by this specification,
most of which are optional.
Example 7
{
"tracking": "1",
"same-party": [
"example.com",
"example_vids.net",
"example_stats.com"
],
"third-party": [
"api.example.net"
],
"audit": [
"http://auditor.example.org/727073"
],
"policy": "/tracking.html",
"control": "http://example.com/your/data"
}
A tracking status representation consists of a single
status-object containing members that describe the
tracking status applicable to the designated resource.
status-object = begin-object member-list end-object
member-list = tracking ns tracking-v [tracking-q]
[ vs same-party ns same-party-v ]
[ vs third-party ns third-party-v ]
[ vs audit ns audit-v ]
[ vs policy ns policy-v ]
[ vs control ns control-v ]
*( vs extension )
A status-object MUST have a member named
tracking that contains a single character
tracking status value
(section 5.2 Tracking Status Value),
optionally followed by one or more tracking qualifiers
(section 5.3 Tracking Status Qualifier Values) .
tracking = %x22 "tracking" %x22
For example, the following demonstrates a minimal tracking status
representation that is applicable to any resource that does not
perform tracking.
Example 8
{"tracking": "N"}
An OPTIONAL member named same-party MAY be
provided with an array value containing a list of domain names
that the origin server claims are the same party, to the extent
they are referenced by the designated resource, since all data
collected via those references share the same data controller.
same-party = %x22 "same-party" %x22
same-party-v = array-of-strings
An OPTIONAL member named third-party MAY be
provided with an array value containing a list of domain names
for third-party services that might be invoked while using the
designated resource but do not share the same data controller as
the designated resource.
third-party = %x22 "third-party" %x22
third-party-v = array-of-strings
An OPTIONAL member named audit MAY be
provided with an array value containing a list of URI references
to external audits of the designated resource's tracking policy
and tracking behavior in compliance with this protocol.
Preferably, the audit references are to resources that describe
the auditor and the results of that audit; however, if such a
resource is not available, a reference to the auditor is
sufficient.
audit = %x22 "audit" %x22
audit-v = array-of-strings
An OPTIONAL member named policy MAY be
provided with a string value containing a URI-reference to a
human-readable document that describes the tracking policy for
the designated resource.
The content of such a policy document is beyond the
scope of this protocol and only supplemental to what is described
by this machine-readable tracking status representation.
policy = %x22 "policy" %x22
policy-v = string ; URI-reference
If the tracking status value is 1 and the designated
resource is being operated by an outsourced service provider on
behalf of a first party, the origin server MUST identify the
responsible first party via the domain of the policy URI, if
present, or by the domain owner of the origin server.
If no policy URI is provided and the origin server domain is
owned by the service provider, then the service provider is the
first party.
An OPTIONAL member named control MAY be
provided with a string value containing a URI-reference to a
resource for giving the user control over personal data collected
by the designated resource (and possibly other resources);
a control member SHOULD be provided if the
tracking status value indicates prior consent
(C).
Such a control resource might include the ability to review
past data collected, delete some or all of the data, provide
additional data (if desired), or opt-in
, opt-out
,
or otherwise modify an out-of-band consent status regarding
data collection. The design of such a resource,
the extent to which it can provide access to that data, and
how one might implement an out-of-band consent mechanism is
beyond the scope of this protocol.
control = %x22 "control" %x22
control-v = string ; URI-reference
Additional extension members MAY be provided
in the status-object to support future enhancements to
this protocol. A user agent SHOULD ignore extension members
that it does not recognize.
extension = object
array-of-strings = begin-array
[ string *( vs string ) ]
end-array
ns = <name-separator (:), as defined in [[!RFC4627]]>
vs = <value-separator (,), as defined in [[!RFC4627]]>
begin-array = <begin-array ([), as defined in [[!RFC4627]]>
end-array = <end-array (]), as defined in [[!RFC4627]]>
begin-object = <begin-object ({), as defined in [[!RFC4627]]>
end-object = <end-object (}), as defined in [[!RFC4627]]>
object = <object, as defined in [[!RFC4627]]>
string = <string, as defined in [[!RFC4627]]>
true = <true, as defined in [[!RFC4627]]>
false = <false, as defined in [[!RFC4627]]>
null = <null, as defined in [[!RFC4627]]>
Note that the tracking status resource space applies equally to
both first-party and third-party services. An example of a
third-party tracking status is
Example 9
{
"tracking": "3",
"policy": "/privacy.html",
"control": "/your/data",
}5.5.4 Status Checks are Not Tracked
When sending a request for the tracking status, a user agent
SHOULD include any cookie data [COOKIES] (set prior to the
request) that would be sent in a normal request to that origin
server, since that data might be needed by the server to determine
the current tracking status. For example, the cookie data might
indicate a prior out-of-band decision by the user to opt-out or
consent to tracking by that origin server.
All requests on the tracking status resource space, including
the site-wide tracking status resource, MUST NOT be tracked,
irrespective of the presence, value, or absence of a DNT header
field, cookies, or any other information in the request.
In addition, all responses to those requests, including the
responses to redirected tracking status requests, MUST NOT
have Set-Cookie or Set-Cookie2 header fields and
MUST NOT have content that initiates tracking beyond what was
already present in the request.
A user agent SHOULD ignore, or treat as an error, any Set-Cookie
or Set-Cookie2 header field received in such a response.
5.5.5 Caching
If the tracking status is applicable to all users, regardless of
the received DNT-field-value or other data received via the
request, then the response SHOULD be marked as cacheable and
assigned a time-to-live (expiration or max-use) that is sufficient
to enable shared caching but not greater than the earliest point
at which the service's tracking behavior might increase. For
example, if the tracking status response is set to expire in seven
days, then the earliest point in time that the service's tracking
behavior can be increased is seven days after the policy has been
updated to reflect the new behavior, since old copies might
persist in caches until the expiration is triggered. A service's
tracking behavior can be reduced at any time, with or without a
corresponding change to the tracking status resource.
If the tracking status is only applicable to all users that have
the same DNT-field-value
, then the response MUST either be
marked with a Vary header field that includes "DNT" in its
field-value or marked as not reusable by a shared cache without
revalidation with a Cache-Control header field containing one of
the following directives: "private", "no-cache", "no-store", or
"max-age=0".
If the tracking status is only applicable to the specific user
that requested it, then the response MUST include a Cache-Control
header field containing one of the following directives:
"private", "no-cache", or "no-store".
Regardless of the cache-control settings, it is expected that
user agents will check the tracking status of a service only once
per session (at most). A public Internet site that intends to
change its tracking status to increase tracking behavior MUST
update the tracking status resource in accordance with that
planned behavior at least twenty-four hours prior to activating
that new behavior on the service.
A user agent that adjusts behavior based on active verification
of tracking status, relying on cached tracking status responses
to do so, SHOULD check responses to its state-changing requests
(e.g., POST, PUT, DELETE, etc.) for a Tk header field
with the U tracking status value, as described in
section 5.4.3 Indicating an Interactive Status Change.