This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.
This document is a significantly streamlined version of the compliance spec for discussion at the Cambridge face-to-face meeting of the Tracking Protection Working Group on Feburary 11-13, 2013. This language reflects the editors effort to simplify existing text and has not been formally adopted by the Working Group. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document.
The introduction will be re-worked after details of substantive text is closer to being finalized.
This section will be re-worked after details of substantive text is closer to being finalized.
A user is an individual human. When user-agent software accesses online resources, whether or not the user understands or has specific knowledge of a particular request, that request is made "by" the user.
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]].
There has been recent discussion about whether the specification should differentiate among different types of users agents (such as general purpose browsers, add-ons, and stand-alone software programs), and possibly specify different compliance obligations depending on the type of user agent, or priority among different categories of user agents in the event of conflicting settings. There is currently no open ISSUE associated with this discussion.
A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person. For unique corporate entities to qualify as a common party with respect to this document,those entities MUST be commonly owned and commonly controlled and MUST provide easy discoverability of affiliate organizations. An list of affiliates MUST be provided within one click from each page or the entity owner clearly identified within one click from each page.
We do not expect outsourcing to be a major topic of discussion at the Cambridge face-to-face, so this definition is suggested as a placeholder. Some working group participants have argued for more prescriptive rules to qualify as a service provider.
Outsourced service providers are considered to be the same party as their clients if the outsourced service providers only act as data processors on behalf of that party in relation to that party, silo the data so that it cannot be accessed by other parties, and have no control over the use or sharing of that data except as directed by that party.
A first party is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party.
A third party is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it.
First Party is the party that owns or has control over the resource the consumer visits. A First Party also includes the owner or controller of an embedded widget, search box or similar service with which a consumer interacts. If a user merely mouses over, closes, or mutes third-party content, that is not sufficient interaction to constitute a First Party widget interaction.
A Third Party is any party other than a First Party, Service Provider, or the user. It is possible to have multiple first parties on a single page but each party must provide clear branding and a link to their respective privacy policy (co-branded experience).
The scope of a "first party" is determined by user expectations and control over the data collected, not limited to a specific site, domain, or legal entity. The first party includes the legal entity that owns and controls the site intended by the user's action and any employees, officers, affiliates, and contractors that operate on behalf of that entity and that are bound under contract to keep data collected on behalf of that entity confidential within the scope of the first party, separated from data collected on behalf of other parties, and to have no independent rights to use, share, or retain the collected data except as directed by the first party. A site that is operated on behalf of multiple legal entities is considered to have a joint first party if a user's expectation would be that each of those entities have control over the data collected.
Data is deidentified when a party:
(1) has taken measures to ensure with a reasonable level of
justified confidence that
the data cannot be used to infer information about,
or otherwise be linked to, a particular consumer, computer,
or other device;
(2) does not to try to reidentify the data; and
(3) contractually prohibits downstream recipients from trying to re-identify the data.
A network interaction is an HTTP request and response, or any other sequence of logically related network traffic.
These continue to be actively debated issues, as the resolution of the use of unique identifiers is likely to end up in these definitions.
The definitions of collection, retention, use, and sharing are drafted expansively so as to comprehensively cover a party's user-information practices. These definitions do not require a party's intent; a party may inadvertently collect, retain, use, or share data. The definition of collection includes information that a party did not cause to be transmitted, such as protocol headers.
Alternative: A party "collects" data when it assembles data from or about one or more network interactions and retains or shares that data beyond the scope of responding to the current request or in a form that remains linkable to a specific user, user agent, or device.
A party may receive, retain, and use data as otherwise prohibited by this standard, so long as it is unaware of such information practices and has made reasonable efforts to understand its information practices. If a party learns that it possesses information in violation of this standard, it must delete that information at the earliest practical opportunity.
The term "tracking" is not used in the document. We may subsequently decide to define this issue, or address the issue of what is "tracking" in the Introduction or Scope section.
The spec currently envisions that users should consent to both the setting of a DNT preference as well as any user-granted exceptions. We have not reached agreement on how precisely we need to define this term.
Explicit and informed choice must satisfy the following bright-line
requirements:
1. Actual presentation: The choice mechanism MUST be
actually presented to the user. It MUST NOT be on a linked page,
such as a terms of service or privacy policy.
2. Clear Terms:The choice mechanism MUST use clear,
non-confusing technology.
3. Independent choice: The choice mechanism MUST be
presented independent of other choices. It MUST NOT be bundled with
other user preferences.
4. No default permission: The choice MUST NOT have the user
permission selected by default.
No definition, other than explicitly leaving the definition of consent to local rules.
This language is not consensus and must change. The parties are generally agreed that this language should only prohibit first parties from enabling third parties to circumvent "Do Not Track" by providing them with correlatable cross-site data in a different context. There is an open debate about the extent to which this should prohibit "data append" practices, where first parties query data brokers about their users (and thus trasmit information to the brokers) order to augment their own records on users.
If a First Party receives a network transaction to which a DNT:1 header is attached, First Parties may engage in their normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.
The First Party must not pass information about this transaction to non-service provider third parties who could not collect the data themselves under this standard.
A user agent MUST offer a control to express a tracking preference to third parties. The control MUST communicate the user's preference in accordance with the [[!TRACKING-DNT]] recommendation and otherwise comply with that recommendation. A user agent MUST NOT express a tracking preference for a user unless the user has given express and informed consent to indicate a 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"). Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.
Shane's proposal has suggested the additional compliance requirements
of user agents:
1. The User Agent must also make available via a link in explanatory
text where DNT is enabled to provide more detailed information about
DNT functionality
2. Any User Agent claiming compliance must have a functional
implementation of the browser exceptions in this specification
If a third party receives a communication to which a DNT:1 header is attached:
Unclear whether this section reflects group consensus.
If the operator of a third-party domain receives a communication to which a DNT:1 header is attached:
Reasonable behavior: A user visits you from an IP address which a general geo-IP database suggests is in the NYC area, where it is 6pm on a Friday. You choose to show an advertisement for theaters and restaurants in the area.
Invasive behavior: A user visits you from an IP address which suggests that they are in a particular ZIP+4, which has a distinctive demographic profile. Their user-agent indicates that they are a Mac user, further narrowing their expected profile. You serve them an ad for business within a few blocks of them which specializes in items which their expected profile indicates they may enjoy.
In this example, even though the decision about which ad to serve was based exclusively on request specific information, but was still tailored to a highly-specific user profile. In particular, the estimation of a user's location to within a single ZIP+4 may make a user feel that they are being followed closely, even if the decision was made on the fly, and the information was only held ephemerally.
These are options that have been discussed in the group. While many have broad consensus within the group, some are debated both based on scope of the draft and whether they should be permitted uses. There is also substantial disagrement over the SCOPE of information that may be collected, used, and retained for these purposes, most notably whether persistent unique identifiers may be collected, used, and retained for these purposes.
If a third-party receives a communication to which a DNT:1 header is attached, that third party MAY nevertheless collect, use, and retain information related to that communication for these permitted uses:
As long as there is:
These permitted uses and requirements are further discussed below.
In order to use the permitted uses outlined below, a party MUST comply with these four requirements.
Third Parties MUST NOT use data retained for a permitted use for non-permitted uses.
Data retained by a party for permitted uses MUST be limited to the data reasonably necessary for such permitted uses, and MUST be retained no longer than is reasonably necessary for such permitted uses. A third party MUST make reasonable data minimization efforts to ensure that only data necessary for each permitted use is retained. A third party MUST provide public transparency of their data retention period for each permitted use. Once a retention period for a given use has expired, the data MUST NOT be used for that permitted use; when there are no remaining permitted uses for some data, that data MUST either be deleted or rendered unlinkable.
Additional proposed language:
Where feasible, a third party SHOULD NOT collect linkable data when that
data is not reasonably necessary for one of the permitted uses. In
particular, data not necessary for a communication (for example, cookie
data, URI parameters, unique identifiers inserted by a network intermediary)
MUST NOT be retained unless reasonably necessary for a particular permitted use.
Third parties MUST use reasonable technical and organizational safeguards to prevent further processing of data retained for Permitted Uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties SHOULD ensure that the access and use of data retained for Permitted Uses is auditable.
Outside of Security and Frequency Capping, data retained for Permitted Uses MUST NOT be used to alter a specific user's online experience [based on multi-site activity].
A third party may only collect, use, and retain for permitted
uses information that a user agent necessarily shares with a web
server when it communicates with the web server (e.g. IP address
and User-Agent), and the URL of the top-level page, communicated
via a Referer header or other means, unless the URL contains
information that is not unlinkable (e.g. a username or user
ID).
A third party may not collect, use, or retain information that a
web server could cause to not be sent but still be able to
communicate with the user agent (e.g. a cookie or a Request-URI
parameter generated by the user agent), except the URL of the
top-level page, or any data added by a network intermediary that
the operator of a web server has actual knowledge of (e.g. a
unique device identifier HTTP header).
Flexibility is provided to implementers on how they accomplish permitted
uses and minimize data retention and use. Implementers are advised to
avoid data collection for DNT:1 users where feasible to enable external
confidence.
Placing third-party cookies with unique identifiers (and other techniques
for linking data to a user, user agent or device) are permitted where
reasonably necessary for a permitted use. Requirements on minimization
and secondary use, however, provide limitations on when any collection
technique is compatible with a Do Not Track preference and what the
implications of that collection are.
To give flexibility to implementers in accomplishing the requirements of
this specification and the listed permitted uses, no particular data
collection techniques are prescribed or prohibited.
Implementers are advised that collection of user data under a Do Not Track
preference (including using unique tracking cookies or browser fingerprinting)
may reduce external auditability, monitoring and user confidence and that
retention of such data may imply liability in certain jurisdictions in cases
of secondary use; for more information, see the Global Considerations.
The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement that permitted use data is not correlated to a unique cookie or other persistent identifier. This issue remains one of the biggest areas of dispute in the working group, as the industry proposal allows for the use of cookies and other unique identifiers by third parties despite a DNT:1 instruction.
This is not a consensus option. It has alternatively been proposed as a way to address inadvertent collection, collection where party is not sure whether collection or use is proper, and research/reporting. Those issues may be addressed elsewhere.
Information may be collected, retained, and used any purpose, so long as the information is retained for no longer than N weeks and the information is not transmitted to a third party and the information is not used to build a profile about a user or otherwise alter any individual's user experience (apart from changes that are made based on aggregate data or security concerns).
Operators MAY collect and retain data related to a communication in a third-party context for up to N weeks. During this time, operators may render data deidentified or perform processing of the data for any of the other permitted uses.
Note that it is not clear that this is in scope, per Shane; others disagree. Revisit whether contextual belongs in some place other than permitted uses (potentially the definition of collection).
Information may be collected, retained and used for the display of contextual content or advertisements, including content or advertisements based on the first-party domain that the user visited.
Information may be collected, retained and used for the display of content or advertisements based in part on data that the third party previously collected from the user when acting as a first party.
This text may be revised to offer two alternatives:
first parties can use any data to offer content in the third party
context, or first parties can only use declared data to offer
content in the third party context. Shane Wiley has proposed
defining "declared data" as Information directly and expressly
supplied by a user to a party through meaningful interaction with
that party.
The issue is also contingent
upon what identifiers third parties can use in when Do Not Track is
turned on. If third parties cannot read cookies, they may be
unable to associate first parties in third-party scenarios.
Others have argued that this language is unnecessary because the
standard places no limitations on the use of first party data.
Information may be collected, retained and used for limiting the number of times that a user sees a particular advertisement, often called "frequency capping."
In Seattle, we discussed specifically limiting how data was
stored for frequency capping:
Server-side frequency capping is allowed if the tracking
identifier is only retained in a form that is unique to each
super-campaign (e.g., one-way hashed with a campaign id) and does
not include retention of the user's activity trail (page URIs on
which the ads were delivered) aside from what is allowed for
other permitted uses.
Information may be collected, retained and used for billing and auditing of concurrent transactions. This may include counting ad impressions to unique visitors, verifying positioning and quality of ad impressions and auditing compliance with this and other standards.
One potential additional compromise on the unique identifier issue for logging would be grandfather in existing contracts that require unique, cookie-based counting. New contracts would not be able to require that ad networks use cookies (or other unique identifiers) to uniquely count users who have DNT:1 enabled.
Information may be collected, retained and used to the extent reasonably necessary for detecting security risks and fraudulent or malicious activity. This includes data reasonably necessary for enabling authentication/verification, detecting hostile and invalid transactions and attacks, providing fraud prevention, and maintaining system integrity. In this example specifically, this information may be used to alter the user's experience in order to reasonably keep a service secure or prevent fraud. Graduated response is preferred when feasible.
Information may be collected, retained and used for identifying and repairing errors that impair existing intended functionality.
Adherence to laws, legal and judicial process, and regulations take precedence over this standard when applicable, but contractual obligations do not.
There had previously been an open debate about whether Aggregate Reporting (including market research and product improvement) should be a dedicated Permitted Use. The group has since decided to address this issue through the exception for Unlinkable Data.
When a user sends the DNT:0 signal, they are expressing a preference for a personalized experience. This signal indicates explicit consent for data collection, retention, processing, disclosure, and use by the recipient of this signal to provide a personalized experience for the user. This recommendation places no restrictions on data collected from requests received with DNT:0.
The operator of a website may engage in practices otherwise described by this standard if the user has given explicit and informed consent. This consent may be obtained through the browser API defined in the companion [[!TRACKING-DNT]] document, or an operator of a website may also obtain "out-of-band" consent to disregard a "Do Not Track" preference using a different technology. If an operator is relying on "out of band" consent to disregard a "Do Not Track" instruction, the operator must indicate this consent to the user agent as described in the companion [[!TRACKING-DNT]] document.
This protocol does not define what constitutes explicit consent in any jurisdiction; check with your lawyer.
Figure out which parts of UGE belong in which document.
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out signals at the same time, it'll be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.
As a general principle, more specific settings override less specific settings.
If a third party receives a communication to which a DNT:1 header is attached, that third party MAY neverthess collect, retain, share, or use data related to that communication if the data is or has been rendered deidentified.
This section has been and will continue to be the topic of active debate. We do not expect to resolve this issue at the Cambridge meeting.
Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly formed even if the third party does not believe that the DNT:1 header was set with the explicit and informed consent of the user.
If the operator of a third-party domain has a good faith belief that a user agent is sending a DNT:1 without the explicit and informed consent of the user, the operator MAY disregard the DNT:1 header and collect, use, and retain information about the user as if no DNT signal had been sent. If the operator disregards the DNT signal, the operator MUST signal to the user agent that it is disregarding the header as described in the companion [[!TRACKING-DNT]] document.
If the operator of a third-party domain does not intend to comply with a DNT:1 signal whose syntax is correctly formed, the operator MUST send a signal to the user agent that it is disregarding the header as described in the companion [[!TRACKING-DNT]] document.
No provision on disregarding non-compliant user agents.
Final wording awaits how the response is designed in the TRACKING-DNT recommendation, but we agree upon the general direction below.
In order to be in compliance with this specification, a third party must make a public commitment that it complies with this standard. A "public commitment" may consist of a statement in a privacy policy, a response header, a machine-readable tracking status resource at a well-known location, or any other reasonable means. This standard does not require a specific form of public commitment.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando (Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), 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.