Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Trackingresponse header field for third-party resources that engage in cross-site tracking, and a mechanism for allowing the user to approve site-specific 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 draft does not represent a final working group consensus, though an attempt has been made to highlight areas where issues have been identified and present multiple alternatives if they have been discussed.
This document was published by the Tracking Protection Working Group as a First Public 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@w3.org (subscribe, archives). All feedback is 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 analytics providers through the insertion of tracking elements on each page.
Advertising revenue is the single largest source of funding on the Web. Since advertisers desire an audience that is receptive to whatever they happen to be advertising, a significant premium is assigned to sites that can demonstrate a favorable target audience, and even more so for sites that are able to identify their audience dynamically and adjust the advertising displayed to be specific to the interests of that user. In an attempt to better understand or predict those interests, some advertising mechanisms follow a user's actions over time, collect data on the observed behavior, and use that data for targeting future advertisements: a practice commonly referred to as online behavioral advertising (OBA).
Like analytics data collection, Web sites often contract with third-party advertising networks for the tasks of selecting, delivering, and measuring the advertising shown on their sites, while advertisers often contract with third-party verification companies to provide independent accounting of ad impressions and fraud detection.
There are numerous techniques for integrating advertising networks into a website, though most involve some form of embedded resource request to a site controlled by the advertising network. Since the advertising networks are supplying ads for multiple sites, they are capable of monitoring how often a given ad is displayed to that same user agent across their entire network (frequency capping). Naturally, advertisers consider frequency capping to be a desirable feature, and thus it is common for advertisers to contractually limit advertising campaigns to a maximum impression count per user. As a result, advertising networks track users from site to site even when OBA is not in use.
In many cases, Web users welcome the use of data collection for
personalization and targeted advertising, since it can allow a site
to tailor the user experience to their specific desires, reduce ads
that are irrelevant or repetitive, and avoid the imposition of more
direct revenue in the form of subscription-only services.
In other cases, personalization and targeting can be perceived as
creepy
, intrusive, and sometimes simply incorrect.
In particular, targeting and personalization can evoke strong
negative feelings when data collected at a trusted site is used,
without the user's consent, for targeting ads on some other site
with which they have no personal trust relationship. When cross-site
tracking or cross-site sharing of data collection does not match the
user's expectations regarding privacy, the result can be a very
angry customer.
None of the participants in this Web of customization and targeted advertising want to offend the user. For advertisers, it is counterproductive. For Web site owners, it drives away their audience and income. For advertising networks, it leads to blocking and lost advertisers. Therefore, we need a mechanism for the user to express their own preference regarding cross-site tracking that is both simple to configure and efficient when implemented. Likewise, since some Web sites may be dependent on the revenue obtained from targeted advertising and unwilling (or unable) to permit use of their content without cross-site data collection, we need a mechanism for sites to alert the user to those requirements and allow the user to configure an exception to DNT for specific sites.
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 site-wide policy regarding DNT compliance, and the HTTP response header field Tracking for third-party resources engaged in dynamic tracking behavior to communicate their compliance or non-compliance with the user's expressed preference.
A companion document, Tracking
Compliance and Scope
, 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.
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 browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].
ISSUE-13 : What are the requirements for DNT on apps/native software in addition to browsers?
[PENDING REVIEW]
The above paragraph aims at resolving this issue.
The goal of this protocol is to allow a user to express their personal preference regarding cross-site tracking to each server and web application that they communicate with via HTTP, thereby allowing each server to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy both parties. Key to that notion of expression is that it must reflect the user's preference, not the preference of some institutional or network-imposed mechanism outside the user's control.
The remainder of this specification defines the protocol in terms of whether DNT is enabled or not enabled. We do not specify how that preference is configured: the user agent is responsible for determining the user experience by which this preference is set.
For example, a user might configure their own user agent to
tell servers do not track me cross-site
, install a plug-in
or extension that is specifically designed to add that expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g., Privacy settings: high
). For each
of these cases, we say that DNT is enabled.
ISSUE-4: What is the default for DNT in client configuration (opt-in or opt-out)?
[PENDING REVIEW]
Proposed text above.
When a user has configured 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.
The DNT header field is hereby defined as the means for expressing a user's tracking preference via HTTP [HTTP11]. A user agent must send the DNT header field on all HTTP requests if (and only if) DNT is enabled. A user agent must not send the DNT header field if DNT is not enabled.
DNT-field-name = "DNT" ; case-insensitive DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive DNT-extension = %x21-2B / %x2D-7E ; visible ASCII except ","
The DNT field-value sent by a user agent must begin with the character "1" (%x31) if DNT is enabled and there is not, to the user agent's knowledge, a specific exception for the origin server targeted by this request. If DNT is enabled and there is a specific exception for the target origin server via some mechanism understood by the user agent, then the DNT field-value sent by a user agent must begin with the character "0" (%x30).
ISSUE-78: What is the difference between absence of DNT header and DNT = 0?
[PENDING REVIEW]
Proposed text above defines that a "0" may only be sent when DNT is
enabled and some mechanism known to the user agent has specifically
made an exception for this origin server. Note that we have not
defined such a mechanism (and probably won't do so). If DNT is
disabled or not implemented, no DNT header field is sent.
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 selected a choice.
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 DNT is enabled, but if you understand the refinements defined
by x, y, or z, then adjust my preferences according to those
refinements.
Extensions can only transmitted if DNT is
enabled. The extension syntax excludes the comma (",")
character in order to to differentiate valid field values from an
invalid occurrence of multiple DNT header fields that have been
combined as a single comma-separated list by a generic HTTP parser.
Designers of future extensions should note that, if enabled, DNT is sent on every request and is thus in the critical path for a server attempting to read and act on every request. Use as few extension characters as possible.
ISSUE-82: Should the DNT header be extensible with additional parameters?
[PENDING REVIEW]
The above paragraphs allow for an extension string. At this point,
no extensions have been defined.
The NavigatorDoNotTrack
interface provides a means for
the user's cross-site tracking preference to be expressed to
web applications running within a page rendered by the user agent.
null
.
Navigator implements NavigatorDoNotTrack
;
Navigator
interface
[NAVIGATOR] (e.g., the window.navigator
object)
must also implement the NavigatorDoNotTrack
interface.
An instance of NavigatorDoNotTrack
is obtained
by using binding-specific casting methods on an instance of
Navigator
.
ISSUE-84: Do we need a JavaScript API / DOM property for client-side js access to Do Not Track status?
[PENDING REVIEW]
We believe that we need such an API. This section proposes one.
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. Therefore, we will define here various mechanisms for communicating the DNT preference via common plug-in APIs.
Tracking Compliance and Scope, defines how service providers are expected to comply when they receive an expression of the user's tracking preference via any of the mechanisms described in section 4. Expressing a Tracking Preference.
If no DNT preference is received, it may indicate either that the user has chosen to allow cross-site tracking or that their user agent does not support this protocol for expressing DNT (e.g., user agents deployed prior to this protocol's existence). In the absence of regulatory, legal, or other requirements, servers are free to interpret the lack of a DNT header as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances.
This section defines how a server communicates its compliance with tracking preferences, including whether it will honor the user's preference, require some form of site-specific exception, or indicate that it already has the user's permission via some other agreement (e.g., a subscription or account agreement). Optionally, links can be provided to human-readable information regarding the site's tracking policies or where to go to opt-in, opt-out, or edit their personal information.
The following goals have been identified as reasons for having a response from the server:
ISSUE-98: Consider applicable laws and regulations, such as Article 5(3) of the EU ePrivacy Directive
The following criteria have been identified as constraints on the response design:
There have been many suggestions, but not much consensus, on how servers ought to respond when DNT is enabled. The various suggestions can be roughly categorized as follows:
and also some combinations of the above. For example, we might define that compliant servers provide a machine-readable site-wide policy that indicates how they honor DNT, what sites are considered the same brand, and links to resources for providing site-specific exceptions to DNT or editing collected tracking data. We could then limit use of a tracking response header field to only those dynamic responses for third-party resources that engage in tracking.
ISSUE-81: Do we need a response at all from server?
[PENDING REVIEW]
Yes: The users expect to be able to see whether a DNT header is
accepted, rejected, or sent into the void.
ISSUE-79: Should a server respond if a user sent DNT:0?
ISSUE-51: Should 1st party have any response to DNT signal
This can be defined as either a well-known location, as defined by RFC5785, or as a Link header field sent in response to any request (regardless of DNT).
ISSUE-47: Should the response from the server point to a URI of a policy (or an existing protocol) rather than a single bit in the protocol?
ISSUE-80: Instead of responding with a Link: header URI, does it make sense to use a well-known location for this policy?
ISSUE-87: Should there be an option for the server to respond with "I don't know what my policy is"
ISSUE-61: A site could publish a list of the other domains that are associated with them
i am neutral) and dynamic headers when
I am a tracking element and I accept your choice to not be tracked
I see that you say DNT, but i am tracking you for the following reasons.
ISSUE-76: Should a server echo the DNT header to confirm receipt?
ISSUE-48: Response from the server could both acknowledge receipt of a value and (separately) whether the server will honor it
ISSUE-90: Interaction of DNT with caching and intermediaries
An HTTP error response status code might be useful for indicating that the site refuses service unless the user either logs into a subscription account or agrees to an exception to DNT for this site and its contracted third-party sites.
ISSUE-43: Sites should be able to let the user know their options when they arrive with Do Not Track
ISSUE-27: How should the "opt back in" mechanism be designed?
ISSUE-46: Enable users to do more granular blocking based on whether the site responds honoring Do Not Track
It would annoy users of DNT if they are presented with an exception dialog each time they visit a site.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Aleecia M. McDonald (Mozilla), Matthias Schunter (IBM), and Shane Wiley (Yahoo!).
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.
ISSUE-2: What is the meaning of DNT (Do Not Track) header?
[CLOSED]
"Does the presence of a DNT header field on requests always indicate
an explicit choice".
The answer we agreed upon is "yes".
ISSUE-50: Are DNT headers sent to first parties? Yes
ISSUE-70: Does a past HTTP request with DNT set affect future HTTP requests? No
ISSUE-40: Enable Do Not Track just for a session, rather than being stored
[CLOSED]
Resolved in DNT Call 2011-10-26: The user agents are free to send
different DNT values for different sessions. We agreed that this is
a user-interface issue and out of scope on its own.
ISSUE-68: Should there be functionality for syncing preferences about tracking across different browsers?
[CLOSED]
Resolved in DNT Call 2011-10-26: The user agents may or may not sync.
However, this is out of scope for this spec.
ISSUE-42: Feedback to the user from the browser when Do Not Track is turned on
ISSUE-44: Ability to measure/detect who is honoring Do Not Track at a technical level
[POSTPONED]
The info at the well-known URI declares whether a server promises to
follow DNT. Whether it actually does (or just pretends to do so) is
hard to determine and should be addressed later.
ISSUE-64: How does site preference management work with DNT
[POSTPONED]
To what extent cookies can be used for preference management (such as
storing a language preference) will be resolved later.
No informative references.