Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines the technical mechanisms for expressing a
tracking preference via the DNT request header field in
HTTP, via an HTML DOM property readable by embedded scripts, and via
properties accessible to various user agent plug-in or extension APIs.
It also defines mechanisms for sites to signal whether and how they
honor this preference, both in the form of a machine-readable tracking
status resource at a well-known location and via a Tk
response header field, and a mechanism for allowing the user to approve
exceptions to DNT as desired.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a snapshot of ongoing discussions within the Tracking Protection Working Group. Text present or not present in this document does not determine consensus within the Working Group; discussions and debates are ongoing. Text in option boxes (highlighted with light blue background color) present options that the group is currently considering, particularly where consensus is known to be lacking, and should be read as a set of proposals rather than as limitations on the potential outcome. Members of the Working Group wish to emphasize that this draft is a work in progress and not a decided outcome or guaranteed direction for future versions of this document.
Readers may review changes from the previous Working Draft. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document.
This document was published by the Tracking Protection Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-tracking-comments@w3.org (subscribe, archives). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The World Wide Web (WWW, or Web) consists of millions of sites interconnected through the use of hypertext. Hypertext provides a simple, page-oriented view of a wide variety of information that can be traversed by selecting links, manipulating controls, and supplying data via forms and search dialogs. A Web page is usually composed of many different information sources beyond the initial resource request, including embedded references to stylesheets, inline images, javascript, and other elements that might be automatically requested as part of the rendering or behavioral processing defined for that page.
Each of the hypertext actions and each of the embedded resource references might refer to any site on the Web, leading to a seamless interaction with the user even though the pages might be composed of information requested from many different and possibly independent Web sites. From the user's perspective, they are simply visiting and interacting with a single brand — the first-party Web property — and all of the technical details and protocol mechanisms that are used to compose a page representing that brand are hidden behind the scenes.
It has become common for Web site owners to collect data regarding the usage of their sites for a variety of purposes, including what led the user to visit their site (referrals), how effective the user experience is within the site (web analytics), and the nature of who is using their site (audience segmentation). In some cases, the data collected is used to dynamically adapt the content (personalization) or the advertising presented to the user (targeted advertising). Data collection can occur both at the first-party site and via third-party providers through the insertion of tracking elements on each page. A survey of these techniques and their privacy implications can be found in [KnowPrivacy].
People have the right to know how data about them will be collected and how it will be used. Empowered with that knowledge, individuals can decide whether to allow their online activities to be tracked and data about them to be collected. Many Internet companies use data gathered about people's online activities to personalize content and target advertising based on their perceived interests. While some people appreciate this personalization of content and ads in certain contexts, others are troubled by what they perceive as an invasion of their privacy. For them, the benefit of personalization is not worth their concerns about allowing entities with whom they have no direct relationship to amass detailed profiles about their activities.
Therefore, users need a mechanism to express their own preference regarding tracking that is both simple to configure and efficient when implemented. In turn, Web sites that are unwilling or unable to offer content without such targeted advertising or data collection need a mechanism to indicate those requirements to the user and allow them (or their user agent) to make an individual choice regarding exceptions.
This specification defines the HTTP request header field DNT for expressing a tracking preference on the Web, a well-known location (URI) for providing a machine-readable tracking status resource that describes a service's DNT compliance, the HTTP response header field Tk for resources to communicate their compliance or non-compliance with the user's expressed preference, and JavaScript APIs for determining DNT status and requesting a user-granted exception.
A companion document, [TRACKING-COMPLIANCE], more precisely defines the terminology of tracking preferences, the scope of its applicability, and the requirements on compliant first-party and third-party participants when an indication of tracking preference is received.
[OPEN] The WG has not come to consensus regarding the definition of tracking and the scope of DNT. As such, a site cannot actually say with any confidence whether or not it is tracking, let alone describe the finer details in a tracking status resource. This issue will be resolved by progress on the TCS document, though its resolution is a necessary prerequisite to understanding and correctly implementing the protocol defined by this document.
The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].
This specification uses Augmented Backus-Naur Form [ABNF] to define network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs.
This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including, but not limited to, browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].
The term permitted use is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference.
The term user-granted exception is used when the user has permitted tracking by a given third party.
A companion document, [TRACKING-COMPLIANCE], defines many of the terms used here, notably 'party', 'first party', and 'third party'.
The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.
Key to that notion of expression is that the signal sent MUST reflect the user's preference, not the choice of some vendor, institution, site, or any network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.
A user agent MUST offer users a minimum of two alternative choices
for a Do Not Track
preference: unset
or
DNT:1
.
A user agent MAY offer a third alternative choice: DNT:0
.
If the user's choice is DNT:1
or DNT:0
, the
tracking preference is enabled; otherwise, the
tracking preference is not enabled.
A user agent MUST have a default tracking preference of
unset
(not enabled) unless a specific tracking preference
is implied by the decision to use that agent. For example, use of a
general-purpose browser would not imply a tracking preference when
invoked normally as SuperFred
, but might imply a preference if
invoked as SuperDoNotTrack
or UltraPrivacyFred
.
Likewise, a user agent extension or add-on MUST NOT alter the tracking
preference unless the act of installing and enabling that extension or
add-on is an explicit choice by the user for that tracking preference.
We do not specify how tracking preference choices are offered to the
user or how the preference is enabled: each implementation is
responsible for determining the user experience by which a tracking
preference is enabled.
For example, a user might select a check-box in their user agent's
configuration, install an extension or add-on that is specifically
designed to add a tracking preference expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g., Privacy settings: high
).
The user-agent might ask the user for their preference during startup,
perhaps on first use or after an update adds the tracking protection
feature. Likewise, a user might install or configure a proxy to add
the expression to their own outgoing requests.
Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what resources can or cannot be accessed through that network. Implementations of HTTP that are not under control of the user MUST NOT generate or modify a tracking preference.
Some participants have noted that enabled/not-enabled status may depend on the Compliance document or may have varying implications in different jurisdictions.
When a user has enabled a tracking preference, that preference needs to be expressed to all mechanisms that might perform or initiate tracking by third parties, including sites that the user agent communicates with via HTTP, scripts that can extend behavior on pages, and plug-ins or extensions that might be installed and activated for various media types.
When enabled, a tracking preference is expressed as either:
DNT | meaning |
---|---|
1 | This user prefers not to be tracked on the target site. |
0 | This user prefers to allow tracking on the target site. |
A user agent MUST NOT send a tracking preference expression if a tracking preference is not enabled. This means that no expression is sent for each of the following cases:
In the absence of regulatory, legal, or other requirements, servers MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.
The DNT header field is hereby defined as the means for expressing a user's tracking preference via HTTP [HTTP11].
DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E ; excludes CTL, SP, DQUOTE, comma, backslash
A user agent MUST send the DNT header field on all HTTP requests if (and only if) a tracking preference is enabled. A user agent MUST NOT send the DNT header field if a tracking preference is not enabled.
The DNT field-value sent by a user agent MUST begin with the numeric character "1" (%x31) if a tracking preference is enabled, the preference is for no tracking, and there is not an exception for the origin server targeted by this request.
The DNT field-value sent by a user agent MUST begin with the numeric character "0" (%x30) if a tracking preference is enabled and the preference is to allow tracking in general or by specific exception for the origin server targeted by this request.
GET /something/here HTTP/1.1 Host: example.com DNT: 1
An HTTP intermediary MUST NOT add, delete, or modify the DNT header
field in requests forwarded through that intermediary unless that
intermediary has been specifically installed or configured to do so
by the user making the requests. For example, an Internet Service
Provider MUST NOT inject DNT: 1
on behalf of all of their
users who have not expressed a preference.
The remainder of the DNT field-value after the initial character is reserved for future extensions. User agents that do not implement such extensions MUST NOT send DNT-extension characters in the DNT field-value. Servers that do not implement such extensions SHOULD ignore anything beyond the first character.
DNT extensions are to be interpreted as modifiers to the
main preference expressed by the first digit, such that the main
preference will be obeyed if the recipient does not understand the
extension. Hence, a DNT-field-value of "1xyz" can be thought of
as do not track, but if you understand the
refinements defined by x, y, or z, then adjust my preferences
according to those refinements.
DNT extensions can only be transmitted when a tracking
preference is enabled.
The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (section 5.4.3 Representation). Since the DNT header field is intended to be sent on every request, when enabled, designers of future extensions ought to use as few extension characters as possible.
This document does not have any implied or specified behavior for the user-agent treatment of cookies when DNT is enabled.
The HTTP specification [HTTP11] permits multiple headers with the same field-name only under restricted circumstances which do not apply here; hence, at most one DNT header may be present in a valid HTTP request.
[OPEN]
[PENDING REVIEW]
This property enables a site executing code in its own origin to determine what DNT header would be sent to it in the current context, taking into account the user's general preference (if any) and any user-granted exceptions.
[NoInterfaceObject]
interface WindowDoNotTrack {
attribute DOMString doNotTrack;
};
doNotTrack
of type DOMString, window
, in the
context of the current top-level origin. If no DNT
header would be sent (e.g. because a tracking preference is
not enabled) the value is null
.
User agents often include user-installable component parts, commonly known as plug-ins or browser extensions, that are capable of making their own network requests. From the user's perspective, these components are considered part of the user agent and thus ought to respect the user's configuration of a tracking preference. However, plug-ins do not normally have read access to the browser configuration.
It is unclear whether we need to standardize the plug-in APIs or if we should rely on it being defined per user agent based on general advice here. No plug-in APIs have been proposed yet.
A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. The protocol expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other specifications.
When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other protocols are used. For example, redirecting to another protocol in order to avoid receipt of the header is not compliant.
The last paragraph may be more appropriate in the compliance document, as it discusses compliance.
The primary goals of this protocol—expressing the user's preference and adhering to that preference—can be accomplished without any response from the server. However, the protocol also seeks to improve the transparency of tracking behavior by providing a machine-readable means for discovering claims of compliance and determining the current tracking status.
Unfortunately, providing a dynamic indication of tracking compliance on every HTTP response is not feasible, since it would have the effect of disabling caching for the entire Web. Instead, this protocol defines a combination of response mechanisms that allow the information to be communicated without making every response dynamic.
This section explains how a user agent MAY discover an origin server's tracking status for a given resource. It defines a REQUIRED site-wide tracking status resource at a specific well-known location and an OPTIONAL space of request-specific tracking status resources for sites where the tracking status might vary based on data within the request. It also defines a Tk response header field that MAY be sent in any HTTP response, MUST be sent in responses to requests that modify the tracking status, and MAY direct the user to a request-specific tracking status resource applicable to the current request.
A tracking status value (TSV) is a short notation for communicating how a designated resource conforms to the tracking protection protocol, as defined by this document and [TRACKING-COMPLIANCE]. For a site-wide tracking status resource, the designated resource to which the tracking status applies is any resource on the same origin server. For a Tk response header field, the corresponding request target is the designated resource and remains so for any subsequent request-specific tracking status resource referred to by that field.
The tracking status value is case sensitive, as defined formally by the following ABNF.
TSV = "1" ; "1" — first-party / "3" ; "3" — third-party / %x43 ; "C" - consent / %x44 ; "D" - disregarding / %x4E ; "N" - none / %x50 ; "P" - potential consent / %x55 ; "U" - updated / %x58 ; "X" - dynamic / ( "!" [testv] ) ; "!" - non-compliant testv = id-char
[PENDING REVIEW] No, in practice there may be dozens of
service providers on any given request. If the designated resource
is operated by a service provider acting as a first party, then
the responsible first party is identified by the
controller
member or the owner of the origin
server domain. This satisfies the use case of distinguishing
between a service provider acting for some other site and the same
service provider acting on one of its own sites.
A tracking status value of N means the origin server claims that the designated resource does not perform tracking of any kind, not even for a permitted use, and does not make use of any data collected from tracking.
A tracking status value of 1 means that the origin server claims that the designated resource is designed for use only within a first-party context and conforms to the requirements on a first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party.
For the site-wide tracking status and Tk header field, the tracking
status values 1
and 3
indicate how the designated resource is designed to conform, not
the nature of the request. Hence, if a user agent is making a
request in what appears to be a third-party context and the
tracking status value indicates that the designated resource is
designed only for first-party conformance, then either the context
has been misunderstood (both are actually the same party) or the
resource has been referenced incorrectly.
For the request-specific tracking status resource, an indication of first or third party as the status value describes how the resource conformed to that specific request, and thus indicates both the nature of the request (as viewed by the origin server) and the applicable set of requirements to which the origin server claims to conform.
A tracking status value of 3 means that the origin server claims that the designated resource is designed for use within a third-party context and conforms to the requirements on a third party.
A tracking status value of X means that the origin server claims that the designated resource is designed for use in both first and third-party contexts and dynamically adjusts tracking status accordingly.
If X
is present in the site-wide tracking status,
more information MUST be provided via the Tk response
header field when accessing a designated resource.
If X
is present in the Tk header field,
more information will be provided in a request-specific
tracking status resource referred to by the status-id.
An origin server MUST NOT send X
as the
tracking status value in the representation of a
request-specific tracking status resource.
A tracking status value of C means that the origin server believes it has received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol.
[OPEN] The C
tracking status
value indicates out of band consent.
[PENDING REVIEW] Proposal is to not add UA requirements.
A tracking status value of P means that the origin
server does not know, in real-time, whether it has received prior
consent for tracking this user, user agent, or device, but
promises not to use or share any DNT:1
data until
such consent has been determined, and further promises to delete
or de-identify within forty-eight hours any DNT:1
data received for which such consent has not been received.
Since this status value does not itself indicate whether a
specific request is tracked, an origin server that sends a
P
tracking status value MUST provide an
edit
member in the corresponding tracking
status representation that links to a resource for obtaining
consent status.
The P
tracking status value is specifically meant to
address audience survey systems for which determining consent at
the time of a request is either impractical, due to legacy systems
not being able to keep up with Web traffic, or potentially "gamed"
by first party sites if they can determine which of their users
have consented. The data cannot be used for the sake of
personalization. If consent can be determined at the time of a
request, the C
tracking status is preferred.
A tracking status value of D means that the origin server is unable or unwilling to respect a tracking preference received from the requesting user agent. An origin server that sends this tracking status value MUST detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from specific user agents (or via specific network intermediaries) that are deemed to be non-conforming, might be collecting additional data from specific source network locations due to prior security incidents, or might be compelled to disregard certain DNT requests to comply with a local law, regulation, or order.
A tracking status value of U means that the request resulted in a potential change to the tracking status applicable to this user, user agent, or device. A user agent that relies on a cached tracking status SHOULD update the cache entry with the current status by making a new request on the applicable tracking status resource.
An origin server MUST NOT send U
as a tracking status
value anywhere other than a Tk header field that is in
response to a state-changing request.
A tracking status value of ! means that the origin server is unable or unwilling to claim that the designated resource conforms to the tracking protection protocol, but is providing a tracking response for the sake of testing and transparency.
The !
value has been provided to ease testing and
deployment on production systems during the initial periods of
testing compliance and during adjustment periods due to future
protocol changes or shifting regulatory constraints. Note that
this value does not indicate that the DNT signal will be ignored,
nor that tracking will occur as a result of accessing the
designated resource, but rather that the site makes no claim to
conformance at this time.
This !
value MAY be followed by an optional
testv character in order to communicate further information
for testing, such as what tracking status the server intends to
deploy for the designated resource at some point in the future,
but that cannot be relied upon as an indication of conformance.
The Tk response header field is hereby defined as an OPTIONAL means for indicating the tracking status that applied to the corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the tracking status.
Tk-field-name = "Tk" Tk-field-value = TSV [ ";" status-id ]
The Tk field-value begins with a tracking status value
(section 5.2 Tracking Status Value),
optionally followed by a semicolon and a status-id
that refers to a request-specific tracking status resource
(section 5.3.2 Referring to a Request-specific Tracking Status Resource).
For example, a Tk header field for a resource that claims not to be tracking would look like:
Tk: N
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 OPTIONAL status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request.
status-id = 1*id-char id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
For example, a response containing
Tk: 1;fRx42
indicates that the target resource claims to conform to the first-party requirements of [TRACKING-COMPLIANCE] and that an applicable tracking status representation can be obtained by performing a retrieval request on
/.well-known/dnt/fRx42
If a Tk field-value has a tracking status value of
X
(dynamic), then a
status-id
MUST be included in the field-value.
The status-id is case-sensitive.
We anticipate that interactive mechanisms might be used, beyond
the scope of this specification, that have the effect of asking
for and obtaining prior consent for tracking, or for modifying
prior indications of consent. For example, the tracking status
resource's status-object defines an edit
member that can refer to such a mechanism. Although such
out-of-band mechanisms are not defined by this specification,
their presence might influence the tracking status object's
response value.
When an origin server provides a mechanism via HTTP for
establishing or modifying out-of-band tracking preferences,
the origin server MUST indicate within the mechanism's response
when a state-changing request has resulted in a change to the
tracking status for that server. This indication of an
interactive status change is accomplished by sending a
Tk header field in the response with a tracking status
value of U
(updated).
Tk: U
An origin server MUST provide a site-wide tracking status resource at the well-known identifier [RFC5785]
/.well-known/dnt/
(relative to the URI of that origin server) for obtaining information about the potential tracking behavior of resources provided by that origin server. A tracking status resource can be used for verification of DNT support, as described in section 5.6 Using the Tracking Status.
A valid retrieval request (e.g., a GET
in HTTP)
on the well-known URI MUST result in either a successful response
containing a machine-readable representation of the site-wide
tracking status, as defined below, or a sequence of redirects that
leads to such a representation.
A user agent MAY consider failure to provide access to such a
representation equivalent to the origin server not implementing
this protocol. The representation can be cached, as described
in section 5.4.5 Caching.
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.3 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
Tk: 1;ahoy
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.
An origin server MUST provide a representation of each tracking
status resource in the JSON format [RFC4627] that conforms 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.
{ "tracking": "1", "qualifiers": "afc", "controller": ["https://www.example.com/privacy"], "same-party": [ "example.com", "example_vids.net", "example_stats.com" ], "third-party": [ "api.example.net" ], "audit": [ "http://auditor.example.org/727073" ], "policy": "/privacy.html#tracking", "edit": "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 [ vs qualifiers ns qualifiers-v ] [ vs controller ns controller-v ] [ 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 edit ns edit-v ] *( vs extension )
A status-object
always has a member named
tracking
with a string value that consists of
the tracking status value applicable to the designated resource
(section 5.2 Tracking Status Value).
tracking = %x22 "tracking" %x22 tracking-v = %x22 TSV %x22
For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform tracking.
{"tracking": "N"}
An origin server MAY send a status-object
member named qualifiers
with a string value
containing a sequence of case sensitive characters corresponding
to each of the permitted uses (as defined in
[TRACKING-COMPLIANCE]) that might be in use for the designated
resource. The purpose of this field is to provide additional
transparency where desired.
qualifier | meaning |
---|---|
a | Audit: Tracking is limited to that necessary for an external audit of the service context and the data collected is minimized accordingly. |
c | Ad frequency capping: Tracking is limited to frequency capping and the data collected is minimized accordingly. |
f | Fraud prevention: Tracking is limited to that necessary for preventing or investigating fraudulent behavior and security violations; the data collected is minimized accordingly. |
l | Local constraints: Tracking is limited to what is required by local law, rule, or regulation and the data collected is minimized accordingly. |
r | Referrals: Tracking is limited to collecting referral information and the data collected is minimized accordingly. |
Multiple qualifiers mean that multiple permitted uses of tracking
might be present and that each such use conforms to the associated
requirements. All qualifiers imply some form of tracking might be
used and thus MUST NOT be provided with a tracking status value of
N
(not tracking).
qualifiers = %x22 "qualifiers" %x22 qualifiers-v = %x22 0*5qualifier %x22 qualifier = %x61 ; "a" - audit / %x63 ; "c" - capping / %x66 ; "f" - fraud / %x6C ; "l" - local / %x72 ; "r" - referral
[OPEN] The list of qualifiers is intended to match one to one to the permitted uses identified by [TRACKING-COMPLIANCE], using references to the definitions there. The list will then be updated accordingly.
An origin server MAY send a member named
controller
with an array value containing
a list of URI references indirectly identifying the party or
set of parties that claims to be the responsible data controller
for personal data collected via the designated resource. An origin
server MUST send a controller
member if the
responsible data controller does not own the designated resource's
domain name.
An origin server that does not send controller
is implying that its domain owner is the sole data controller;
information about the data controller ought to be found on the
designated resource's site root page, or by way of a clearly
indicated link from that page (i.e., no controller member is
considered equivalent to: "controller":["/"]
).
If the designated resource has joint data controllers
(i.e., multiple parties have independent control over the
collected data), the origin server MUST send a
controller
member that contains a reference
for each data controller.
Each URI reference provided in controller
MUST refer to a resource that, if a retrieval action is performed
on that URI, would provide the user with information regarding
(at a minimum) the identity of the corresponding party and
its data collection practices.
controller = %x22 "controller" %x22 controller-v = array-of-strings
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 as
the designated resource.
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 privacy 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 relevant privacy 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
in the machine-readable tracking status representation.
If no policy
member is provided, this
information might be obtained via the links provided in
controller
.
policy = %x22 "policy" %x22 policy-v = string ; URI-reference
An OPTIONAL member named edit
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);
an edit
member SHOULD be provided if the
tracking status value indicates prior consent
(C
).
If no edit
member is provided, this
information might be obtained via the links provided in
controller
or policy
.
An edit 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.
edit = %x22 "edit" %x22 edit-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
{ "tracking": "3", "policy": "/privacy.html", "edit": "/your/data", }
[OPEN] 3 Alternatives - text is needed:
(A) Current draft: Resource is optional
(B) Alternative proposal 1: If multiple domains on a page belong to the
same party, then this fact SHOULD be declared using the
same-party attribute
(C) Alternative proposal 2: State that user agents MAY assume that
additional elements that are hosted under a different URL and occur
on a page and declare "intended for 1st party use" are malicious unless
this URL is listed in the "same-party" attribute
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.
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 tracking status representation 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.3.3 Indicating an Interactive Status Change.
If an origin server receives a request with DNT:1
,
does not have out-of-band consent for tracking this user, and
wishes to deny access to the requested resource until the user
provides some form of user-granted exception or consent for tracking,
then the origin server SHOULD send an HTTP error response with a
status code of 409 (Conflict) and a message body that describes
why the request has been refused and how one might supply the
required consent or exception to avoid this conflict [HTTP11].
The 409 response SHOULD include a user authentication mechanism in the header fields and/or message body if user login is one of the ways through which access is granted.
This section is for collecting use cases that describe questions a user agent might have about tracking status and how the protocol can be used to answer such questions. More cases are needed.
Deployment of this protocol for a given service can
be discovered by making a retrieval request on the site-wide
tracking resource
relative
to the service URI.
/.well-known/dnt/
If the response is an error, then the service does not implement this standard. If the response is a redirect, then follow the redirect to obtain the tracking status (up to some reasonable maximum of redirects to avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message payload, if possible, or consider it an error.
A key advantage of providing the tracking status at a resource separate from the site's normal services is that the status can be accessed and reviewed prior to making use of those services and prior to making requests on third-party resources referenced by those services.
A user agent MAY check the tracking status for a designated
resource by first making a retrieval request for the site-wide
tracking status representation, as described above, and then
parsing the representation as JSON to extract the
status-object
.
If retrieval is unsuccessful or parsing results in a syntax error,
the user agent SHOULD consider the site to be non-conformant with
this protocol.
The status-object
is supposed to have a member
named tracking
containing the tracking status
value. The meaning of each tracking status value is defined in
section 5.2 Tracking Status Value.
If the tracking status value is N, then the origin server claims that no tracking is performed for the designated resource for at least the next 24 hours or until the Cache-Control information indicates that this response expires.
If the tracking status value is not N, then the origin server claims that it might track the user agent for requests on the URI being checked for at least the next 24 hours or until the Cache-Control information indicates that this response expires.
This section is non-normative.
User-granted exceptions to Do Not Track, including site-specific exceptions, are agreed between the site and the user, and stored by the user agent. A resource should rely on the DNT header it receives to determine the user's preference for tracking with respect to that particular request. An API is provided so that sites may request and check the status of exceptions for tracking.
We envisage that the exceptions may also be usable as a consent mechanism.
This section is non-normative.
The following principles guide the design of user-agent-managed exceptions.
opt back into tracking for behavioral advertising or similar purposes when they arrive with the Do Not Track setting enabled.
When asking for a site-specific exception, the top-level origin making the request may be making some implicit or explicit claims as to the actions and behavior of its third parties; for this reason, it might want to establish exceptions for only those for which it is sure that those claims are true. (Consider a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). For this reason, there is support both for explicitly named sites, as well as support for granting an exception to all third-parties on a given site (site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user may desire a site to be allowed to track them on any top-level origin. An API is provided so that the site and the user may establish such a web-wide exception.
The call to store an exception MUST reflect the user's intention to grant an exception, at the time of the call. This intention MUST be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.
[OPEN] We agree that exceptions should reflect user consent and that this needs to be ensured before a site is permitted to register an exception. There is concern that the language above is insufficient to guarantee this desire. Potential language that is acceptable by the whole group is still under discussion.
Sites MAY ask for an exception, and have it stored, even when the user's general preference is not enabled. (This permits recording a permission to allow tracking in jurisdictions where such permission cannot be assumed – see section 6.8 Exceptions without interactive JavaScript.)
The user-agent MAY provide interfaces to the user:
The requirement for the site to determine the user's intention is new; previously the site was required to inform, but the final determination of intention was the responsibility of the UA. This version removes that split of user-determination, and leaves it solely with the site.
This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but should not be read as mandating any specific implementation.
This API considers exceptions which are double-keyed to two domains: the site, and the target. A user might — for instance — want AnalytiCo to be allowed to track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define three terms:
For instance, if the document at
http://web.exnews.com/news/story/2098373.html
references the resources
http://exnews.analytico.net/1x1.gif
and
http://widgets.exsocial.org/good-job-button.js
,
the top-level origin is web.exnews.com
;
exnews.analytico.net
and
widgets.exsocial.org
are both
targets.
[PENDING REVIEW] In the current proposal a
domain
parameter allows exceptions to apply to
sub-domains in the same way as cookies.
The domains that enter into the behavior of the APIs include:
Domains that enter into the decision over what DNT header to be sent in a given HTTP request include:
Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT header it sends them.
The calls cause the following steps to occur (subject to user confirmation of the exception, if the user-agent asks for it):
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A pair of values A and X match if and only if one of the following is true:
In addition, responses to the JavaScript API indicated should be consistent with this user preference (see below).
The prior version of this required that the UA "somehow confirms with the user that they agree to the grant of exception, if not already granted"
[POSTPONED] This model does not support mashed-up content which is in turn
supported by ads; it's not clear how to distinguish between
embedded content which is embedding ads (and hence the top-level
origin stays the same) and embedded content that should start a
new context.
Proposal: For this version of the specification, we don't
address this corner case.
User-agents MUST handle each API request as a 'unit', granting and maintaining it in its entirety, or not at all. That means that a user-agent MUST NOT indicate to a site that a request for targets {a, b, c} exists in the database, and later remove only one or two of {a, b, c} from its logical database of remembered grants. This assures sites that the set of sites they need for operational integrity is treated as a unit. Each separate call to an API is a separate unit.
It is left up to individual user-agent implementations how to determine and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names might mean little to the user. The user might, for example, be told that there is a stored exception for a specific set of sites on such-and-such top-level origin, rather than listing them by name; or the user-agent may decide to store, and show to the user, a site-wide exception, effectively ignoring the list of domain names, if supplied.
Conversely, if a wild-card is used, the user may be told that there is a stored exception for all third-parties that are, or will be, embedded on the indicated the top-level origin.
[OPEN] There is software that in just a few lines of code
just spawn DNT;1 or DNT;0 headers regardless of user's will. A
requirement on the user agent that they can handle the full
exception mechanism will allow to discard compliance statements by
those agents. It will
also allow also the site to test for conformance by requiring an
exception. In case the UA does not react on an exception request,
the server could ignore DNT signals from that UA. It would allow
thus testing from the horizon of the site without wild guessing;
However, there is no practical difference between a UA that hard-wires
'no' to all exception requests, and a UA that does not implement the
calls.
[PENDING REVIEW] The current assumption is that the best practice is to use frames.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
void
dictionary StoreExceptionPropertyBag {
DOMString? domain;
DOMString? siteName;
DOMString? explanationString;
DOMString? detailURI;
};
detailURI
of type DOMString, nullabledomain
of type DOMString, nullableexplanationString
of type DOMString, nullablesiteName
of type DOMString, nullabledictionary StoreSiteSpecificExceptionPropertyBag : StoreExceptionPropertyBag
{
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings
of type sequence<DOMString>
The storeSiteSpecificTrackingException
method takes
a dictionary argument of type StoreSiteSpecificExceptionPropertyBag
that allows optional information to be provided.
If the request does not include the
arrayOfDomainStrings
, then this request is for a
site-wide exception. Otherwise each string in
arrayOfDomainStrings
specifies a
target. When called,
storeSiteSpecificTrackingException
MUST return
immediately.
If the list arrayOfDomainStrings
is supplied, the
user-agent MAY choose to store a site-wide
exception. If it does so it MUST indicate
this in the return value.
If domain
is not specified or is null or empty then
the execution of this API and the use of the resulting permission
(if granted) use the 'implicit' parameter, when the API is called,
the document origin. This forms the first part of
the duplet in the logical model, and hence in operation will be
compared with the top-level origin.
If permission is stored for an explicit list, then the set of duplets (one per target):
[document-origin, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[document-origin, * ]
is added to the database of remembered grants.
If domain
is supplied and not empty then it is treated
in the same way as the domain parameter to cookies and allows setting
for subdomains. The domain
argument can be set to
fully-qualified right-hand segment of the document host name, up to
one level below TLD.
For example, www.foo.bar.example.com may set the
domain parameter as as "bar.example.com"
or
"example.com"
, but not to "something.else.example.com"
or "com"
.
If the document-origin would not be permitted to set a cookie on the
domain
following the cookie domain rules [COOKIES]
(e.g. domain
is not a right-hand match or is a TLD)
then the duplet MUST not be entered into the database and
a SYNTAX_ERR exception should be thrown.
If permission is stored for an explicit list, then the set of duplets (one per target):
[*.domain, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[*.domain, * ]
is added to the database of remembered grants.
A particular response to the API — like a DNT response header — is only valid immediately, and users may choose to edit the list of stored exceptions and revoke some or all of them.
The prior version of this call was asynchronous with a call-back; the change to require the site to determine the user's wishes, rather than the UA, enabled this to become synchronous. This is simpler; the user-agent may still ask for the user's approval. Sites wishing to know whether an exception stands, or the DNT header that they would receive, should call the appropriate enquiry API.
If domain is not supplied or is null or empty then this
ensures that the database of remembered grants no longer
contains any duplets for which the first part is the current
document origin; i.e., no duplets [document-origin,
target]
for any target.
If domain is supplied and is not empty then this
ensures that the database of remembered grants no longer
contains any duplets for which the first part is the
domain wildcard; i.e., no duplets [*.domain, target]
for any target.
There is no callback. After the call has been made, it is assured that there are no site-specific or site-wide exceptions for the given top-level origin.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
void
dictionary RemoveExceptionPropertyBag {
DOMString? domain;
};
domain
of type DOMString, nullableWhen this method returns the database of grants no longer contains the indicated grant(s); if some kind of processing error occurred then an appropriate exception will be thrown.
If there are no matching duplets in the database of remembered grants when the method is called then this operation does nothing (and does not throw an exception).
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
boolean
dictionary ConfirmExceptionPropertyBag {
DOMString? domain;
};
domain
of type DOMString, nullabledictionary ConfirmSiteSpecificExceptionPropertyBag : ConfirmExceptionPropertyBag
{
sequence<DOMString> arrayOfDomainStrings;
};
arrayOfDomainStrings
of type sequence<DOMString>
If the call does not include the
arrayOfDomainStrings
, then this call is to confirm a
site-wide exception. Otherwise each string in
arrayOfDomainStrings
specifies a
target.
If the list arrayOfDomainStrings
is supplied, and the
user-agent stores only site-wide exceptions, then the user-agent
MUST match by confirming a site-wide exception.
If the domain
argument is not supplied or is null or empty
then the execution of this API uses the 'implicit' parameter,
when the API is called,
the document origin. This forms the first part of
the duplet in the logical model.
If the user-agent stores explicit lists, and the call includes one, the database is checked for the existence of all the duplets (one per target):
[document-origin, target]
If the user-agent stores only site-wide exceptions or the call did not include an explicit list, the database is checked for the single duplet:
[document-origin, * ]
If the user-agent stores explicit lists, and the call includes one,
and the domain
argument is provided and is not empty then the
database is checked for the existence of all the duplets (one per target):
[*.domain, target]
If the user-agent stores only site-wide exceptions or the call did
not include an explicit list, and the domain
argument is
provided and is not empty then the database is checked for the single
duplet:
[*.domain, * ]
The returned boolean has the following possible values:
true
all the duplets exist in the database;false
one or more of the duplets does not
exist in the database.
[ * , document-origin]
or
[ * , *.domain]
(based on if domain
is provided and is not null and not empty)
is added to the database of remembered grants.
The members of the StoreExceptionPropertyBag
dictionary are as described
above in the
request for site-specific exceptions.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
void
This API requests the addition of a web-wide grant for a specific site, to the database.
As above, this call used to be asynchronous, and the change to the UI enabled it to be synchronous.
[ * , document-origin]
or [ * , *.domain]
(based on if domain
is provided and is not null and not empty).
There is no callback. After the call has been made, the
indicated pair is assured not to be in the database. The same
matching as is used for determining which header to send is used
to detect which entry (if any) to remove from the database.
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
void
Parameter | Type | Nullable | Optional | Description |
---|---|---|---|---|
properties |
| ✘ | ✘ |
boolean
This API confirms the existence of a web-wide grant for a specific site, in the database.
The returned boolean indicates whether the duplet
[ * , document-origin]
or [ * , *.domain]
(based on if domain
is provided and is not null and
not empty) exists in the database.
true
indicates that the web-wide exception exists;false
indicates that the web-wide exception
does not exist.A site may request an exception for one or more third party services used in conjunction with its own offer. Those third party services may wish to use other third parties to complete the request in a chain of interactions. The first party will not necessarily know in advance whether a known third party will use some other third parties.
If a user-agent sends a tracking exception to a given combination of origin server and a named third party, the user agent will send DNT:0 to that named third party. By receiving the DNT:0 header, the named third party acquires the permission to track the user agent and collect the data and process it in any way allowed by the legal system it is operating in.
Furthermore, the named third party receiving the DNT:0 header acquires at least the right to collect data and process it for the given interaction and any secondary use unless it receives a DNT:1 header from that particular identified user agent.
The named third party is also allowed to transmit the collected data for uses related to this interaction to its own sub-services and sub-sub-services (transitive permission). The tracking permission request triggered by the origin server is thus granted to the named third party and its sub-services. This is even true for sub-services that would normally receive a DNT:1 web-wide preference from the user-agent if the user agent interacted with this service directly.
For advertisement networks this typically would mean that the collection and auction system chain can use the data for that interaction and combine it with existing profiles and data. The sub-services to the named third party do not acquire an independent right to process the data for independent secondary uses unless they, themselves, receive a DNT:0 header from the user agent (as a result of their own request or the request of a first-party). In our example of advertisement networks that means the sub-services can use existing profiles in combination with the data received, but they can not store the received information into a profile until they have received a DNT:0 of their own.
A named third party acquiring an exception with this mechanism MUST make sure that sub-services it uses acknowledge this constraint by requiring the use of the appropriate tracking status value and qualifier, which is "XX" (such as "tl"), from its sub-sub-services.
The permission acquired by the DNT mechanism does not override retention limitations found in the legal system the content provider or the named third party are operating in.
[OPEN] When the status values and qualifiers are fixed, the penultimate paragraph will probably need adjusting to match. The use of "tl" (which meant "tracking but only in accordance with local laws" when this text was written) doesn't seem right, as the text talks, essentially, of the sub-sub-service acting on behalf of the site that received the DNT:0 header, which might suggest something more like "CS" (service provision to a third-party that received consent).
This section is non-normative.
As described above, it is the responsibility solely of the site making the call to determine that an exception grant reflects the user's informed consent at the time of the call.
It is expected that the site will explain, in its online content, the need for an exception, and the consequences of granting or denying an exception, to the user.
User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a notification to the user at the time of the request, or even not complete the storing of the exception until the user approves. Some agents might provide a user-interface to see and edit the database of recorded exception grants. The API parameters siteName, explanationString, and detailURI are provided so that the user-agent may use them in their user interface.
A user agent that chooses to highlight when tracking exceptions have been stored might provide an interface like the following.
In some user-agent implementations, decisions to grant exceptions may have been made in the past (and since forgotten) or may have been made by other users of the device. Thus, exceptions may not always represent the current preferences of the user. Some user agents might choose to provide ambient notice that user-opted tracking is ongoing, or easy access to view and control these preferences. Users may desire options to edit exceptions either at the time of tracking or in a separate user interface. This might allow the user to edit their preferences for a site they do not trust without visiting that site.
This section is non-normative.
Some third party servers that comply with this standard may wish to receive user-granted exceptions but when they are invoked as third parties (using, for example, images, or "tracking pixels") do not have an interactive JavaScript presence on the page. They cannot request an exception under these circumstances, both because a script is needed, and because they are required to explain to the user the need for and consequences of granting an exception, and get the user's consent. In general this process of informing, getting consent, and calling the API is not expected to be in the page where such trackers are invoked.
To obtain an exception, a document (page, frame, etc.) that loads the Javascript is needed. The user may visit the site that desires an exception directly, the first party site could load a frame of the site desiring the exception, or that frame might be part of some other page containing a number of frames, which allows aggregation of requests for exceptions.
In all these ways, the site is contributing to informing the user and getting their consent, and is also able to call the Javascript API when it is granted.
Depending on the resolution of options for the User-Granted Exceptions section, this language might need to be updated to correspond.
Sites might wish to request exceptions even when a user arrives without a DNT header. Users might wish to grant affirmative permission to tracking on or by certain sites even without expressing general tracking preferences.
User agents MAY instantiate
navigator.storeSiteSpecificTrackingException
even when navigator.doNotTrack
is null. Sites SHOULD
test for the existence of
storeSiteSpecificTrackingException
before calling
the method. If an exception is granted in this context and the
user-agent stores that preference, a user agent may send a DNT:0
header even if a tracking preference isn't expressed for other
requests. Persisted preferences MAY also affect which header is
transmitted if a user later chooses to express a tracking
preference.
Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification.
This section is non-normative.
This section is to inform the authors of sites on some considerations in using the exceptions APIs to best effect; sites of particular interest here are those that need an exception in order to allow the user to perform some operation or to have some access.
The 'Store' calls do not have a return value, and return immediately. If there is a problem with the calling parameters, then a Javascript exception will be raised. In addition, it may be that the user-agent does not immediately store the exception, possibly because it is allowing the user to confirm. Even though the site has acquired the user's informed consent before calling the 'Store' API, it is possible that the user will change their mind, and allow the store to proceed but then later ask it be removed, or even by denying the storage in the first place.
The use of the word 'exception' both to describe the user granting something, and for a problem in Javascript, is an unfortunate clash here.
Sites can call the 'Confirm' APIs to enquire whether a specific exception has been granted and stands in the user-agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been deleted, or not yet granted), then the user is ideally again offered the information needed to give their informed consent, and again offered the opportunity to indicate that they grant it. As stated in the normative text, the site needs to explain and acquire consent immediately prior to calling the Store API, and not remember some past consent; this allows the user to change their mind.
If they do grant it (using some positive interaction such as a button), the site can return to checking the 'Confirm' API.
In this way the site:
By storing a client-side configurable state and providing functionality to learn about it later, this API might facilitate user fingerprinting and tracking. User agent developers ought to consider the possibility of fingerprinting during implementation and might consider rate-limiting requests or using other heuristics to mitigate fingerprinting risk. User agents SHOULD clear stored user-granted exceptions when the user chooses to clear cookies or other client-side state.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Nick Doty (W3C/MIT), Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Mozilla), Matthias Schunter (IBM), John Simpson (Consumer Watchdog), David Singer (Apple), David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C/ERCIM), Shane Wiley (Yahoo!), and Andy Zeigler (Microsoft).
The DNT header field is based on the original Do Not Track
submission by Jonathan Mayer (Stanford), Arvind Narayanan
(Stanford), and Sid Stamm (Mozilla).
The DOM API for NavigatorDoNotTrack
is based on the
Web Tracking Protection submission by Andy Zeigler,
Adrian Bateman, and Eliot Graff (Microsoft).
Many thanks to Robin Berjon for ReSpec.js.