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 an editors' strawman reflecting a snapshot of live discussions within the Tracking Protection Working Group. It does not yet capture all of our work. For example, we have issues that are [PENDING REVIEW] with complete text proposals that have not yet made it into this draft. Text in blue boxes presents multiple options the group is considering. Options included in this draft should not be read as limitations on the potential outcome, but rather simply as possible options that are currently under consideration by the working group. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document.

Introduction

This introduction will be re-worked after details of substantive text is closer to being finalized.

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 user-granted exceptions.

This specification 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. This specification defines the meaning of a Do Not Track preference and sets out practices for websites and other online companies to comply with this preference.

A companion document, [[!TRACKING-DNT]], 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 site-specific, user-granted exception.

Scope and Goals

This section consists of proposed text that is meant to address ISSUE-6 and is in active discussion. Currently, it satisfies no one. Like the introduction, we will revisit and finalize once the document is more complete.

While there are a variety of business models to monetize content on the web, many rely on advertising. Advertisements can be targeted to a particular user's interests based on information gathered about one's online activity. While the Internet industry believes many users appreciate such targeted advertising, as well as other personalized content, there is also an understanding that some people find the practice intrusive. If this opinion becomes widespread, it could undermine the trust necessary to conduct business on the Internet. This Compliance specification and a companion [[!TRACKING-DNT]] specification are intended to give users a means to indicate their tracking preference and to spell out the obligations of compliant websites that receive the Do Not Track message. The goal is to provide the user with choice, while allowing practices necessary for a smoothly functioning Internet. This should be a win-win for business and consumers alike. The Internet brings millions of users and web sites together in a vibrant and rich ecosystem. As the sophistication of the Internet has grown, so too has its complexity which leaves all but the most technically savvy unable to deeply understand how web sites collect and use data about their online interactions. While on the surface many web sites may appear to be served by a single entity, in fact, many web sites are an assembly of multiple parties coming together to power a user's online experience. As an additional privacy tool, this specification provides both the technical and compliance guidelines to enable the online ecosystem to further empower users with the ability to communicate a tracking preferences to a web site and its partners.

The accompanying TRACKING-DNT recommendation explains how a user, through a user agent, can clearly express a desire not to be tracked. This Tracking Compliance and Scope recommendation sets the standard for the obligations of a website that receives such a DNT message.

Taken together these two standards should have four substantial outcomes:

  1. Empower users to manage their preference around the collection and correlation of data about Internet activities that occur on different sites and spell out the obligations of sites in honoring those preferences when DNT is enabled.
  2. Provide an exceedingly straightforward way for users to gain transparency and control over data usage and the personalization of content and advertising on the web.
  3. Enable a vibrant Internet to continue to flourish economically by supporting innovative business models while protecting users' privacy.
  4. Establish compliance metrics for operators of online services

This standard has limited applicability to any practices by first parties, their service providers, subsidiaries, or affiliated companies. Under the standard, first parties may and will continue to collect and use data for tracking and other purposes. This standard is primarily directed at third parties.

This solution is intended to be persistent, technology neutral, and reversible by the user. It aims to preserve a vibrant online ecosystem, privacy-preserving secondary data uses necessary to ecommerce, and adequate security measures. We seek a solution that is persistent, technology neutral, and [something that speaks with the ability to opt back in], but that preserves a vibrant online ecosystem, privacy-preserving secondary data uses, and adequate security measures.

Definitions

User

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.

User Agent

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.

Party

Option 1

A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person which acts as a functional entity. A set of functional entities is considered affiliated when they are related by both common majority ownership and common control, and affiliation is made easily discoverable by a user.

Option 2

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 (Affiliates) and MUST provide “easy discoverability” of affiliate organizations. An “Affiliate List” MUST be provided within one click from each page or the entity owner clearly identified within one click from each page.

A website with a clear labeled link to the Affiliate List within the privacy policy would meet this requirement or the ownership brand clearly labeled on the privacy policy itself and may choose to act as a single party.

Service Providers/Outsourcers

We seem to have general consensus in theory but not in language for the definition of a service provider. However, the three options below different significantly in how prescriptive and demanding the test to qualify as a service provider should be.

Option 1: Service Provider/Outsourcer Definition

This option contains both definitions and normative compliance requirements.

This section applies to parties engaging in an outsourcing relationship, wherein one party "stands in the shoes" of another party to perform a specific task. Both parties have responsibilities, as detailed below.

A first party or a third party MAY outsource functionality to another party, in which case the third party may act as the original first party or third party under this standard, with the following additional restrictions:

  • Data collected by each outsourced company is separated for each party they collect data for by both technical means and organizational process, AND
  • The outsourced company has no independent rights to the collected information, AND
  • A contractual relationship exists between the outsourced and the party they collect data for that outlines and mandates these requirements.

An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)

Non-Normative

Outsourced companies that act purely as vendors for their customers (often first parties in this context) are not the intended target for the Tracking Preference Expression but it is important there are no unintended activities that are extended to another party through this allowance. In all cases, its expected an outsourced company acting on the part of a customer follows all of the same restrictions placed on that customer.

For the data separation requirement, outsourced companies have technical options to achieve appropriate separation but in each the critical element is that data is never reconstituted for users that have indicated a preference not to be tracked. One possible approach would be to leverage a per partner hash against a common cookie identifier, ensuring the resulting identifier is consistent for a specific customer, but is unable to be linked with another customer’s identifier.

Contractual requirements that enforce data rights and responsibilities for separation are a critical element of establishing an outsourcer acting on another party’s behalf. Contracts may occur directly through parties (for example, a Publisher in an Ad Network) or between intermediaries (for example, an Ad Network acting through an Ad Exchange). In either case, data separation and removal of independent rights are necessary elements that must survive intermediary contractual constructs.

Technical Precautions

Throughout all data collection, retention, and use, outsourced parties MUST use all feasible technical precautions to both mitigate the identifiability of and prevent the identification of data from different first parties.

Structural separation ("siloing") of data per first party, including both

  1. separate data structures and
  2. avoidance of shared unique identifiers

are necessary, but not necessarily sufficient, technical precautions.

Explanations of some techniques that may satisfy these requirements are documented in the Technical Precautions section of the appendix.

Internal Practices

Throughout all data collection, retention, and use, outsourced parties MUST use sufficient internal practices to prevent the identification of data from different parties.

Explanations of some techniques that may satisfy these requirements are documented in the Internal Practices section of the appendix.

Use Direction

An outsourced service:

  1. MUST use data retained on behalf of a party ONLY on behalf of that party, and
  2. MUST NOT use data retained on behalf of a party for their own business purposes, or for any other reasons.

First Party or Third Party Requirements

Representation

A party's representation that it is in compliance with this standard includes a representation that its outsourcing parties comply with this standard.

Contract

A First party or Third party MUST enter into a contract with an outsourced party that requires that outsourced party to comply with these requirements.

Option 2: Service Provider/Outsourcer Definition

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.

Option 3: Service Provider/Outsourcer Definition

Service Providers acting on the behalf of a First party or Third party, and with no independent rights to use that party’s data outside of the context of that party and Permitted Uses, are also considered to be acting as that party.

First and Third Parties

Option 1: First and Third Parties

Definitions

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.

Discussion

Overview

We draw a distinction between those parties an ordinary user would or would not expect to share information with, "first parties" and "third parties" respectively. The delineation exists for three reasons.

First, when a user expects to share information with a party, she can often exercise control over the information flow. Take, for example, Example Social, a popular social network. The user may decide she does not like Example Social's privacy or security practices, so she does not visit examplesocial.com. But if Example Social provides a social sharing widget embedded in another website, the user may be unaware she is giving information to Example Social and unable to exercise control over the information flow.

Second, we recognize that market pressures are an important factor in encouraging good privacy and security practices. If users do not expect that they will share information with an organization, it is unlikely to experience market pressure from users to protect the security and privacy of their information. In practice, moreover, third parties may not experience sufficient market pressure from first parties since increasingly third parties do not have a direct business relationship with the first party websites they appear on. We therefore require a greater degree of user control over information sharing with such organizations.

Last, third parties are often in a position to collect a sizeable proportion of a user's browsing history – information that can be uniquely sensitive and easily associated with a user's identity. We wish to provide user control over such information flows.

We recognize that, unlike with a bright-line rule, there can be close calls in applying our standard for what constitutes a first party or a third party. But we believe that in practice, such close calls will be rare. The overwhelming majority of content on the web can be classified as first party or third party, with few cases of ambiguity in practice.

We require a confidence at a "high probability" before a party can consider itself a first party. Where there is reasonable ambiguity about whether a user has intentionally interacted with a party, it must consider itself a third party. Our rationale is that, in the rare close cases, a website is in the best position to understand its users' expectations. We therefore impose the burden of understanding user expectations on the website. We also wish, in close cases, to err on the side of conforming to user expectations and protecting user privacy. If the standard is insufficiently protective, ordinary users have limited recourse; if the standard imposes excessive limits, websites retain the safety valve of explicitly asking for user permission.

In some cases, web requests are redirected through intermediary domains, such as url shorteners or framing pages, before eventually delivering the content that the user was attempting to access. The operators of these intermediary domains are third parties, unless they are a common party to the operator of either the referring page or the eventual landing page.

Examples

  1. A user accesses an Example News article. The page includes an advertisement slot, which loads content from many companies other than Example News. Those companies are third parties.
  2. A user accesses an Example News article. The page includes an analytics script that is hosted by Example Analytics, an analytics service. Example Analytics is a third party.
  3. A user accesses an Example News article. It includes a social sharing widget from Example Social, a popular social network. Example Social is a third party.
  4. A user visits Example Diary, which is hosted by the free blogging service Example Blog Hosting but located at examplediary.com. Example Blog Hosting is a third party.
  5. A user launches Example Application, an app on a mobile device. The app includes a library from Example Advertising Network that displays ads. Example Advertising Network is a third party.
  6. A user visits Example Social and sees the language: "Check out this Example News article on cooking: sho.rt/1234". The user clicks the link which directs the user to a page operated by the company Example Sho.rt which then redirects the user to a page operated by Example News. Example Social and Example News and first parties, and Example Sho.rt is a third party.
  7. A user visits Example Social and sees a hyperlink reading: "Check out this Example News article on cooking." A user clicks the link which points to framing.com/news1234. This page loads nothing but a frame which contains the cooking article from Example News, but all links are rewritten to pass through framing.com which is operated by Example Framing. Example Social and Example News are first parties and Example Framing is a third party.

Multiple First Parties

There has been some disagreement within the group over how many first parties there should be in any one network interaction. These three options lay out the range of possibilities; the first is text that has been before the group for some time, the others are new.

There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.

There can be only one first party in any network transaction absent additional meaningful interaction with otherwise third party content on the webpage. The first party is the registrant and operator of the domain that the user intentionally communicated with.

If a user intends to communicate with a party that utilizes a different party as a platform, then both parties are first parties in the network transaction.

Example: ExampleSports franchise has a dedicated page on a ExampleSocial. When a user visits this dedicated page, both ExampleSports and ExampleSocial are first parties.

User Interaction with Third-Party Content

A party may start out as a third party but become a first party later on, after a user interacts with it. If content from a third party is embedded on a first party page, the third party may become an additional first party if it can infer with high probability that the average user knowingly and intentionally communicated with it. If a user merely moused over, closed, or muted third-party content, the party would not be able to draw such an inference.

Examples

  1. Example Weather offers an unbranded weather widget that is embedded into websites, including Example News. The widget contains small links to Example Weather's website and privacy policy. A user visits Example News and scrolls through the weekly forecast in the Example Weather widget. Example Weather is a third party. The user has interacted with Example Weather's widget, but an ordinary user would not expect that scrolling through the widget involves communicating with Example Weather.
  2. Example Social, a popular social network, hosts a social sharing button that other websites can embed. The button is colored and styled in the same fashion as Example Social's website, contains descriptive text that is specific to Example Social, includes Example Social's logo, and very frequently appears on Example Social's website. Example News embeds the Example Social button, and a user clicks it. Example Social is a first party once the user clicks its embedded social sharing button. The average user would understand that by clicking the button she is communicating with Example Social.
Option 2: First and Third Parties

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).

Unlinkable Data

There is debate about whether to use the terms unlinkable, unlinked, or unidentified to describe this type of data.

Option 1: Unlinkable Data

A party render a dataset unlinkable when it
1. takes commercially reasonable steps have been taken to de-identify data such that there is confidence that it contains information which could not be linked to a specific user, user agent, or device in a production environment
2. publicly commits to retain and use the data in unlinkable fashion, and not to attempt to re-identify the data
3. contracually prohibits any third party that it transmits the unlinkable data to from attempting to re-identify the data. Parties SHOULD provide transparency to their delinking process (to the extent that it will not provided confidential details into security practices) so external experts and auditors can assess if the steps are reasonably given the particular data set.

Option 2: Unlinkable Data

A dataset is unlinkable when there is a high probability that it contains only information that could not be linked to a particular user, user agents, or device by a skilled analyst. A party renders a dataset unlinkable when either:
1. it publicly publishes information that is sufficiently detailed for a skilled analyst to evaluate the implementation, or
2. ensure that the dataset is at least 1024-unlinkable.

Network Transaction

A "network interaction" is an HTTP request and response, or any other sequence of logically related network traffic.

Non-normative explanatory text: Determination of a party's status is limited to a single interaction because a party's status may be affected by time, context, or any other factor that influences user expectations.

Data collection, retention, use, and sharing

These continue to be actively debated issues, as the resolution of the use of unique identifiers is likely to end up in these definitions.

  1. A party "collects" data if the data comes within its control.
  2. A party "retains" data if data remains within a party's control beyond the scope of the current interaction.
  3. A party "uses" data if the party processes the data for any purpose other than storage or merely forwarding it to another party.
  4. A party "shares" data if the party enables another party to receive or access that data.

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.

Exception for unknowing collection, retention, and use

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.

Tracking

The term "tracking" is not used in the document. This section is likely to be deleted, and the issues will be addressed in the definitions of "collection" and "unlinkable" above.

Option 1: Non-first Party Identifiers

Concerns with this section include undefined term "user data" plus as written, this may apply more broadly than the authors intended

Tracking is the collection or use of user data via either a unique identifier or a correlated set of data points being used to approximate a unique identifier, in a context other than "first party" as defined in this document. This includes:

  1. a party collecting data across multiple websites, even if it is a first party in one or more (but not all) of the multiple contexts
  2. a third party collecting data on a given website
  3. a first party sharing user data collected from a DNT:1 user with third parties "after the fact".

Examples of tracking use cases include:

  1. personalized advertising
  2. cross-site analytics or market research that has not been de-identified
  3. automatic preference sharing by social applications

Option 2: Cross-site or Over Time

Tracking is defined as following or identifying a user, user agent, or device across multiple visits to a site (time) or across multiple sites (space).

Mechanisms for performing tracking include but are not limited to:

  1. assigning a unique identifier to the user, user agent, or device such that it will be conveyed back to the server on future visits;
  2. personalizing references or referral information such that they will convey the user, user agent, or device identity to other sites;
  3. correlating data provided in the request with identifying data collected from past requests or obtained from a third party; or,
  4. combining data provided in the request with de-identified data collected or obtained from past requests in order to re-identify that data or otherwise associate it with the user, user agent, or device.

A preference of "Do Not Track" means that the user does not want tracking to be engaged for this request, including any mechanism for performing tracking, any use of data retained from prior tracking, and any retention or sharing of data from this request for the purpose of future tracking, beyond what is necessary to enable:

  1. the limited permitted uses defined in this specification;
  2. the first-party (and third-parties acting as the first-party) to provide the service intentionally requested by the user; and
  3. other services for which the user has provided prior, specific, and informed consent.

Option 3: Silence

One proposal is not to define "tracking," but rather to list what is, or is not, required and allowed in order to comply with the recommendation.

First Party Compliance

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 Recommendation.

User Agent Compliance

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

Third Party Compliance

This section addresses the crux of what DNT is intended to accomplish, and as such, all of this section remains hotly debated. The specific language is likely to change. See also alternative text proposed by Nick Doty.

If a third party receives a communication to which a DNT:1 header is attached:

  1. that third party MUST NOT collect, share, or use information related to that communication outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;
  2. that third party MUST NOT use information about previous communications in which it was a third party, outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;
  3. that third party MAY delete information about previous communications in which it was a third party.

Permitted Operational Uses for Third Parties and Service Providers

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.

Global Requirements for Permitted Uses

In order to use the Permitted Uses outlined below, a party MUST comply with these four requirements.

No Secondary Uses

Third Parties MUST NOT use data retained for permitted uses for non-permitted uses.

Data Minimization and Transparency

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. Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained. A third party MUST provide public transparency of their data retention period. The third party MAY enumerate each individually if they vary across Permitted Uses. Once the period of time for which you have declared data retention for a given use has expired, the data MUST NOT be used for that permitted use. After there are no remaining Permitted Uses for given data, the data must be deleted or rendered unlinkable.

Jonathan Mayer to provide non-normative examples per ACTION-298.

Reasonable Security

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.

Whether or not an audit, or the type of audit, is mandated is still in discussion; an optional field exists in the TPE spec for auditors and self-regulatory commitments. The audit section of the TPE should be cross-referenced here.

No Personalization

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.

No Persistent Identifiers

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).

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.

Enumerated Permitted Uses

Short Term Collection and Use

We have discussed allowing a N-week (anywhere from 1 week to 3 months) grace period where third parties could collect and use data, partly due to concerns , partly as a compromise to the market research/aggregate reporting issue. We do not have consensus on this permitted use at this point. If we decide to allow this, we would need to add non-normative text explaining the rationale and providing examples.

Information may be collected 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).

Contextual Content or Ad Delivery

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).

Regardless of DNT signal, 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.

Examples
  1. A user visits ExampleSports.com with DNT:1 enabled to read a news article about a baseball game. ExampleSports uses the third party ExampleAds to serve ads on ExampleSports.com. ExampleAds is not an outsourcing partner of ExampleSports, and often uses third-party behavioral data to serve targeted ads to users who have not enabled DNT:1. ExampleAds may collect and use information about the user in order to render an advertisement (including IP address and information about the user agent) and information about the url of the news article in order to render an advertisement related to the baseball game.
  2. A user visits ExampleLocalNews.com with DNT:1 enabled to read a news article about a local fire. ExampleLocalNews uses the third party ExampleWeather to display a weather widget on its site. ExampleWeather is not an outsourcing partner of ExampleLocalNews. ExampleWeather may collect and user information about the user in order to render the weather widget (including IP address and information about the user agent) and information about the domain of the news site in order to render weather information related to the city which ExampleLocalNews reports on.
Content or Ad Delivery Based on First Party Data

Regardless of DNT signal, 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 will 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. 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.

Examples
  1. A user visits ExampleNews.com with DNT:1 enabled to read a story about a national election. ExampleNews uses the third party ExamplePortal to serve content and advertisements on its site. ExamplePortal is not an outsourcing partner of ExampleNews. The user had previously visited ExamplePortal.com with DNT:1 enabled and read several stories about golf. ExamplePortal may serve an advertisement related to golf to that same user on ExampleNews. However, ExamplePortal may not use the fact that user went to ExampleNews to add to the user's ExamplePortal profile, and may only retain and use information about that fact for a permitted operational use.
  2. A user visits Example Music with DNT:1 enabled to listen to recently released albums streamed online. Example Music uses the third party Example Social to provide a widget that shows users what their Example Social friends have done on ExampleMusic. ExampleSocial is not an outsourcing partner of ExampleMusic. The user is a member of ExampleSocial and has several friends who also share information about what they do on ExampleMusic on ExampleSocial. ExampleSocial may display information that the users' friends had shared on ExampleSocial related to ExampleMusic within its third-party widget on ExampleMusic. However, ExampleSocial may not use the fact that user went to ExampleMusic to add to the user's ExampleSocial profile, and may only retain and use information about that fact for a permitted operational use.
Frequency Capping

Regardless of DNT signal, 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.

Examples

A user visits ExampleNews with DNT:1 enabled. ExampleNews uses the third party ExampleAds to serve content and advertisements on its site. ExampleAds is not an outsourcing partner of ExampleNews. ExampleAds has previously shown the user an ad for ExampleCars five times in the past week on other sites. ExampleCars' contract with Example Ads states that Example Ads will be paid less for impressions where the user sees an ad more than five times in a week. ExampleAds may opt not to show the user the ad for ExampleCars because the user has already seen the ad five times on other sites.

Financial Logging and Auditing

Regardless of DNT signal, information may be collected, retained and used for financial fulfillment purposes such as billing and audit compliance. This includes counting and verifying:

  • ad impressions to unique visitors
  • clicks by unique visitors
  • subsequent action or conversion by unique visitors
  • quality measures such as ad position on sites and the sites on which the ads were served

One potential 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.

Examples

Add examples for display verification, click verification, CPA, quality measures

Security and Fraud Prevention

To the extent reasonably necessary for detecting security risks and fraudulent or malicious activity, parties may collect, retain, and use data regardless of a DNT signal. 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.

There is an open action to define "graduated response," and an open question of whether "graduated response" should be in the normative text, or addressed through non-normative examples.

Examples

Add examples with and without outsourced parties (J- not sure what this means)

Debugging

Regardless of DNT signal, information may be collected, retained and used for identifying and repairing errors that impair existing intended functionality.

Discussion

Detailed information is often necessary to replicate a specific user's experience to understand why their particular set of variables is resulting in a failure of expected functionality or presentation. These variables could include items such as cookie IDs, page URLs, device or UA details, content specifics, and activity/event specifics to narrow in on the cause of the discrepancy.

Examples

A user visits ExampleBlog with DNT:1 enabled. Example News uses the third party ExampleAds to serve content and advertisements on its site. ExampleAds is not an outsourcing partner of ExampleBlog. ExampleAds retains [to be determined data fields] in order to later replicate users' experiences in receiving its ads to subsequently diagnose problems and understand why their particular set of variables resulted in a failure of expected functionality or presentation.

Compliance With Local Laws and Public Purposes

The group has generally agreed that companies can collect and process data as required by local law despite the DNT:1 signal and still comply with this standard. We have also conceptually agreed that companies cannot exploit this language by creating contractual requirements between companies to collect data as a "legally required" basis for the collection and use of data despite a DNT:1 signal.

Regardless of DNT signal, information may be collected, retained and used for complying with local laws and public purposes, such as copyright protection and delivery of emergency services.

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.

Geolocation compliance by a third party

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:

  1. Geo-location information that is more granular than postal code is too granular. Geolocation data must not be used at any level more granular than postal code. Note that while the number of people living in a postal code varies from country to country, postal codes are extant world-wide.
  2. If specific consent has been granted for the use of more granular location data, than that consent prevails.

Discussion

It is acceptable to use data sent as part of this particular network interaction when composing a response to a DNT:1 request, but it is not acceptable to store that data any longer than needed to reply. For instance, it would be appropriate to use an IP address to guess which country a user is in, to avoid showing them an advertisement for products or services unavailable where they live.

When using request-specific information to compose a reply, some levels of detail may feel invasive to users, and may violate their expectations about Do Not Track. These sorts of detailed assessments should be avoided.

Examples

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.

User-Granted Exceptions

First and third paragraphs added per ACTION-251. Needs edits for fluency.

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.

Interaction with existing user privacy controls

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.

  1. No DNT Signal / No Opt-Out: Treat as DNT unset
  2. DNT Signal / No Opt-Out: Treat as DNT:1
  3. Opt-Out / No DNT Signal: Treat as DNT:1
  4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; DNT User-Granted Exception is honored

Disregarding Non-Compliant User Agents

this section is the topic of active debate.

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.

No provision on Disregarding Non-Compliant User Agents.

Public Disclosure of Compliance

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.

Third Party Auditing

Tracking Status Qualifiers may include a value to indicate auditing.

Privacy Preserving Techniques

Technical Precautions

Siloing in the Browser

Outsourcing services should use browser access control features so that stored data specific to one party is never accessed or collected when the user visits another party.

Same-Origin Policy

The same-origin policy silos stored data by domain name. An outsourcing service can use a different domain name for each first party.

              Example Analytics provides an outsourced analytics service to Example News
              and Example Sports, two unrelated websites. Example Analytics stores its
              cookies for Example News at examplenews.exampleanalytics.com, and it
              stores its cookies for Example Sports at
              examplesports.exampleanalytics.com.
      

Cookie Path Attribute

The HTTP cookie path can be used to silo data to a first party.

              Example Analytics stores its cookies for Example News with
              "Path=/examplenews", and it stores its cookies for Example Sports with
              "Path=/examplesports".  
      

Storage Key

For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.

              Example Analytics stores data for Example News at
              window.localStorage["examplenews"] and data for Example Sports at
              window.localStorage["examplesports"].
      

Siloing in the Backend

Encryption Keys

An outsourcing service should encrypt each first party's data with a different set of keys.

Access Controls

An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.

Access Monitoring

An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.

Retention in the Backend

An outsourcing service should retain information only so long as necessary to provide necessary functionality to a first party. If a service creates periodic reports, for example, it should delete the data used for a report once it is generated. An outsourcing service should be particularly sensitive to retaining protocol logs, since they may allow correlating user activity across multiple first parties.

Internal Practices

Policy

An outsourcing service should establish a clear internal policy that gives guidance on how to collect, retain, and use outsourced data in compliance with this standard.

Training

Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.

Supervision and Reporting

An outsourcing service should establish a supervision and reporting structure for detecting improper access.

Auditing

External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices. Auditor reports should be made available to the public.

Acknowledgements

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.