This partial draft attempts to reflect some of the points of consensus across multiple proposals presented at the Washington, DC f2f meeting, including issue-10 (what is a first party), issue-17 (data use by a first party), issue-19 (data collection and use by a third party), issue-31 (data minimization), issue-49 (third party on behalf of first party), and issue-73 (silo v. contract for outsourcing partner). It does not get into the disputed areas of issue-22 (operational use), issue-24 (fraud exemption), issue-25 (research exemption).

If you remember the eight page poster on the wall with only two points of major disagreement in DC, this draft tries to capture the parts where we basically agreed. The idea is to have a format we can now go through and tweak and fix, then hand off to the Compliance editors to integrate into a public draft. Our next step is to see where we have consensus on these issues, where we are still working out wording, and where there are differences. Please review this text carefully prior to discussions during the Seattle f2f.

Much of the text comes from two proposals, one from Jonathan / Peter / Tom, the other from Shane et. al. Extraordinarily little text is actually new. The structure is different, with definitions pulled to the beginning and a simplified hierarchy.


A functional entity is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.

Functional entities are affiliated when they are related by both common majority ownership and common control.

A party is a set of functional entities that are affiliated and follow requirements to be easily discoverable.

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

An outsourced party is any party, in a specific network interaction, that is working on behalf of a specific first or third party in compliance with the outsourced party information practices.

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, and complies with DNT under first party information practices.

A third party is any party in a specific network interaction that is not a first party, an outsourced party, or the user. A party without the ability to infer with high probability that the user knowingly and intentionally communicated with it MUST represent itself as a third party and comply with third party information practices. A first party MAY choose to represent itself as a third party and comply with third party information practices.

A dataset is unidentifiable when there is a high probability that it contains only information which could not be linked to a particular user, user agent, or device by a skilled analyst. N-unlinkability is the special case of K-anonymity where all values are considered part of the pseudo-identifier.

Protocol information includes:

Protocol information does not include:

A party collects data if the data comes within its control and the control of that data is not transient.

Open action on defining collection; this is not done

A party retains data if the data remains within the party's control.

A party uses data if the party processes the data for any purpose, including for storage.

A party shares data if the party enables another party to collect the data.

Information Practices for All Parties

This section of the specification applies to all parties who comply with an incoming DNT signal. See the companion [[!TRACKING-DNT]] document for information on how to respond to an incoming signal.

Additional Voluntary Measures

This specification sets a minimum common standard for compliance. Any party MAY take additional steps to protect user privacy when responding to a Do Not Track request.

User Permission and Consent

We have discussed this at length in action-152, action-157, and action-159. This section attempts to merge several texts together.

A party MAY engage in information practices otherwise prohibited by this recommendation if it has received explicit, informed consent from the user to do so, a user-granted exception. When seeking a user-granted exception, sites SHOULD communicate those requests clearly, accurately, and in line with applicable law. Permission may be attained through either (A) receiving a DNT:0 signal, (B) the browser API defined in the companion [[!TRACKING-DNT]] document or (C) consent attained "out-of-band". An "out-of-band" consent mechanism has the same effect under this standard as the browser exception API.

Still to be addressed, DNT permission if consent from before (via Terms of Service or other) applies. ISSUE?

Possible texts to introduce the following paragraph:
  • a party may receive multiple conflicting signals from users.
  • out-of-band consent overrides an expressed dnt signal.
  • a party may engage [per above].

If a party has received prior consent for tracking a given user, user agent, or device, that consent overrides the general preference indicated by the DNT header. If a party chooses to track based on that prior consent, the party MUST indicate that status, as described in [[!TRACKING-DNT]]. For example, if you have two conflicting signals from a user with a global DNT:1 yet also have the user's consent specific to you (via browser API or out-of-band consent) then the user's consent is the correct signal to follow.

An "out-of-band" choice mechanism MUST additionally satisfy the following condition: A reasonable user would know that the choice overrides his or her general Tracking Preference.


Many organizations have developed direct consent mechanisms for web-wide tracking prior to this standard. Interactions with users to obtain consent may be contextual. For example, if a service has an obvious cross-site tracking function that the user deliberately signs up for then this could be deemed to have achieved “explicit and informed” consent from a user without directly addressing its relation to a Tracking Preference (which wasn’t contemplated at the time the consent experience was designed). Even in these cases, organizations should recall that users with DNT:1 are requesting privacy, and strongly consider providing Tracking Preference references in associated product or service materials such as a privacy policy, help center, or a separate notice to users who have indicated preferences for privacy. Organizations should also scope the user's consent to the task the user is likely to understand. For example, a user who signed up for a news tracking service that would note which articles he or she read across the entire web in order to suggest relevant articles in the future might consider just using the service as sufficient contextual consent for gathering information about news. However, that does not mean the user has also consented to that information being used in any other context or by other parties. Contextual consent is specific to a product or feature, as understood by the user.

Companies should not seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or their Privacy Center if it will not be obvious to users that the nature of the service will lead the company to ignore a user’s Tracking Preference based on the nature of the consent the user is granting. As an example where context would be insufficient to establish consent, a company could not obtain explicit, informed consent to ignore DNT in third-party settings by placing notice in a privacy policy or the terms of use for an email service or a game if that company also happens to own an advertising network. The company would need to present users with a request for consent. It is a good practice to present a choice that signing up for a service will override a Tracking Preference setting, or the option to decline the service, at the time the user's choice is being made. The W3C geolocation API is one example of out-of-band consent, which we discuss in the section on geolocation.

Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences. This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally present options to alter that consent if the user chooses to do so.

We suggest the following properties for any out-of-band consent mechanism:

Actual presentation
The choice mechanism must be actually presented to the user. It must not only be on a linked page, such as a terms of service or privacy policy.
Clear terms
The choice mechanism must use clear, non-confusing terminology.
Independent choice
The choice mechanism must be presented independent of other choices. It must not be bundled with other user preferences.
No default permission
The choice mechanism must not have the user permission preference selected by default.

What constitutes explicit consent is not necessarily the same across all legal jurisdictions. It is the site's responsibility to ensure that it has consent.

Unidentifiable Data

Any party MAY collect, retain, or use unidentifiable data, subject to the requirements that the party MUST either:

  1. publicly publish information that is sufficiently detailed for a skilled analyst to evaluate the implementation, or
  2. ensure that any datasets are at least 1024-unlinkable.

Unidentifiable information will either be unidentifiable at the time of collection, or be made unidentifiable by aggregating data after it is collected; both are described below.

Information That Is Unidentifiable When Collected

A party may collect non-protocol information if it is, independent of protocol information, unidentifiable data. The data may be retained and used subject to the same limitations as protocol information.

	Example Advertising sets a language preference cookie that stores one of a 
	few values, such as us, de, and so on, and thousands of users share the 
	same language preference.

Information That Is Unidentifiable After Aggregation

If we do not adopt the notion of a grace period for log files, then this section applies only to parties that know they are always first parties. For everyone else, the only form of permitted aggregation will be at the point of collection as things are currently written.

During the period in which a party may use protocol information prior to processing, it may aggregate protocol information and unidentifiable data into an unidentifiable dataset. Such a dataset may be retained indefinitely and used for any purpose.

	Example Advertising maintains a dataset of how many times per week 
	Italy-based users load an ad on Example News.


It would be helpful to describe what 1024-unlinkable means so we do not send implementers scrambling for other texts. Also useful, a discussion that this can be either calculated mathematically (with a pointer to a readable reference) or by estimating based on actual data, perhaps with non-DNT users or pre-DNT users.


While there is disagreement over whether discoverability is sufficient, we do seem to be converging on what discoverability is. Should we decide discoverability is not helpful, or insufficient, we can easily remove this section.

A functional entity must make its affiliated functional entities easily discoverable by a user.

Non-Normative Discussion

Affiliation may be made easily discoverable by a user in many ways, including but not limited to: prominent and common branding on pages, one click away within a privacy policy, or a machine-readable format in a well-known location. As a general guideline: if a lawsuit could be brought against two different entities, they are not the same functional entity. Similarly, if two portions of a legal entity have different privacy policies, they should not be considered the same functional entity under Do Not Track.

Additional Requirements Based on Party Status

In addition to the information practices for all parties as described in this section, for each network interaction an additional set of information practices applies based on which type of party you are during that network interaction: first party, outsourced party, or third party.

Non-Normative Discussion

Determination of a party's status is limited to a single transaction because a party's status may be affected by time, context, or any other factor that influences user expectations. Other than some third parties becoming first parties when users interact (for example, social widgets or ads,) party status will usually stay stable for the entire interaction with a given user.

Information Practices for First Parties

This section of the document applies just to first parties.

A first party MUST NOT share information with a third party that the third party is prohibited from collecting itself. A first party MUST NOT share (send or collect) identifiable information about a user to any party it does not have an outsource relationship with. [reference to "outsource" definition]

strawman: A first party MUST NOT share identifiable information about a user with any party with which it does not have an outsource relationship.
core purpose: to prevent a first party as a loophole?

While confining data just to the first party reflects discussions of the TPWG to date, newer members have concerns about these provisions.

Non-Normative Discussion


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

Common Examples and Use Cases

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

Multiple First Parties

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

Information Practices for Third Parties

This section of the document applies just to third parties.

General Rule

A third party may not collect, retain, use, or share any information related to communication with a user or user agent. There are exceptions to this general rule as defined in the following sections.

Permitted Uses

We recognize a limited set of data uses as important enough to continue even with data in potentially identifiable form. For all other uses, many of which are quite valuable, sites can ask users for permission. Note that first parties are not constrained to permitted uses. Outsourced parties may act as the party they work with would act: if working with a third party, they are also bound to this list of permitted uses.

While we agree on this general structure, we do not agree on uses at this point.

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 and Use Cases

Example: 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.

Discussion: 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 News.

Example: 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.

Discussion: 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.

Information Practices for Outsourcing

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:

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


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.

Non-Normative Discussion

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, and it
	stores its cookies for Example Sports at

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

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

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

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

Non-Normative Discussion


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.


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.


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.

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


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


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