tcs-wd3.txt   tcs-wd4.txt 
W3C W3C
Tracking Compliance and Scope Tracking Compliance and Scope
W3C Working Draft 02 October 2012 W3C Working Draft 30 April 2013
This version: This version:
http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/ http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/
Latest published version: Latest published version:
http://www.w3.org/TR/tracking-compliance/ http://www.w3.org/TR/tracking-compliance/
Latest editor's draft: Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-complian ce.html http://www.w3.org/2011/tracking-protection/drafts/tracking-complian ce.html
Previous version: Previous version:
http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/
Editors: Editors:
Justin Brookman, CDT Justin Brookman, CDT
Sean Harvey, Google
Erica Newland, CDT
Heather West, Google Heather West, Google
Sean Harvey, Google (until June 2012)
Erica Newland, CDT (until May 2012)
Copyright (c) 2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C Copyright (c) 2013 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights
liability, trademark and document use rules apply. Reserved. W3C liability, trademark and document use rules apply.
---------------------------------------------------------------------- ----------------------------------------------------------------------
Abstract Abstract
This specification defines the meaning of a Do Not Track (DNT) preference This specification defines the meaning of a Do Not Track (DNT) preference
and sets out practices for websites to comply with this preference. and sets out practices for websites to comply with this preference.
Status of This Document Status of This Document
This section describes the status of this document at the time of its This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports index at http://www.w3.org/TR/. can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a snapshot of live discussions within the Tracking This document is a snapshot of ongoing discussions within the Tracking
Protection Working Group. It does not yet capture all of our work. For Protection Working Group. Text present or not present in this document
example, we have issues that are [PENDING REVIEW] with complete text does not determine consensus within the Working Group; discussions and
proposals that have not yet made it into this draft. Text in blue boxes debates are ongoing. Text in option boxes (highlighted with light blue
presents multiple options the group is considering. Options included in background color) present options that the group is currently considering,
this draft should not be read as limitations on the potential outcome, but particularly where consensus is known to be lacking, and should be read as
rather simply as possible options that are currently under consideration a set of proposals rather than as limitations on the potential outcome.
by the working group. This draft is substantially revised from the Members of the Working Group wish to emphasize that this draft is a work
previous Working Draft. An issue tracking system is available for in progress and not a decided outcome or guaranteed direction for future
recording raised, open, pending review, closed, and postponed issues versions of this document.
regarding this document.
This draft is substantially revised from the previous Working Draft; much
non-normative text has been removed to provide clarity for the reader and
many options have been condensed by the editors and participants in the
group. Non-normative examples or appendices may be added in subsequent
revisions. An issue tracking system is available for recording raised,
open, pending review, closed, and postponed issues regarding this
document.
This document was published by the Tracking Protection Working Group as a This document was published by the Tracking Protection Working Group as a
Working Draft. This document is intended to become a W3C Recommendation. Working Draft. This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to If you wish to make comments regarding this document, please send them to
public-tracking@w3.org (subscribe, archives). All feedback is welcome. public-tracking@w3.org (subscribe, archives). All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress. document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 This document was produced by a group operating under the 5 February 2004
W3C Patent Policy. W3C maintains a public list of any patent disclosures W3C Patent Policy. W3C maintains a public list of any patent disclosures
made in connection with the deliverables of the group; that page also made in connection with the deliverables of the group; that page also
includes instructions for disclosing a patent. An individual who has includes instructions for disclosing a patent. An individual who has
skipping to change at line 80 skipping to change at line 87
section 6 of the W3C Patent Policy. section 6 of the W3C Patent Policy.
Table of Contents Table of Contents
* 1. Introduction * 1. Introduction
* 2. Scope and Goals * 2. Scope and Goals
* 3. Definitions * 3. Definitions
* 3.1 User * 3.1 User
* 3.2 User Agent * 3.2 User Agent
* 3.3 Party * 3.3 Party
* 3.3.1 Option 1 * 3.4 Service Providers
* 3.3.2 Option 2 * 3.5 First Party
* 3.4 Service Providers/Outsourcers * 3.5.1 Multiple First Parties
* 3.4.1 Option 1: Service Provider/Outsourcer Definition * 3.6 Third Party
* 3.4.1.1 Non-Normative * 3.7 Deidentified Data
* 3.4.1.2 Technical Precautions * 3.8 Network Transaction
* 3.4.1.3 Non-Normative Discussion * 3.9 Data collection, retention, use, and sharing
* 3.4.1.3.1 Siloing in the Browser * 3.9.1 Exception for unknowing collection, retention, and use
* 3.4.1.3.1.1 Same-Origin Policy * 3.10 Tracking
* 3.4.1.3.1.2 Cookie Path Attribute * 3.11 Explicit and Informed Consent
* 3.4.1.3.1.3 Storage Key
* 3.4.1.3.2 Siloing in the Backend
* 3.4.1.3.2.1 Encryption Keys
* 3.4.1.3.2.2 Access Controls
* 3.4.1.3.2.3 Access Monitoring
* 3.4.1.3.3 Retention in the Backend
* 3.4.1.4 Internal Practices
* 3.4.1.4.1 Non-Normative Discussion
* 3.4.1.4.1.1 Policy
* 3.4.1.4.1.2 Training
* 3.4.1.4.1.3 Supervision and Reporting
* 3.4.1.4.1.4 Auditing
* 3.4.1.5 Use Direction
* 3.4.1.6 First Party or Third Party Requirements
* 3.4.1.6.1 Representation
* 3.4.1.6.2 Contract
* 3.4.2 Option 2: Service Provider/Outsourcer Definition
* 3.4.3 Option 3: Service Provider/Outsourcer Definition
* 3.5 First and Third Parties
* 3.5.1 Option 1: First and Third Parties
* 3.5.1.1 Definitions
* 3.5.1.2 Discussion
* 3.5.1.2.1 Overview
* 3.5.1.2.2 Multiple First Parties
* 3.5.1.2.3 User Interaction with Third-Party
Content
* 3.5.2 Option 2: First and Third Parties
* 3.6 Unlinkable Data
* 3.6.1 Option 1: Unlinkable Data
* 3.6.2 Option 2: Unlinkable Data
* 3.7 Network Transaction
* 3.8 Data collection, retention, use, and sharing
* 3.8.1 Exception for unknowing collection, retention, and use
* 3.9 Tracking
* 3.9.1 Option 1: Non-first Party Identifiers
* 3.9.2 Option 2: Cross-site or Over Time
* 3.9.3 Option 3: Silence
* 3.10 Explicit and Informed Consent
* 3.10.1 Option 1: Prescriptive
* 3.10.2 Option 2: Silence
* 4. First Party Compliance * 4. First Party Compliance
* 4.1 Additional/Alternative First Party Compliance Requirements
* 4.1.1 Explanation
* 5. User Agent Compliance * 5. User Agent Compliance
* 6. Third Party Compliance * 6. Third Party Compliance
* 6.1 Permitted Operational Uses for Third Parties and Service * 6.1 Geolocation compliance by a third party
Providers * 6.2 Permitted Operational Uses for Third Parties
* 6.1.1 Enumerated Uses * 6.2.1 Global Requirements for Permitted Uses
* 6.1.1.1 Short Term Collection and Use * 6.2.1.1 No Secondary Uses
* 6.1.1.2 Contextual Content or Ad Delivery * 6.2.1.2 Data Minimization and Transparency
* 6.1.1.2.1 Examples * 6.2.1.3 Reasonable Security
* 6.1.1.3 Content or Ad Delivery Based on First Party * 6.2.1.4 No Personalization
* 6.2.1.5 No Persistent Identifiers
* 6.2.2 Enumerated Permitted Uses
* 6.2.2.1 Short Term Collection and Use
* 6.2.2.2 Contextual Content or Ad Delivery
* 6.2.2.3 Content or Ad Delivery Based on First Party
Data Data
* 6.1.1.3.1 Examples * 6.2.2.4 Frequency Capping
* 6.1.1.4 Frequency Capping * 6.2.2.5 Financial Logging and Auditing
* 6.1.1.4.1 Examples * 6.2.2.6 Security and Fraud Prevention
* 6.1.1.5 Financial Logging and Auditing * 6.2.2.7 Debugging
* 6.1.1.5.1 Examples * 6.2.2.8 Audience Measurement
* 6.1.1.6 Security and Fraud Prevention * 6.2.2.9 Compliance With Local Laws and Public Purposes
* 6.1.1.6.1 Examples
* 6.1.1.7 Debugging
* 6.1.1.7.1 Discussion
* 6.1.1.7.2 Examples
* 6.1.1.8 Aggregate Reporting
* 6.1.1.8.1 Option 1: Aggregate Reporting
* 6.1.1.8.2 Option 2: Aggregate Reporting
* 6.1.1.8.3 Option 3: No Aggregate Reporting
* 6.1.1.9 Compliance With Local Laws and Public Purposes
* 6.1.2 Additional Requirements for Permitted Uses
* 6.1.2.1 No Secondary Uses
* 6.1.2.2 Data Minimization and Transparency
* 6.1.2.3 Reasonable Security
* 6.1.2.4 No Personalization
* 6.1.2.5 No Persistent Identifiers
* 6.2 Geolocation compliance by a third party
* 6.2.1 Discussion
* 6.2.2 Examples
* 6.3 User-Granted Exceptions * 6.3 User-Granted Exceptions
* 6.3.1 Interaction with existing user privacy controls * 6.3.1 Interaction with existing user privacy controls
* 6.3.2 Logged In Transactions * 6.4 Exception for Deidentified Data
* 6.4 Disregarding Non-Compliant User Agents * 6.5 Disregarding Non-Compliant User Agents
* 6.5 Degrading User Experience for DNT:1 users
* 6.6 Public Disclosure of Compliance * 6.6 Public Disclosure of Compliance
* 6.6.1 Third Party Auditing
* A. Acknowledgements * A. Acknowledgements
* B. References * B. References
* B.1 Normative references * B.1 Normative references
* B.2 Informative references
1. Introduction 1. Introduction
Note Note
This introduction will be re-worked after details of substantive text is The introduction will be re-worked after details of substantive text is
closer to being finalized. 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.
2. Scope and Goals 2. Scope and Goals
Issue 6: What are the underlying concerns? Why are we doing this? This specification is designed to provide users a simple machine-readable
preference expression mechanism to globally or selectively allow or limit
This section consists of proposed text that is meant to address ISSUE-6 online tracking.
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 "Tracking" is understood by this standard as the collection and retention
correlation of data about Internet activities that occur on different of data across multiple parties' domains or services in a form such that
sites and spell out the obligations of sites in honoring those it can be attributed to a specific user, user agent, or device.
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, Note
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 The scope language is not at consensus, but is an effort by the editors to
reversible by the user. It aims to preserve a vibrant online ecosystem, offer a provisional definition of tracking.
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.
3. Definitions 3. Definitions
3.1 User 3.1 User
A user is an individual human. When user-agent software accesses online A user is an individual human. When user-agent software accesses online
resources, whether or not the user understands or has specific knowledge resources, whether or not the user understands or has specific knowledge
of a particular request, that request is made "by" the user. of a particular request, that request is made "by" the user.
3.2 User Agent 3.2 User Agent
This specification uses the term user agent to refer to any of the various This specification uses the term user agent to refer to any of the various
client programs capable of initiating HTTP requests, including but not client programs capable of initiating HTTP requests, including but not
limited to browsers, spiders (web-based robots), command-line tools, limited to browsers, spiders (web-based robots), command-line tools,
native applications, and mobile apps [HTTP11]. native applications, and mobile apps [HTTP11].
Note
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.
3.3 Party 3.3 Party
3.3.1 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.
3.3.2 Option 2
A party is any commercial, nonprofit, or governmental organization, a A party is any commercial, nonprofit, or governmental organization, a
subsidiary or unit of such an organization, or a person. For unique subsidiary or unit of such an organization, or a person. For unique
corporate entities to qualify as a common party with respect to this corporate entities to qualify as a common party with respect to this
document, those entities MUST be commonly owned and commonly controlled document,those entities MUST be commonly owned and commonly controlled and
(Affiliates) and MUST provide "easy discoverability" of affiliate MUST provide easy discoverability of affiliate organizations. An list of
organizations. An "Affiliate List" MUST be provided within one click from affiliates MUST be provided within one click from each page or the entity
each page or the entity owner clearly identified within one click from owner clearly identified within one click from each page.
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.
3.4 Service Providers/Outsourcers
Note
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.
3.4.1 Option 1: Service Provider/Outsourcer Definition
Note
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.)
3.4.1.1 Non-Normative
This section is 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.
3.4.1.2 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.
3.4.1.3 Non-Normative Discussion
This section is non-normative.
3.4.1.3.1 Siloing in the Browser
This section is non-normative.
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.
3.4.1.3.1.1 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 1
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.
3.4.1.3.1.2 Cookie Path Attribute
The HTTP cookie path can be used to silo data to a first party.
Example 2
Example Analytics stores its cookies for Example News with
"Path=/examplenews", and it stores its cookies for Example Sports with
"Path=/examplesports".
3.4.1.3.1.3 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 3
Example Analytics stores data for Example News at
window.localStorage["examplenews"] and data for Example Sports at
window.localStorage["examplesports"].
3.4.1.3.2 Siloing in the Backend
3.4.1.3.2.1 Encryption Keys
An outsourcing service should encrypt each first party's data with a
different set of keys.
3.4.1.3.2.2 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.
3.4.1.3.2.3 Access Monitoring
An outsourcing service should deploy access monitoring mechanisms to
detect improper use of siloed data.
3.4.1.3.3 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.
3.4.1.4 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.
3.4.1.4.1 Non-Normative Discussion
This section is non-normative.
3.4.1.4.1.1 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.
3.4.1.4.1.2 Training
Personnel that interact with outsourced data should be familiarized with
internal policy on compliance with this standard.
3.4.1.4.1.3 Supervision and Reporting
An outsourcing service should establish a supervision and reporting
structure for detecting improper access.
3.4.1.4.1.4 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.
3.4.1.5 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.
3.4.1.6 First Party or Third Party Requirements
3.4.1.6.1 Representation
A party's representation that it is in compliance with this standard
includes a representation that its outsourcing parties comply with this
standard.
3.4.1.6.2 Contract
A first party MUST enter into a contract with an outsourced party that
requires that outsourced party to comply with these requirements.
3.4.2 Option 2: Service Provider/Outsourcer Definition 3.4 Service Providers
Outsourced service providers are considered to be the same party as their Outsourced service providers are considered to be the same party as their
clients if the outsourced service providers only act as data processors on clients if the outsourced service providers only act as data processors on
behalf of that party, silo the data so that it cannot be accessed by other behalf of that party in relation to that party, silo the data so that it
parties, and have no control over the use or sharing of that data except cannot be accessed by other parties, and have no control over the use or
as directed by that party. sharing of that data except as directed by that party.
3.4.3 Option 3: Service Provider/Outsourcer Definition
Service Providers acting on the behalf of a First Party and with no
independent rights to use the First Party's data outside of the context of
that First Party and Permitted Uses are also considered to be acting as
the First Party.
3.5 First and Third Parties
3.5.1 Option 1: First and Third Parties
3.5.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.
3.5.1.2 Discussion
This section is non-normative.
3.5.1.2.1 Overview
This section is non-normative.
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.
3.5.1.2.2 Multiple First Parties
Note Outsourced service providers are considered to be the same party as their
clients if the service provider
There has been some disagreement within the group over how many first 1. acts only as a data processor on behalf of the client;
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 2. ensures that the data can only be accessed and used as directed by that
expect to communicate with: the provider of the website the user has client;
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 3. has not independent right to use or share the data except as necessary
additional meaningful interaction with otherwise third party content on to ensure the integrity, security, and correct operation of the service
the webpage. The first party is the registrant and operator of the domain being provided; and
that the user intentionally communicated with.
If a user intends to communicate with a party that utilizes a different 4. has a contract in place that outlines and mandates these requirements.
party as a platform, then both parties are first parties in the network
transaction.
Example: ExampleSports franchise has a dedicated page on a ExampleSocial. Issue 49: Third party as first party -- is a third party that collects
When a user visits this dedicated page, both ExampleSports and data on behalf of a first party treated the same way as the first party
ExampleSocial are first parties.
3.5.1.2.3 User Interaction with Third-Party Content 3.5 First Party
A party may start out as a third party but become a first party later on, In a specific network interaction, a party with which the user
after a user interacts with it. If content from a third party is embedded intentionally interacts is a first party. In most cases on a traditional
on a first party page, the third party may become an additional first web browser, the first party will be the party that owns and operates the
party if it can infer with high probability that the average user domain visible in the address bar. The party that owns and operates or has
knowingly and intentionally communicated with it. If a user merely moused control over a branded/labelled embedded widget, search box, or similar
over, closed, or muted third-party content, the party would not be able to service with which a user intentionally interacts is also considered a
draw such an inference. First Party. If a user merely mouses over, closes, or mutes such content,
that is not sufficient interaction to render the party a first party.
Examples 3.5.1 Multiple First Parties
1. Example Weather offers an unbranded weather widget that is embedded In most network interactions, there will be only one first party with
into websites, including Example News. The widget contains small links which the user intends to interact. However, in some cases, a network
to Example Weather's website and privacy policy. A user visits Example resource will be jointly operated by two or more parties, and a user would
News and scrolls through the weekly forecast in the Example Weather reasonably expect to communicate with all of them by accessing that
widget. Example Weather is a third party. The user has interacted with resource. User understanding that multiple parties operate a particular
Example Weather's widget, but an ordinary user would not expect that resource could be accomplished through inclusion of multiple parties'
scrolling through the widget involves communicating with Example News. brands in a domain name, or prominent branding on the resource indicating
2. Example Social, a popular social network, hosts a social sharing that multiple parties are responsible for content or functionality on the
button that other websites can embed. The button is colored and styled resource with which a user reasonably would expect to interact by
in the same fashion as Example Social's website, contains descriptive accessing the resource. Simple branding of a party, without more, will not
text that is specific to Example Social, includes Example Social's be sufficient to make that party a first party in any particular network
logo, and very frequently appears on Example Social's website. Example interaction.
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.
3.5.2 Option 2: First and Third Parties Issue 10: What is a first party?
First Party is the party that owns the Web site or has control over the 3.6 Third Party
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.
Note In a specific network interaction, any entity that is not the user, user
agent, or a first party is considered a third party.
If a user merely mouses over, closes, or mutes third-party content, that 3.7 Deidentified Data
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 Data is deidentified when a party:
the user. It is possible to have multiple first parties on a single page (1) has taken measures to ensure with a reasonable level of justified
but each party must provide clear branding and a link to their respective confidence that the data cannot be used to infer information about, or
privacy policy (co-branded experience). otherwise be linked to, a particular consumer, computer, or other device;
(2) does not to try to reidentify the data; and
(3) contractually prohibits downstream recipients from trying to
re-identify the data.
3.6 Unlinkable Data Data can be considered sufficiently deidentified to the extent that it has
been deleted, modified, aggregated, anonymized or otherwise manipulated in
order to achieve a reasonable level of justified confidence that the data
cannot reasonably be used to infer information about, or otherwise be
linked to, a particular user, user agent, or device.
Note Note
There is debate about whether to use the terms unlinkable, unlinked, or The first option above is based on the definition of unlinkable data in
unidentified to describe this type of data. the 2012 FTC privacy report; the second option was proposed by Daniel
Kaufman. The group has a fundamental disagreement about whether internal
3.6.1 Option 1: Unlinkable Data access controls within an organization could be sufficient to de-identify
data for the purposes of this standard.
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.
3.6.2 Option 2: Unlinkable Data Issue 188: Definition of unlinkable data
A dataset is unlinkable when there is a high probability that it contains Issue 191: Non-normative Discussion of De-Identification
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.
3.7 Network Transaction 3.8 Network Transaction
A "network interaction" is an HTTP request and response, or any other A network interaction is an HTTP request and response, or any other
sequence of logically related network traffic. sequence of logically related network traffic.
Non-normative explanatory text: Determination of a party's status is 3.9 Data collection, retention, use, and sharing
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.8 Data collection, retention, use, and sharing
Note
We have not had time to substantially edit the definitions of collection
and tracking. These continue to be actively debated issues, as the
resolution of the use of unique identifiers is likely to end up in these
definitions.
Issue 16: What does it mean to collect data? (caching, logging, storage, Issue 16: What does it mean to collect data? (caching, logging, storage,
retention, accumulation, profile etc.) retention, accumulation, profile etc.)
1. A party "collects" data if the data comes within its control. 1. A party collects data if it receives the data and either shares the
2. A party "retains" data if data remains within a party's control beyond data with other parties or stores the data for more than a transient
period.
2. A party retains data if data remains within a party's control beyond
the scope of the current interaction. the scope of the current interaction.
3. A party "uses" data if the party processes the data for any purpose 3. A party uses data if the party processes the data for any purpose
other than storage or merely forwarding it to another party. other than storage or merely forwarding it to another party.
4. A party "shares" data if the party enables another party to receive or 4. A party shares data if the party provides a copy or access to the data
access that data. to a third party.
The definitions of collection, retention, use, and sharing are drafted The definitions of collection, retention, use, and sharing are drafted
expansively so as to comprehensively cover a party's user-information expansively so as to comprehensively cover a party's user-information
practices. These definitions do not require a party's intent; a party may practices. These definitions do not require a party's intent; a party may
inadvertently collect, retain, use, or share data. The definition of inadvertently collect, retain, use, or share data. The definition of
collection includes information that a party did not cause to be collection includes information that a party did not cause to be
transmitted, such as protocol headers. transmitted, such as protocol headers.
3.8.1 Exception for unknowing collection, retention, and use 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.
3.9.1 Exception for unknowing collection, retention, and use
A party may receive, retain, and use data as otherwise prohibited by this A party may receive, retain, and use data as otherwise prohibited by this
standard, so long as is unaware of such information practices and has made standard, so long as it is unaware of such information practices and has
reasonable efforts to understand its information practices. If a party made reasonable efforts to understand its information practices. If a
learns that it possesses information in violation of this standard, it party learns that it possesses information in violation of this standard,
must delete that information at the earliest practical opportunity. it must delete that information at the earliest practical opportunity.
3.9 Tracking 3.10 Tracking
Note Note
The term "tracking" is not used in the document. This section is likely to The term "tracking" is not used in the normative text of this document. We
be deleted, and the issues will be addressed in the definitions of may subsequently decide to define this term, or address the issue of what
"collection" and "unlinkable" above. is "tracking" in the Introduction or Scope section. A definition proposed
by the editors is available in the Scope section above.
Issue 117: Terms: tracking v. cross-site tracking Issue 117: Terms: tracking v. cross-site tracking
3.9.1 Option 1: Non-first Party Identifiers 3.11 Explicit and Informed Consent
Note Note
Concerns with this section include undefined term "user data" plus as The spec currently envisions that users should consent to both the setting
written, this may apply more broadly than the authors intended of a DNT preference as well as any user-granted exceptions. We have not
reached agreement on how precisely we need to define this term.
Tracking is the collection or use of user data via either a unique Explicit and informed choice must satisfy the following bright-line
identifier or a correlated set of data points being used to approximate a requirements:
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 1. Actual presentation: The choice mechanism MUST be actually presented
first party in one or more (but not all) of the multiple contexts to the user. It MUST NOT be on a linked page, such as a terms of
2. a third party collecting data on a given website service or privacy policy.
3. a first party sharing user data collected from a DNT:1 user with third 2. Clear Terms: The choice mechanism MUST use clear, non-confusing
parties "after the fact". technology.
3. Independent choice: The choice mechanism MUST be presented independent
of other choices. It MUST NOT be bundled with other user preferences.
4. No default permission: The choice MUST NOT have the user permission
selected by default.
Examples of tracking use cases include: No definition, other than explicitly leaving the definition of consent to
local rules.
1. personalized advertising Issue 69: Should the spec say anything about minimal notice? (ie. don't
2. cross-site analytics or market research that has not been bury in a privacy policy)
de-identified
3. automatic preference sharing by social applications
3.9.2 Option 2: Cross-site or Over Time 4. First Party Compliance
Tracking is defined as following or identifying a user, user agent, or If a first party receives a network transaction to which a DNT:1 header is
device across multiple visits to a site (time) or across multiple sites attached, First Parties may engage in their normal collection and use of
(space). information. This includes the ability to customize the content, services,
and advertising in the context of the first party experience.
Mechanisms for performing tracking include but are not limited to: The first party must not pass information about this transaction to
non-service provider third parties who could not collect the data
themselves under this standard.
1. assigning a unique identifier to the user, user agent, or device such 4.1 Additional/Alternative First Party Compliance Requirements
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 When DNT:1 is received,
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; 1. A first party MUST NOT combine or otherwise use identifiable data
2. the first-party (and third-parties acting as the first-party) to received from another party with data it collected while a first
provide the service intentionally requested by the user; and party;
3. other services for which the user has provided prior, specific, and 2. A first party MUST NOT share identifiable data with another party
informed consent. unless the data was provided voluntarily by the user and is necessary
to complete a business transaction with the user; and
3. A party MUST NOT use data gathered while a first party when operating
as a third party.
3.9.3 Option 3: Silence 4.1.1 Explanation
One proposal is not to define "tracking," but rather to list what is, or This section is non-normative.
is not, required and allowed in order to comply with the recommendation.
3.10 Explicit and Informed Consent When DNT:1 is received, a first party retains the ability to customize
content, services, and advertising only within the context of the first
party experience. A first party takes the user interaction outside of the
first party experience if it receives identifiable data from another party
and uses that data for customization of content, services, or advertising.
When DNT:1 is received the first Party may continue to utilize user
provided data in order to complete or fulfill a user initiated business
transaction such as fulfilling an order for goods or a subscription.
When DNT:1 is received and a Party has become a third party it is
interacting with the user outside of the first party experience. Using
data gathered while a first party is incompatible with interaction as a
third party.
Note Note
The spec currently envisions that users should consent to both the setting This language is not consensus. The parties are generally agreed that this
of a DNT preference as well as any user-granted exceptions. We have not language should prohibit first parties from enabling third parties to
reached agreement on how precisely we need to define this term. 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, or whether third
parties may use data they previously collected in a first party context.
One proposed compromise to the first issue would be to allow data append
only when the data broker would qualify as a service provider, having no
independent right to use the data associated with the append inquiry.
Issue 69: Should the spec say anything about minimal notice? (ie. don't Issue 170: Definition of and what/whether limitations around data append
bury in a privacy policy)
3.10.1 Option 1: Prescriptive 5. User Agent Compliance
Explicit and informed choice must satisfy the following bright-line A user agent MUST offer a control to express a tracking preference to
requirements: third parties. The control MUST communicate the user's preference in
1. Actual presentation: The choice mechanism MUST be actually presented to accordance with the [TRACKING-DNT] recommendation and otherwise comply
the user. It MUST NOT be on a linked page, such as a terms of service or with that recommendation. A user agent MUST NOT express a tracking
privacy policy. preference for a user unless the user has given express and informed
2. Clear Terms:The choice mechanism MUST use clear, non-confusing consent to indicate a tracking preference.
technology.
3. Independent choice: The choice mechanism MUST be presented independent
of other choices. It MUST NOT be bundled with other user preferences.
4. No default permission: The choice MUST NOT have the user permission
selected by default.
3.10.2 Option 2: Silence While we do not specify how tracking preference choices are offered to the
user or how the preference is enabled, each implementation MUST follow the
following user interface guidelines:
No definition, other than explicitly leaving the definition of consent to 1. The User Agent is responsible for determining the user experience by
local rules. which a tracking preference is enabled. For example, a user might select a
check-box in their user agent's configuration, or install an extension or
add-on that is specifically designed to add a tracking preference
expression so long as the checkbox, extension or add-on otherwise follows
these user interface guidelines;
4. First Party Compliance 2. The User Agent MUST ensure that the tracking preference choices are
communicated to users clearly and conspicuously, and shown at the time and
place the tracking preference choice is made available to a user;
Note 3. The User Agent MUST ensure that the tracking preference choices
accurately describe DNT, including the parties to whom DNT applies, and
MUST make available via a link in explanatory text where DNT is enabled to
provide more detailed information about DNT functionality.
This language is not consensus and must change. The parties are generally Non-Normative:
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 The User Agent plays a key role in enacting the DNT functionality. As a
attached, First Parties may engage in their normal collection and use of result, it is appropriate for the User Agent to play an equally key role
information. This includes the ability to customize the content, services, in describing DNT functionality and educating users about DNT in order for
and advertising in the context of the first party experience. this standard to be meaningful.
The First Party must not pass information about this transaction to While the user interface guidelines do not specify the exact presentation
non-service provider third parties who could not collect the data to the user, they are intended to help ensure that users understand their
themselves under this Recommendation. choices with respect to DNT. For example, outlining the parties (e.g.,
First Parties, Service Providers, Third Parties) to whom DNT applies and
using language that a reasonable user is likely to understand is critical
for ensuring that users are in position to provide their informed consent
to a tracking preference.
Issue 229: Draft crisp definition [of data append] Moreover, as DNT functionality is complex, it is important that User
Agents educate users about DNT, including but not limited to offering a
clearly described link that takes the user to additional information about
DNT functionality. For example, given that some parties may chose not to
comply with DNT, it would be helpful for browsers to educate users about
how to check the response header and/or tokens to see if a server is
responding with a "public commitment" of compliance.
5. User Agent Compliance Finally, recognizing that DNT settings may be set by non-browser User
Agents acting in violation of the user interface guidelines, the browsers
should take reasonable steps to ensure that DNT settings are valid.
A user agent MUST offer a control to express a tracking preference to User agents and web sites MUST obtain express and informed consent when
third parties. The control MUST communicate the user's preference in setting controls that affect the tracking preference expression. The
accordance with the [TRACKING-DNT] recommendation and otherwise comply controls MUST communicate the user's preference in accordance with the
with that recommendation. A user agent MUST NOT express a tracking [TRACKING-DNT] recommendation.
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 User agents and web sites offering tracking preference choices to users
or how the preference is enabled: each implementation is responsible for MUST follow the following user interface guidelines:
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 1. User agents and web sites are responsible for determining the user
user agents: experience by which a tracking preference is controlled;
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 2. User agents and web sites MUST ensure that tracking preference choices
functionality are communicated to users clearly and accurately, and shown at the time
2. Any User Agent claiming compliance must have a functional and place the tracking preference choice is made available to a user;
implementation of the browser exceptions in this specification
3. User agents and web sites SHOULD ensure that the tracking preference
choices describe the parties to whom DNT applies and SHOULD make available
explanatory text to provide more detailed information about DNT
functionality.
Issue 150: DNT conflicts from multiple user agents Issue 150: DNT conflicts from multiple user agents
Issue 153: What are the implications on software that changes requests but Issue 153: What are the implications on software that changes requests but
does not necessarily initiate them? does not necessarily initiate them?
6. Third Party Compliance 6. Third Party Compliance
Note
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 If a third party receives a communication to which a DNT:1 header is
attached: attached:
1. that third party MUST NOT collect, share, or use information related 1. that third party MUST NOT collect, retain, share, or use information
to that communication outside of the permitted uses as defined within related to that communication outside of the permitted uses as defined
this standard and any explicitly-granted exceptions, provided in within this standard and any explicitly-granted exceptions, provided
accordance with the requirements of this standard; in accordance with the requirements of this standard;
2. that third party MUST NOT use information about previous 2. that third party MUST NOT share or use information about previous
communications in which it was a third party, outside of the permitted communications in which it was a third party, outside of the permitted
uses as defined within this standard and any explicitly-granted uses as defined within this standard and any explicitly-granted
exceptions, provided in accordance with the requirements of this exceptions, provided in accordance with the requirements of this
standard; standard;
3. that third party MAY delete information about previous communications
in which it was a third party.
6.1 Permitted Operational Uses for Third Parties and Service Providers 6.1 Geolocation compliance by a third party
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.
6.2 Permitted Operational Uses for Third Parties
Note Note
These are options that have been discussed in the group. While many have 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 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 the draft and whether they should be permitted uses. There is also
substantial disagrement over the SCOPE of information that may be substantial disagrement over the SCOPE of information that may be
collected, used, and retained for these purposes, most notably whether collected, used, and retained for these purposes, most notably whether
persistent unique identifiers may be collected, used, and retained for persistent unique identifiers may be collected, used, and retained for
these purposes. these purposes.
skipping to change at line 1063 skipping to change at line 545
As long as there is: As long as there is:
* No Secondary Use * No Secondary Use
* Data Minimization and Transparency * Data Minimization and Transparency
* Reasonable Security * Reasonable Security
* No Personalization * No Personalization
These permitted uses and requirements are further discussed below. These permitted uses and requirements are further discussed below.
6.1.1 Enumerated Uses 6.2.1 Global Requirements for Permitted Uses
6.1.1.1 Short Term Collection and Use
Note
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).
6.1.1.2 Contextual Content or Ad Delivery
Note
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.
6.1.1.2.1 Examples
This section is non-normative.
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.
6.1.1.3 Content or Ad Delivery Based on First Party Data
Note
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 content or advertisements based in part of data that
the third party previously collected from the user when acting as a first
party.
6.1.1.3.1 Examples
This section is non-normative.
1. A user visits ExampleNews.com with DNT:1 enabled to read a story about
a national election. ExamplesNews 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.
6.1.1.4 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.
6.1.1.4.1 Examples
This section is non-normative.
A user visits ExampleNews with DNT:1 enabled. ExamplesNews 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 fives 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.
6.1.1.5 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
Note
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.
6.1.1.5.1 Examples
This section is non-normative.
Note
Add examples for display verification, click verification, CPA, quality
measures
6.1.1.6 Security and Fraud Prevention
Regardless of DNT signal, information may be collected, retained and used
for detecting security risks and fraudulent activity, defending from
attacks and fraud, and maintaining integrity of the service. This includes
data reasonably necessary for enabling authentication/verification,
detecting hostile 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.
Note
The more likely options at this point may be represented in Nick Doty's
proposed:
To the extent reasonably necessary for protection of computers and
networks and to detect ad or other fraud, third parties may engage in
tracking. Use of graduated response is preferred.
or David Wainberg's proposed:
Parties may collect and use data in any way to the extent reasonably
necessary for the detection and prevention of malicious or illegitimate
activity.
6.1.1.6.1 Examples
This section is non-normative.
Note
Add examples with and without outsourced parties
6.1.1.7 Debugging
Regardless of DNT signal, information may be collected, retained and used
for identifying and repairing errors that impair existing intended
functionality.
6.1.1.7.1 Discussion
This section is non-normative.
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.
6.1.1.7.2 Examples
This section is non-normative.
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.
6.1.1.8 Aggregate Reporting
6.1.1.8.1 Option 1: Aggregate Reporting
Regardless of DNT signal, information may be collected, retained and used
for aggregate reporting, such as market research and product improvement.
Data MAY be collected and retained on an individual level, but the use of
the data must only be aggregate reporting, and the products of the
reporting MUST be unlinkable as defined in this document.
6.1.1.8.2 Option 2: Aggregate Reporting
Regardless of DNT signal, information may be collected, retained and used
for aggregate reporting, such as market research and product improvement,
if that information is collected and retained for another enumerated
permitted use. Data MAY be collected and retained on an individual level,
but the use of the data must only be aggregate reporting, and the products
of the reporting MUST be unlinkable as defined in this document. If the
operator no longer has another enumerated permitted use for which to use
and retain the data, the operator MAY NOT use and retain the data for
aggregate reporting unless the data has been rendered unlinkable as
defined in this document.
6.1.1.8.3 Option 3: No Aggregate Reporting
There is no permitted use for aggregate reporting outside of the grace
period described earlier.
Issue 25: Possible exception for research purposes
6.1.1.9 Compliance With Local Laws and Public Purposes
Note
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.
6.1.2 Additional Requirements for Permitted Uses
In order to use the Permitted Uses outlined, a party must comply with In order to use the permitted uses outlined below, a party MUST comply
these four requirements. with these four requirements.
6.1.2.1 No Secondary Uses 6.2.1.1 No Secondary Uses
Third Parties MUST NOT use data retained for permitted uses for Third Parties MUST NOT use data retained for a permitted use for
non-permitted uses. non-permitted uses.
6.1.2.2 Data Minimization and Transparency 6.2.1.2 Data Minimization and Transparency
A third party MUST ONLY retain information for a Permitted Use for as long Data retained by a party for permitted uses MUST be limited to the data
as is reasonably necessary for that use. Third parties MUST make reasonably necessary for such permitted uses, and MUST be retained no
reasonable data minimization efforts to ensure that only the data longer than is reasonably necessary for such permitted uses. A third party
necessary for the permitted use is retained. A third party MUST provide MUST make reasonable data minimization efforts to ensure that only data
public transparency of their data retention period. The third party MAY necessary for each permitted use is retained. A third party MUST provide
enumerate each individually if they vary across Permitted Uses. Once the public transparency of their data retention period for each permitted use.
period of time for which you have declared data retention for a given use, Once a retention period for a given use has expired, the data MUST NOT be
the data MUST NOT be used for that permitted use. After there are no used for that permitted use; when there are no remaining permitted uses
remaining Permitted Uses for given data, the data must be deleted or for some data, that data MUST either be deleted or rendered unlinkable.
rendered unlinkable.
Note Additional proposed language:
May be worthwhile to put some examples in around when it is or isn't a Where feasible, a third party SHOULD NOT collect linkable data when that
good idea to explain use, ie, Commonly Accepted Practices vs. security data is not reasonably necessary for one of the permitted uses. In
data to address unique businesses particular, data not necessary for a communication (for example, cookie
data, URI parameters, unique identifiers inserted by a network
intermediary) MUST NOT be retained unless reasonably necessary for a
particular permitted use.
6.1.2.3 Reasonable Security 6.2.1.3 Reasonable Security
Third parties MUST use reasonable technical and organizational safeguards Third parties MUST use reasonable technical and organizational safeguards
to prevent further processing of data retained for Permitted Uses. While to prevent further processing of data retained for Permitted Uses. While
physical separation of data maintained for permitted uses is not required, physical separation of data maintained for permitted uses is not required,
best practices should be in place to ensure technical controls ensure best practices should be in place to ensure technical controls ensure
access limitations and information security. Third parties SHOULD ensure access limitations and information security. Third parties SHOULD ensure
that the access and use of data retained for Permitted Uses is auditable. that the access and use of data retained for Permitted Uses is auditable.
Note 6.2.1.4 No Personalization
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.
6.1.2.4 No Personalization
Outside of Security and Frequency Capping, data retained for Permitted Outside of Security and Frequency Capping, data retained for Permitted
Uses MUST NOT be used to alter a specific user's online experience based Uses MUST NOT be used to alter a specific user's online experience [based
on multi-site activity. on multi-site activity].
6.1.2.5 No Persistent Identifiers 6.2.1.5 No Persistent Identifiers
A third party may only collect, use, and retain for permitted uses 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 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 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 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 means, unless the URL contains information that is not unlinkable (e.g. a
username or user ID). username or user ID).
A third party may not collect, use, or retain information that a web 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 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 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 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 network intermediary that the operator of a web server has actual
knowledge of (e.g. a unique device identifier HTTP header). knowledge of (e.g. a unique device identifier HTTP header).
Flexibility is provided to implementers on how they accomplish permitted
uses and minimize data retention and use. Implementers are advised to
avoid data collection for DNT:1 users where feasible to enable external
confidence.
Placing third-party cookies with unique identifiers (and other techniques
for linking data to a user, user agent or device) are permitted where
reasonably necessary for a permitted use. Requirements on minimization and
secondary use, however, provide limitations on when any collection
technique is compatible with a Do Not Track preference and what the
implications of that collection are.
To give flexibility to implementers in accomplishing the requirements of
this specification and the listed permitted uses, no particular data
collection techniques are prescribed or prohibited. Implementers are
advised that collection of user data under a Do Not Track preference
(including using unique tracking cookies or browser fingerprinting) may
reduce external auditability, monitoring and user confidence and that
retention of such data may imply liability in certain jurisdictions in
cases of secondary use; for more information, see the Global
Considerations.
Note Note
The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement
that permitted use data is not correlated to a unique cookie or other that permitted use data is not correlated to a unique cookie or other
persistent identifier. This issue remains one of the biggest areas of persistent identifier. This issue remains one of the biggest areas of
dispute in the working group, as the industry proposal allows for the use 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 of cookies and other unique identifiers by third parties despite a DNT:1
instruction. instruction.
6.2 Geolocation compliance by a third party 6.2.2 Enumerated Permitted Uses
6.2.2.1 Short Term Collection and Use
Information may be collected, retained, and used any purpose, so long as
the information is retained for no longer than N weeks and the information
is not transmitted to a third party and the information is not used to
build a profile about a user or otherwise alter any individual's user
experience (apart from changes that are made based on aggregate data or
security concerns).
Operators MAY collect and retain data related to a communication in a
third-party context for up to N weeks. During this time, operators may
render data deidentified or perform processing of the data for any of the
other permitted uses.
Issue 134: Would we additionally permit logs that are retained for a short
enough period?
Issue 142: How should protocol data be allowed to be used in the first N
weeks?
6.2.2.2 Contextual Content or Ad Delivery
Note Note
Unclear whether this section reflects group consensus. Note that it is not clear that this is in scope. Revisit whether
contextual belongs in some place other than permitted uses (potentially
the definition of collection).
Issue 39: Tracking of geographic data (however it's determined, or used) 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.
If the operator of a third-party domain receives a communication to which 6.2.2.3 Content or Ad Delivery Based on First Party Data
a DNT:1 header is attached:
1. Geo-location information that is more granular than postal code is too Information may be collected, retained and used for the display of content
granular. Geolocation data must not be used at any level more granular or advertisements based in part on data that the third party previously
than postal code. Note that while the number of people living in a collected from the user when acting as a first party.
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.
6.2.1 Discussion Note
This section is non-normative. This permitted use does not reflect consensus. Some members of the group
do not think first party data should be used in a third-party context
(this option is reflected in the optional text for First Party Compliance
above).
It is acceptable to use data sent as part of this particular network This text may be revised to offer two alternatives: first parties can use
interaction when composing a response to a DNT:1 request, but it is not any data to offer content in the third party context, or first parties can
acceptable to store that data any longer than needed to reply. For only use declared data to offer content in the third party context. Shane
instance, it would be appropriate to use an IP address to guess which Wiley has proposed defining "declared data" as Information directly and
country a user is in, to avoid showing them an advertisement for products expressly supplied by a user to a party through meaningful interaction
or services unavailable where they live. with that party.
When using request-specific information to compose a reply, some levels of The issue is also contingent upon what identifiers third parties can use
detail may feel invasive to users, and may violate their expectations in when Do Not Track is turned on. If third parties cannot read cookies,
about Do Not Track. These sorts of detailed assessments should be avoided. they may be unable to associate first parties in third-party scenarios.
6.2.2 Examples Others have argued that this language is unnecessary because the standard
places no limitations on the use of first party data.
This section is non-normative. Issue 54: can first parties use declared data while in a 3rd party
context?
Reasonable behavior: A user visits you from an IP address which a general 6.2.2.4 Frequency Capping
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 Information may be collected, retained and used for limiting the number of
that they are in a particular ZIP+4, which has a distinctive demographic times that a user sees a particular advertisement, often called "frequency
profile. Their user-agent indicates that they are a Mac user, further capping."
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 Operators MAY retain data related to a communication in a third-party
based exclusively on request specific information, but was still tailored context to use for limiting how often advertisements are shown to a
to a highly-specific user profile. In particular, the estimation of a particular user if the data retained do not include the user's browsing
user's location to within a single ZIP+4 may make a user feel that they history (for example, page URIs on which ads were past delivered). For
are being followed closely, even if the decision was made on the fly, and this permitted use, operators MUST NOT construct profiles of users or user
the information was only held ephemerally. behavior based on their ad frequency history or otherwise alter the user's
experience based on this data.
6.3 User-Granted Exceptions 6.2.2.5 Financial Logging and Auditing
Information may be collected, retained and used for billing and auditing
of concurrent transactions. This may include counting ad impressions to
unique visitors, verifying positioning and quality of ad impressions and
auditing compliance with this and other standards.
Issue 22: Still have operational use of data (auditing of where ads are
shown, impression tracking, etc.)
6.2.2.6 Security and Fraud Prevention
Information may be collected, retained and used to the extent reasonably
necessary for detecting security risks and fraudulent or malicious
activity. This includes data reasonably necessary for enabling
authentication/verification, detecting hostile and invalid transactions
and attacks, providing fraud prevention, and maintaining system integrity.
In this example specifically, this information may be used to alter the
user's experience in order to reasonably keep a service secure or prevent
fraud. Graduated response is preferred when feasible.
Note Note
Figure out which parts of UGE belong in which document. There has been an unresolved discussion on whether "graduated response"
should be in the normative text, defined, addressed through non-normative
examples, or not included at all.
Issue 24: Possible exemption for fraud detection and defense
6.2.2.7 Debugging
Information may be collected, retained and used for identifying and
repairing errors that impair existing intended functionality.
6.2.2.8 Audience Measurement
Note
The group has recently debated whether to include a permitted use for the
collection of third-party data to calibrate audience measurement primarily
conducted through the use of opt-in panels. The most recent proposal by
ESOMAR is available, but the language is not consensus, and the working
group has not decided whether such a permitted use is even appropriate.
Issue 25: Possible exemption for research purposes
6.2.2.9 Compliance With Local Laws and Public Purposes
Adherence to laws, legal and judicial process, and regulations take
precedence over this standard when applicable, but contractual obligations
do not.
6.3 User-Granted Exceptions
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 The operator of a website may engage in practices otherwise described by
this standard if the user has given explicit and informed consent. This this standard if the user has given explicit and informed consent. This
consent may be obtained through the browser API defined in the companion consent may be obtained through the browser API defined in the companion
[TRACKING-DNT] document, or an operator of a website may also obtain [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 "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 different technology. If an operator is relying on "out of band" consent
to disregard a "Do Not Track" instruction, the operator must indicate this to disregard a "Do Not Track" instruction, the operator must indicate this
consent to the user agent as described in the companion [TRACKING-DNT] consent to the user agent as described in the companion [TRACKING-DNT]
document. document.
This protocol does not define what constitutes explicit consent in any
jurisdiction; check with your lawyer.
User agents and web sites MUST obtain express and informed consent when
setting controls that affect the tracking preference expression. The
controls MUST communicate the user's preference in accordance with the
[TRACKING-DNT] recommendation.
User agents and web sites offering tracking preference choices to users
MUST follow the following user interface guidelines:
1. User agents and web sites are responsible for determining the user
experience by which a tracking preference is controlled;
2. User agents and web sites MUST ensure that tracking preference choices
are communicated to users clearly and accurately, and shown at the time
and place the tracking preference choice is made available to a user;
3. User agents and web sites SHOULD ensure that the tracking preference
choices describe the parties to whom DNT applies and SHOULD make available
explanatory text to provide more detailed information about DNT
functionality.
6.3.1 Interaction with existing user privacy controls 6.3.1 Interaction with existing user privacy controls
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out 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 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 browser vendors are on the same page with respect to honoring user choices
in circumstances where "mixed signals" may be received. in circumstances where "mixed signals" may be received.
As a general principle, more specific settings override less specific As a general principle, more specific settings override less specific
settings. settings.
1. No DNT Signal / No Opt-Out: Treat as DNT unset 1. No DNT Signal / No Opt-Out: Treat as DNT unset
2. DNT Signal / No Opt-Out: Treat as DNT:1 2. DNT Signal / No Opt-Out: Treat as DNT:1
3. Opt-Out / No DNT Signal: 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; 4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site;
DNT User-Granted Exception is honored DNT User-Granted Exception is honored
6.3.2 Logged In Transactions 6.4 Exception for Deidentified Data
Note
Add note that we may be able to handle this section entirely within the
consent definition, rather than calling it out; potentially thought an
example in the consent section. Concern about UI creep.
Issue 65: How does logged in and logged out state work
6.4 Disregarding Non-Compliant User Agents
Note If a third party receives a communication to which a DNT:1 header is
attached, that third party MAY neverthess collect, retain, share, or use
data related to that communication if the data is or has been rendered
deidentified.
this section is the topic of active debate. 6.5 Disregarding Non-Compliant User Agents
Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly 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 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. 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 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 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, 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. 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 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 user agent that it is disregarding the header as described in the
companion [TRACKING-DNT] document. companion [TRACKING-DNT] document.
No provision on Disregarding Non-Compliant User Agents. If the operator of a third-party domain does not intend to comply with a
DNT:1 signal whose syntax is correctly formed, the operator MUST send a
6.5 Degrading User Experience for DNT:1 users signal to the user agent that it is disregarding the header as described
in the companion [TRACKING-DNT] document.
Note No provision on disregarding non-compliant user agents.
We have consensus that it's fine to degrade the experience for DNT:1 Issue 161: Do we need a tracking status value for partial compliance or
transactions, but need to find the text. rejecting DNT?
Issue 93: Should 1st parties be able to degrade a user experience or On the [TRACKING-DNT] document, we have this pending-review issue
charge money for content based on DNT? regarding communicating disregarding a user/agent.
6.6 Public Disclosure of Compliance 6.6 Public Disclosure of Compliance
Note Note
Final wording awaits how the response is designed in the TRACKING-DNT Final wording awaits how the response is designed in the TRACKING-DNT
recommendation, but we agree upon the general direction below. recommendation, but we agree upon the general direction below.
In order to be in compliance with this specification, a third party must 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 make a public commitment that it complies with this standard. A "public
commitment" may consist of a statement in a privacy policy, a response commitment" may consist of a statement in a privacy policy, a response
header, a machine-readable tracking status resource at a well-known header, a machine-readable tracking status resource at a well-known
location, or any other reasonable means. This standard does not require a location, or any other reasonable means. This standard does not require a
specific form of public commitment. specific form of public commitment.
6.6.1 Third Party Auditing
Issue 21: Enable external audit of DNT compliance
Tracking Status Qualifiers may include a value to indicate auditing.
A. Acknowledgements A. Acknowledgements
This specification consists of input from many discussions within and This specification consists of input from many discussions within and
around the W3C Tracking Protection Working Group, along with written around the W3C Tracking Protection Working Group, along with written
contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando
(Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), (Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla),
Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University),
Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson
(Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), (Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert),
David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and
skipping to change at line 1573 skipping to change at line 897
Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm
(Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot
Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.
B. References B. References
B.1 Normative references B.1 Normative references
[HTTP11] [HTTP11]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June
1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt 1999. RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
[TRACKING-DNT] [TRACKING-DNT]
Roy T. Fielding; David Singer. Tracking Preference Expression Roy T. Fielding; David Singer. Tracking Preference Expression
(DNT). 2 October 2012. W3C Working Draft. (Work in progress.) URL: (DNT). 02 October 2012. W3C Working Draft. URL:
http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/ http://www.w3.org/TR/tracking-dnt/
B.2 Informative references
[KnowPrivacy]
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June
2009. URL:
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf
 End of changes. 130 change blocks. 
1188 lines changed or deleted 512 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/