Tracking Compliance and Scope

Abstract

This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.

3. Definitions

The Definitions section of this document is in a high state of flux as of this draft and contains a large number of controversial text proposals and open issues for the working group. None of these definitions should be considered definitive or final.

The term exemption is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference. The term exception is used when the user has permitted tracking, usually in the form of a site-specific exception, for a given third-party. In general: exemptions are additional permissions granted by the standard; exceptions are additional permissions granted by the user. These words are often confused when drafting new text.

3.1 Drafting Notes

ISSUE-97 : A special rule for URL-shortening services remains an open issue and is not addressed in the proposal put forward in 3.2 through 3.4.

ISSUE-26 : Providing data to 3rd-party widgets &emdash; does that imply consent?

The proposal put forward here does not provided a special rule for widgets. The same first party vs. third party test for static content applies.

3.2 Parties

3.2.1 Option 1: User Expectations

3.2.1.1 Definition

A "party" is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person, that an ordinary user would perceive to be a discrete entity for purposes of information collection and sharing. Domain names, branding, and corporate ownership may contribute to, but are not necessarily determinative of, user perceptions of whether two parties are distinct.

3.2.1.2 Non-Normative Discussion

Our definition of what constitutes a "party" is guided by ordinary user expectations. We decline to adopt a conflicting approach that would draw a line at domain names, corporate affiliation, or branding, as discussed below.

3.2.1.2.1 Domain Names

In an uncomplicated world, a party might be delineated by domain boundaries. In practice, however, the domain approach can emphasize differences that would not matter to ordinary users and would be restrictive for many business uses. Suppose Example Company hosts dynamic content on example.com and static images on example-static.com. An average user would understand both domains are operated by Example Company, but a domain name distinction would say the two domains are different parties. Using domain names to differentiate parties would also impose an unnecessary choice on large websites of either hosting all their content on a single domain or having some of their content considered third party. By adopting a user expectations standard, we allow a single website to span multiple domains.

A domain name approach can also gloss over relevant differences from a user expectations perspective. Suppose Example Company hires an analytics company and aliases the domain analytics.example.com to the analytics company's website. By user expectations, and corporate affiliation and branding, the analytics company would be a separate party. Moreover, circumventing the limits imposed by this standard would require nothing more than switching domain names. The user expectations standard we adopt recognizes that multiple parties may exist at a single domain.

3.2.1.2.2 Corporate Affiliation

Corporate families can consist of businesses in completely unrelated industries; users may have limited understanding of how businesses are related by corporate ownership or control. Moreover, by creating affiliates for the purposes of data sharing, organizations could circumvent the limits imposed by this standard. Under the user expectations standards we adopt, a corporate affiliate is not, in general, the same party as an organization.

3.2.1.2.3 Branding

In many cases, branding aligns with ordinary user expectations. Unrelated websites rarely share branding. In company ownership scenarios, prominent language like "Brand A, provided by Company B" may be sufficient for the average user to understand that Brand A is owned by Company B and information shared with Brand A may also be shared with Company B.

But, in some cases, branding does not align with user expectations. Suppose Example Search owns a video sharing website, Example Video. Most users are aware that Example Video is a subsidiary of Example Search, and that the Example Video website differs from the Example Search website for historical reasons. The Example Video home page does not, however, include any branding reference to Example Search. Under a branding test, Example Search and Example Branding would be different parties. The user expectations test allows for factors, other than branding, that influence user understanding.

Branding may also fall short in informing user expectations. If most users have never heard of Company B, language like "Brand A, provided by Company B" may not be adequate for the average user to understand the relationship between Brand A and Company B. A user expectations test recognizes there may be instances where even conspicuous branding is inadequate to inform users.

3.2.2 Option 2: Discoverable Affiliates

3.2.2.1 Normative 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 standard, those entities must be commonly owned and commonly controlled, and must make their parent affiliation (if any) easy discoverable to users.

3.2.2.2 Non-Normative Discussion

This may be accomplished in many ways, including but not limited to, prominent and common branding on site pages, "one click away" within Privacy Policies, and, if available, a programmatic list of domains that share common ownership (affiliation).

3.3 First Parties and Third Parties

3.3.1 Option 1: Meaningful User Interaction

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

Some participants are concerned this proposal is not implementable as-is.

3.3.1.2 Non-Normative Discussion

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

3.3.1.2.1.1 Common Examples and Use Cases

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

3.3.1.2.2 Multiple First Parties

While this is not closed the idea there may be multiple first parties on one webpage based on meaningful interaction has little controversy, with some discussion around the margins about details of co-run sites.

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.

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

3.3.1.2.3.1 Examples and Use Cases

Little controversy, with some discussion of adding examples of co-run sites unresolved by publication. Some think branding covers this case; others want to add an additional example: A user visits a contest website hosted by two parties (clearly branded): Company X and Company Y. The page includes links to both parties legal information (Privacy Policy, Terms of Service) with explanation that both parties are first parties on this website.

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.

3.3.2 Option 2: Discoverable Ownership and Affiliates

This language merely rehashes the discoverable affiliate definition of "party" and does not provide guidance as to when a party is operating on a first-party or third-party basis. This language would be better incorporated as non-normative discussion under the Option 2: Discoverable Affiliates definition of party above.

3.3.2.1 Definitions

A First Party is the entity that owns the Web site or has Control over the Web site the consumer visits. A First Party also includes the owner of a widget, search box or similar service with which a consumer interacts, even if such First Party does not own or have Control over the Web site where the widget or services are displayed to the consumer.

A First Party includes Affiliates of that First Party, but only to the extent that the Affiliate is (1) an entity that Controls, is Controlled by, or us under common Control with, the First Party; or (2) an entity where the relationship to the First Party is clear to consumers through co-branding or similar means.

A First Party must make reasonable efforts to disclose, in a manner easily discoverable by Users, its ownership or Control of a site or service, such as through branding on the site or service, disclosures in the privacy policy, or terms of use linked to that site or service.

Control of an entity means that one entity (1) is under significant common ownership or operational control of the other entity, or (2) has the power to exercise a controlling influence over the management or policies of the other entity. In addition, for an entity to be under the Control of another entity and be treated as a First Party under this standard, the entity must also adhere to DNT standard in this specification.

3.4 Data Controller and Processor

ISSUE-14 : How does what we talk about with 1st/3rd party relate to European law about data collector vs data processor? [PENDING REVIEW]

The text that follows may move elsewhere or may ultimately be removed from the document.

For the EU, the outsourcing scenario is clearly regulated. In the current EU Directive 95/46/EC, but also in the suggested regulation reforming the data protection regime, an entity using or processing data is subject to data protection law. A First Party (EU: data controller) is an entity or multiple entities (EU: joint data controller) who determines the purposes, conditions and means of the data processing will be the data controller. A service provider (EU: data processor) is an entity with a legal contractual relation to the Data Controller. The Service Provider does determine the purposes, conditions and means of the data processing, but processes data on behalf of the controller. The data processor acts on behalf of the data controller and is a separate legal entity. An entity acting as a first party and contracting services of another party is responsible for the overall processing. A third party is an entity with no contractual relation to the Data Controller and no specific legitimacy or authorization in processing personal data. If the third party has own rights and privileges concerning the processing of the data collected by the first party, it isn't a data processor anymore and thus not covered by exemptions. This third party is then considered as a second data controller with all duties attached to that status. As the pretensions of users are based on law, they apply to first and third party alike unless the third party acts as a mere data processor.

3.5 Network Interaction

3.5.1 Definition

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

3.5.2 Non-Normative Discussion

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.

3.6 Transactional data

Transactional data is information about the user's interactions with various websites, services, or widgets which could be used to create a record of a user’s system information, online communications, transactions and other activities, including websites visited, pages and ads viewed, purchases made, etc.

3.7 Data collection, retention, use, and sharing

The following text consists of proposed text that is meant to address ISSUE-16. This language is currently being actively debated.

ISSUE-16 : What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.)

A party "collects" data if the data comes within its control.
A party "retains" data if data remains within a party's control.
A party "uses" data if the party processes the data for any purpose other than storage.
A party "shares" data if the party enables another party to collect the 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.

3.8 Tracking

We are still working through how, or if, to define tracking. Some suggest the phrase "cross-site tracking" only. We will need to ensure both final recommendations use the same terms in the same way.

3.8.1 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:

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
a third party collecting data on a given website
a first party sharing user data collected from a DNT-on user with third parties "after the fact".

Examples of tracking use cases include:

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

3.8.2 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:

assigning a unique identifier to the user, user agent, or device such that it will be conveyed back to the server on future visits;
personalizing references or referral information such that they will convey the user, user agent, or device identity to other sites;
correlating data provided in the request with identifying data collected from past requests or obtained from a third party; or,
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:

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

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

3.10 Meaningful Interaction

Wording needs polish to ensure it works with accessibility issues, but other than minor edits this is agreed upon.

"Meaningful Interaction" with a widget or window initially presented on a third-party basis means clicking on such content (except to stop, close, silence, or otherwise impair the rendering of such content) or otherwise affirmatively engaging with the content in a manner that would reasonably be interpreted to express an affirmative intention to interact with that party. A user merely moving her cursor across the widget or window does not constitute "meaningful interaction."

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

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

4. Compliance with an expressed tracking preference

4.1 Compliance by a first party

This section consists of proposed text that is meant to address ISSUE-17: Data use by 1st Party, ISSUE-30: Will Do Not Track apply to offline aggregating or selling of data?, ISSUE-54: Can first party provide targeting based on registration information even while sending DNT, ISSUE-59: Should the first party be informed about whether the user has sent a DNT header to third parties on their site?, and ISSUE-91: Might want prohibitions on first parties re-selling data to get around the intent of DNT, and are pending discussion and [PENDING REVIEW].

Additional text has been prepared for each of these five options. This text will be added once an option has been decided upon.

The following are distinct options that have been proposed by members of the group:

Only share if (1): If an operator of a first party domain stores a request to which a [DNT-ON] header is attached, that operator must not share information about that stored communication to a third party, outside of the exemptions as defined in this standard or specific exceptions granted.
Only share if (2): For those users who send the DNT signal and have not granted a site-specific exception to the first party, first parties must NOT share user-specific data with third parties [This will leave room for sharing with Agents/Service Providers/Vendors to the 1st party &emdash; as well as sharing aggregate and anonymous data with "others" (general reporting, for example).]
Do not remember: When DNT is enabled, a 1st party should treat each session with a user as an entirely new session unless it has been given permission to store his information and use it again.
Silence: This standard imposes no requirements on first-party websites. A first-party website may take steps to protect user privacy in responding to a Do Not Track request.
Do not circumvent:
1. Sharing of Data with a Third-Party Website: A first-party website must not share data to a third-party website that the third-party website could not collect itself under this standard. A first-party website may otherwise transfer data to a third-party website.
2. Additional Voluntary Measures: A first-party website may take additional steps to protect user privacy in responding to a Do Not Track request.
  1. Example Voluntary Measures (Non-Normative)
3. Transfer of Data from a First-Party Website: If a third-party website receives data from a first-party website, the data is subject to the same collection, retention, sharing, and use limitations under this standard as if the third-party website had collected the data itself.

4.2 Intermediary compliance

This issue is being addressed in the [TRACKING-DNT] specification.

4.3 Compliance by a third party

This section consists of proposed text that is meant to address ISSUE-19 and ISSUE-39 and is pending discussion and [PENDING REVIEW].

4.3.1 General compliance

4.3.1.1 Option 1: Simple Formulation

If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached:

that operator must not collect, share, or use information related to that communication outside of the exemptions as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;
that operator must not use information about previous communications in which the operator was a third party, outside of the explicitly expressed exemptions as defined within this standard;
that operator [must not or should not] retain information about previous communications in which the operator was a third party, outside of the explicitly expressed exemptions as defined within this standard.

4.3.1.2 Option 2: More Detailed Formulation

The following consists of proposed text that is meant to address ISSUE-71 and is pending discussion and [PENDING REVIEW].

ISSUE-71 : Does DNT also affect past collection or use of past collection of info?

When a third party receives a DNT signal, it must not relate additional data from that HTTP request to existing profiles associated with that user-agent that are based on data that the third party has previously collected across sites over time; this is except as permitted by exemptions stated elsewhere in this specification
Three alternatives:
1. Additionally, the entity must not use identifiers that it can determine were collected from the same user agent before the DNT signal was received, except as permitted by exemptions, for as long as it continues to receive a DNT signal from that user-agent.
2. A third party must not associate collected data with either previous or future user profiles. Any third party data collected under operational purpose exemptions must NEVER be profiled independently or associated with previous or future user profiles.
3. When a third party receives a DNT signal, it must not retain data from that HTTP request that could be associated with an existing profile, except as permitted by exemptions stated elsewhere in this specification.
The entity may take additional steps with respect to previously collected DNXT data such as deleting data before its usual expiration. However, as DNT signal affects only HTTP request that it accompanies and may be modified by the user, it is not recommended that special deletion take place without some notice to user(s).

Examples and use cases

User visits Site A, to which Ad Network B delivers advertisements. Ad Network B has accumulated transactional information about User from User’s visits to Site A and other non-affiliated sites in the past. However, User now sends DNT signal with HTTP request during this session on Site A. Ad Network B cannot add information from current HTTP request from Site A session to any profile it maintains on User. Since it must not collect and any data from this session and relate it to previously collected data, Network B must regard and treat him like completely unknown user to them, absent any exemptions or override from user.
Same as above scenario. Based on transactional information collected about User’s visits to non-affiliated sites in the past, Ad Network B has placed User into Technology Shopper Segment. Since Ad Network B must not recognize User during sessions in which User is sending DNT signal via that browser, it cannot deliver Technology Shopper advertisement to User’s browser, absent obtaining override from user. Ad Network B may instead choose to deliver a random ad, an ad based on the context of Site A, or an ad based on general location based on IP address transmitted with HTTP.

4.3.2 Geolocation compliance by a third party

This section may move into, or have implications for, the section 3 definitions.

If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached:

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.
If specific consent has been granted for the use of more granular location data, than that consent prevails.

4.3.2.1 Non-Normative Discussion

It is acceptable to use data sent as part of this particular network interaction when composing a response to a [DNT-ON] 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.

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

ISSUE-19 : Data collection / Data use (3rd party)

ISSUE-88 : different rules for impression of and interaction with 3rd-party ads/content

4.4 Cookie Syncing

The following consists of proposed text under review

ISSUE-32: Sharing of data between entities via cookie syncing / identity brokering

4.4.1 Non-normative background

In a cookie syncing procedure a Demand-Side Platform (DSP) aim to match a cookieXYZ (corresponding to its domain) to the cookieABC set by the Supply Side Platform (SSP) for the same User-Agent U. Cookie syncing requires that the SSP adds a 1x1 pixel from the DSP domain. The SSP has to pass the string "cookieABC" corresponding to ids domain to the DSP through the URL of this 1x1 pixel. The DSP parses the "cookieABC" in the URL and associates it to the cookieXYZ for its domain. Once the cookies have been matched, the DSP will be able to re-target U on the SSP affiliated sites.

The solution consists in not allowing cookie syncing when the SSP receives DNT:ON. If it did not, the SSP may start the cookie syncing process but the DSP must not synchronize the cookies if it received DNT:ON. The reason is that if the SSP publishes ads on a limited number of websites, the DSP would know that the client visited at least one of these websites.

4.4.2 Normative text

The operator of domain acting as a third party (SSP) on a website and receiving [DNT-ON] must not load content from a second unaffiliated third party domain (DSP) to transfer a user ID to this third party.

A third party receiving [DNT-ON] and a user ID through the URL loaded from an unaffiliated entity acting as a third party must not associate the ID of the cookie sent in the request to the user ID transmitted in the URL and must not collect or use other information related to that communication and not covered by the 3rd party exemption.

Open issues:

This text does not cover Cross-Origin Resource Sharing (CORSE) and perhaps should.
Would rather not have discussion of specific technology, and isn't this already prohibited? This section may be redundant.
Ad Exchanges use cookie synching for business purposes, including third-party auditing to verify ad impressions. However, this might be resolved with a service provider exemption.

4.5 Usage Exemptions

This section outlines potential exemptions to the standard based on necessary business use. For all of these exemptions, the complying entity must make reasonable data minimization efforts to ensure that only the data necessary for the exempted purpose be retained.

The following text consists of proposed text that is meant to address ISSUE-23 , ISSUE-24 , ISSUE-25 , ISSUE-31 , ISSUE-34 , and ISSUE-49 and is pending discussion and [PENDING REVIEW].

Should we explicitly identify goals and use cases in order to evaluate these exemptions?

4.5.1 Exemptions for operational use of data

This section consists of proposed text that is meant to address ISSUE-22 and is pending discussion and [PENDING REVIEW]. We have active discussions in this area.

ISSUE-22 : Still have "operational use" of data (auditing of where ads are shown, impression tracking, etc.)

4.5.1.1 Discussion

In order to preserve certain common and important data usages, while still protecting consumer privacy concerns, it will be necessary to provide operational purpose exemptions for necessary business activities when the DNT signal is on. There are several key categories of data collection and use that must remain intact such that web site operators who are (in the vast majority) offering their services free of charge in exchange for advertising on their properties. Proposed exemptions include:

Frequency Capping - A form of historical tracking to ensure the number of times a user sees the same ad is kept to a minimum. Perhaps related, sequential ad rotation. Withdrawn.
Financial Logging - Ad impressions and clicks (and sometimes conversions) events are tied to financial transactions (this is how online advertising is billed) and therefore must be collected and stored for billing and auditing purposes.
3rd Party Auditing - Online advertising is a billed event and there are concerns with accuracy in impression counting and quality of placement so 3rd party auditors provide an independent reporting service to advertisers and agencies so they can compare reporting for accuracy.
Security - From traditional security attacks to more elaborate fraudulent activity, ad networks must have the ability to log data about suspected bad actors to discern and filter their activities from legitimate transactions. This information is sometimes shared across 3rd parties in cooperatives to help reduce the daisy-chain effect of attacks across the ad ecosystem.
Contextual Content or Ad Serving: A third-party may collect and use information contained with the user agent string (including IP address and referrer url) to deliver content customized to that information.
Research / Market Analytics
Product Improvement, or, more narrowly, Debugging

Discussion is ongoing as to how to define these exemptions and whether or not all should be included in an exemptions list.

4.5.2 Exemption for Outsourcing

This section consists of proposed text that is meant to address ISSUE-23 , ISSUE-72 , ISSUE-73 and ISSUE-49 and are pending discussion and [PENDING REVIEW].

This section may be moved to the section titled "First Parties and Third Parties"

ISSUE-49 : Third party as first party - is a third party that collects data on behalf of the first party treated the same way as the first party?

4.5.2.1 Normative Discussion

A third-party site may operate as a first-party site if all the following conditions hold:

the third party's data collection, retention, and use practices comply with at least the requirements for first-parties;
the data collected by the third party is available only to the first party, and the third party has no independent right to use the data;
the third party makes commitments that are consistent with compliance with this standard and they do so in a form that is legally enforceable (directly or indirectly) by the first party, individual users, and regulators; data retention by the third party must not survive the end of this legal enforceability;
the third party undertakes reasonable technical precautions to prevent collecting [retention of?] data that could be correlated across first parties.

4.5.2.2 Non-Normative Discussion

4.5.2.2.1 Overview

The rationale for rule (2) is that we allow the third party to stand in the first party’s shoes – but go no further. The third party may not use the data it collects for "product improvement," "aggregate analytics," or any other purpose except to fulfill a request by a first party, where the results are shared only with the first party.

Rule (3) allows for the possibility of more than one level of outsourcing.

In rule (4), one component of reasonable technical precautions will often be using the same-origin policy to segregate information for each first-party customer.

Note that any data collected by the third party that is used, or may be used, in any way by any party other than the first party, is subject to the requirements for third parties.

4.5.2.2.2 Examples and use cases

ExampleAnalytics collects analytic data for ExampleProducts Inc.. It operates a site under the DNS analytics.exampleproducts.com. It collects and analyzes data on visits to ExampleProducts, and provides that data solely to ExampleProducts, and does not access or use it itself.

4.5.3 Exemption for unidentifiable data

This section consists of proposed text that is meant to address ISSUE-34 and is pending discussion and [PENDING REVIEW].

ISSUE-34 : Possible Exemption for aggregate analytics

4.5.3.1 Normative Discussion

A third party may collect, retain, and use any information from a user or user agent that, with high probability, could not be used to:

identify or nearly identify a user or user agent; or
correlate the activities of a user or user agent across multiple network interactions.

4.5.3.2 Non-Normative Discussion

4.5.3.2.1 Overview

Clarification is needed with regard to what is meant by the following text

This exemption (like all exemptions) may not be combined with other exemptions unless specifically allowed. A third party acting within the outsourcing exemption, for example, may not make independent use of the data it has collected even though the use involves unidentifiable data.

A rule to the contrary would provide a perverse incentive for third parties to press all exemptions to the limit and then use the collected data within this exemption.

A potential 'safe harbor' under this clause could be to retain only aggregate counts, not per-transaction records.

4.5.3.2.2 Examples and use cases

A third-party advertising network records the fact that it displayed an ad.
A third-party analytics service counts the number of times a popular page was loaded.

4.5.4 Other issues raised around exemptions

ISSUE-24 : Possible exemption for fraud detection and defense

ISSUE-25 : Possible exemption for research purposes

The following consists of proposed text that is meant to address ISSUE-28 and is pending discussion and [PENDING REVIEW].

ISSUE-28 : Exemption for mandatory legal process

This specification is not intended to override applicable laws and regulations.

Indeed, a party may take action contrary to the requirements of this standard if compelled by applicable law. If compelled by applicable law to collect, retain, or transmit data despite receiving a DNT:1 signal for which there is no exemption, the party should notify affected users to the extent practical and allowed by law.

It should be noted that this allowance does not extend to the fulfillment of a contractual obligation.

ISSUE-75 : How do companies claim exemptions and is that technical or not?

ISSUE-31 : Minimization &emdash; to what extent will minimization be required for use of a particular exemption? (conditional exemptions)

ISSUE-92 : If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking?

ISSUE-89 : Does DNT mean at a high level: (a) no customization, users are seen for the first time, every time. (b) DNT is about data moving between sites.

ISSUE-97: Re-direction, shortened URLs, click analytics &emdash; what kind of tracking is this?

5. Exceptions

ISSUE-66 : Can user be allowed to consent to both third party and first party to override general DNT?

ISSUE-93 : Should 1st parties be able to degrade a user experience or charge money for content based on DNT?

5.1 Introduction to exceptions

For the purposes of this document, an exception is a user-granted override of their default DNT status for one or more third parties within a given first party context.

It is possible for first parties to request, and users to set, exceptions to their default DNT status on a per-first party basis for the third parties that the first party works with. The goal of this is to allow first parties to communicate with their users about their options with respect to DNT within the context of that first party's web pages.

Should Market Research be deemed an exception rather than an exemption?

5.2 Opt-In to site-specific exceptions

The following consists of proposed text and is pending discussion and [PENDING REVIEW].

When a DNT enabled user agent grants a site-specific exception, the site places a site-specific opt-in mechanism on the user agent allowing the site to respond as a First Party. The DNT header must remain enabled so that if the user returns to the site, both the user's general preference for DNT and the site-specific exception will be clear. When seeking a site-specific exception from the user, the site must describe to the user, via a direct link from the exception page, all purposes for which the tracking will be used.

5.3 Interaction with existing user privacy controls

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

No DNT Signal / No Opt-Out: Treat as DNT unset
DNT Signal / No Opt-Out: Treat as DNT:1
Opt-Out / No DNT Signal: Treat as DNT:1
Opt-Out / DNT Exception: Treat as DNT:0 for that site; DNT Exception is honored

NOTE: The above text will need to be modified to include the appropriate terminology as this is decided upon by the working group. For example, DNT Exception would need to be replaced with "Site-Specific Exception" depending on the outcome of that discussion.

ISSUE-83 : How do you opt out if already opted in?

ISSUE-67 : Should opt-back-in be stored on the client side? [Not sure this doesn't belong in the technical spec]

5.4 Logged In

ISSUE-65 : How does logged in and logged out state work

5.4.1 Option 1: Logged In Honors DNT

If a user is logged into a first-party website and it receives a DNT:1 signal, the website must respect DNT:1 signal as a first party and should handle the user login as it normally would. If a user is logged into a third-party website, and the third party receives a DNT:1 signal, then it must respect the DNT:1 signal unless it falls under an exemption described in this document.

Example use cases:

A user with DNT:1 logs into a search service called "Searchy". Searchy also operates advertisements on other websites. When the user is on a news website, Searchy receives DNT:1, and it must respect it, as Searchy is operating in a third-party context.
A user with DNT:1 enabled visits a shopping website and logs in. The shopping website continues to provide recommendations, order history, etc. The shopping site includes third-party advertisements. Those third-parties continue to respect DNT:1. When the user purchases the items in their basket, a third-party financial transaction service is used. The user interacts with the third-party service, at which point it becomes first-party and may use previously collected data.
A user with DNT:1 visits a website (Website A) that uses a third-party authentication service called "LogMeIn". The user logs into the site with his LogMeIn credentials. The user has interacted with LogMeIn, and now it can act as a first-party. Now the user vists Website B, which also uses the LogMeIn service, but is branded differently than Website A. LogMeIn must respect the DNT:1 signal until the user chooses to interact with LogMeIn in order to log into Website B.

5.4.2 Option 2: Silence on Logged In

No text on this topic at all, and let the existing rules work it out.

5.5 Enforcement/Compliance

5.5.1 Normative discussion

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 party must make a public commitment that it complies with this standard.

5.5.2 Non-normative discussion

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

ISSUE-21 : Enable external audit of DNT compliance

We have reviewed one audit proposal that we declined to adopt. We may include a smaller-scoped proposal in the future, or may drop auditing all together.