tcs-wd2.txt | tcs-wd3.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Compliance and Scope | Tracking Compliance and Scope | |||
W3C Working Draft 13 March 2012 | W3C Working Draft 02 October 2012 | |||
This version: | This version: | |||
http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ | http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/ | |||
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/2011/WD-tracking-compliance-20111114/ | http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ | |||
Editors: | Editors: | |||
Justin Brookman, CDT | Justin Brookman, CDT | |||
Sean Harvey, Google | Sean Harvey, Google | |||
Erica Newland, CDT | Erica Newland, CDT | |||
Heather West, Google | Heather West, Google | |||
Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. | Copyright (c) 2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C | |||
W3C liability, trademark and document use rules apply. | 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 live discussions within the Tracking | |||
Protection Working Group. It does not yet capture all of our work. For | Protection Working Group. It does not yet capture all of our work. For | |||
example, we have issues that are [PENDING REVIEW] with complete text | example, we have issues that are [PENDING REVIEW] with complete text | |||
proposals that did not make it into this draft. Text in white is typically | proposals that have not yet made it into this draft. Text in blue boxes | |||
[CLOSED]: we have reached a consensus decision. Text in blue boxes | presents multiple options the group is considering. Options included in | |||
presents multiple options the group is considering. In some cases we are | this draft should not be read as limitations on the potential outcome, but | |||
close to agreement, and in others we have more to discuss. An issue | rather simply as possible options that are currently under consideration | |||
tracking system is available for recording raised, open, pending review, | by the working group. This draft is substantially revised from the | |||
closed, and postponed issues regarding this document. This draft, | previous Working Draft. An issue tracking system is available for | |||
published 13 March 2012, is substantially different from and more complete | recording raised, open, pending review, closed, and postponed issues | |||
than the First Public Working Draft. | regarding this document. | |||
We have not yet reviewed comments from the Community Group associated with | ||||
this work. We thank them for their time and detailed feedback, and will | ||||
address their comments in the near future. | ||||
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 feedback is 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. | |||
skipping to change at line 80 | skipping to change at line 76 | |||
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 | |||
actual knowledge of a patent which the individual believes contains | actual knowledge of a patent which the individual believes contains | |||
Essential Claim(s) must disclose the information in accordance with | Essential Claim(s) must disclose the information in accordance with | |||
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 | |||
* 2.1 Goals | ||||
* 3. Definitions | * 3. Definitions | |||
* 3.1 Drafting Notes | * 3.1 User | |||
* 3.2 Parties | * 3.2 User Agent | |||
* 3.2.1 Option 1: User Expectations | * 3.3 Party | |||
* 3.2.1.1 Definition | * 3.3.1 Option 1 | |||
* 3.2.1.2 Non-Normative Discussion | * 3.3.2 Option 2 | |||
* 3.2.1.2.1 Domain Names | * 3.4 Service Providers/Outsourcers | |||
* 3.2.1.2.2 Corporate Affiliation | * 3.4.1 Option 1: Service Provider/Outsourcer Definition | |||
* 3.2.1.2.3 Branding | * 3.4.1.1 Non-Normative | |||
* 3.2.2 Option 2: Discoverable Affiliates | * 3.4.1.2 Technical Precautions | |||
* 3.2.2.1 Normative Discussion | * 3.4.1.3 Non-Normative Discussion | |||
* 3.2.2.2 Non-Normative Discussion | * 3.4.1.3.1 Siloing in the Browser | |||
* 3.3 First Parties and Third Parties | * 3.4.1.3.1.1 Same-Origin Policy | |||
* 3.3.1 Option 1: Meaningful User Interaction | * 3.4.1.3.1.2 Cookie Path Attribute | |||
* 3.3.1.1 Definitions | * 3.4.1.3.1.3 Storage Key | |||
* 3.3.1.2 Non-Normative Discussion | * 3.4.1.3.2 Siloing in the Backend | |||
* 3.3.1.2.1 Overview | * 3.4.1.3.2.1 Encryption Keys | |||
* 3.3.1.2.1.1 Common Examples and Use Cases | * 3.4.1.3.2.2 Access Controls | |||
* 3.3.1.2.2 Multiple First Parties | * 3.4.1.3.2.3 Access Monitoring | |||
* 3.3.1.2.3 User Interaction with Third-Party | * 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 | Content | |||
* 3.3.1.2.3.1 Examples and Use Cases | * 3.5.2 Option 2: First and Third Parties | |||
* 3.3.2 Option 2: Discoverable Ownership and Affiliates | * 3.6 Unlinkable Data | |||
* 3.3.2.1 Definitions | * 3.6.1 Option 1: Unlinkable Data | |||
* 3.4 Data Controller and Processor | * 3.6.2 Option 2: Unlinkable Data | |||
* 3.5 Network Interaction | * 3.7 Network Transaction | |||
* 3.5.1 Definition | * 3.8 Data collection, retention, use, and sharing | |||
* 3.5.2 Non-Normative Discussion | * 3.8.1 Exception for unknowing collection, retention, and use | |||
* 3.6 Transactional data | * 3.9 Tracking | |||
* 3.7 Data collection, retention, use, and sharing | * 3.9.1 Option 1: Non-first Party Identifiers | |||
* 3.8 Tracking | * 3.9.2 Option 2: Cross-site or Over Time | |||
* 3.8.1 Option 1: Non-first Party Identifiers | * 3.9.3 Option 3: Silence | |||
* 3.8.2 Option 2: Cross-site or Over Time | * 3.10 Explicit and Informed Consent | |||
* 3.8.3 Option 3: Silence | * 3.10.1 Option 1: Prescriptive | |||
* 3.9 Consent | * 3.10.2 Option 2: Silence | |||
* 3.9.1 Option 1 | * 4. First Party Compliance | |||
* 3.9.2 Option 2 | * 5. User Agent Compliance | |||
* 3.9.3 Silence | * 6. Third Party Compliance | |||
* 3.10 Meaningful Interaction | * 6.1 Permitted Operational Uses for Third Parties and Service | |||
* 3.11 User | Providers | |||
* 3.12 User Agent | * 6.1.1 Enumerated Uses | |||
* 4. Compliance with an expressed tracking preference | * 6.1.1.1 Short Term Collection and Use | |||
* 4.1 Compliance by a first party | * 6.1.1.2 Contextual Content or Ad Delivery | |||
* 4.2 Intermediary compliance | * 6.1.1.2.1 Examples | |||
* 4.3 Compliance by a third party | * 6.1.1.3 Content or Ad Delivery Based on First Party | |||
* 4.3.1 General compliance | Data | |||
* 4.3.1.1 Option 1: Simple Formulation | * 6.1.1.3.1 Examples | |||
* 4.3.1.2 Option 2: More Detailed Formulation | * 6.1.1.4 Frequency Capping | |||
* 4.3.2 Geolocation compliance by a third party | * 6.1.1.4.1 Examples | |||
* 4.3.2.1 Non-Normative Discussion | * 6.1.1.5 Financial Logging and Auditing | |||
* 4.3.2.2 Examples | * 6.1.1.5.1 Examples | |||
* 4.4 Cookie Syncing | * 6.1.1.6 Security and Fraud Prevention | |||
* 4.4.1 Non-normative background | * 6.1.1.6.1 Examples | |||
* 4.4.2 Normative text | * 6.1.1.7 Debugging | |||
* 4.5 Usage Exemptions | * 6.1.1.7.1 Discussion | |||
* 4.5.1 Exemptions for operational use of data | * 6.1.1.7.2 Examples | |||
* 4.5.1.1 Discussion | * 6.1.1.8 Aggregate Reporting | |||
* 4.5.2 Exemption for Outsourcing | * 6.1.1.8.1 Option 1: Aggregate Reporting | |||
* 4.5.2.1 Normative Discussion | * 6.1.1.8.2 Option 2: Aggregate Reporting | |||
* 4.5.2.2 Non-Normative Discussion | * 6.1.1.8.3 Option 3: No Aggregate Reporting | |||
* 4.5.2.2.1 Overview | * 6.1.1.9 Compliance With Local Laws and Public Purposes | |||
* 4.5.2.2.2 Examples and use cases | * 6.1.2 Additional Requirements for Permitted Uses | |||
* 4.5.3 Exemption for unidentifiable data | * 6.1.2.1 No Secondary Uses | |||
* 4.5.3.1 Normative Discussion | * 6.1.2.2 Data Minimization and Transparency | |||
* 4.5.3.2 Non-Normative Discussion | * 6.1.2.3 Reasonable Security | |||
* 4.5.3.2.1 Overview | * 6.1.2.4 No Personalization | |||
* 4.5.3.2.2 Examples and use cases | * 6.1.2.5 No Persistent Identifiers | |||
* 4.5.4 Other issues raised around exemptions | * 6.2 Geolocation compliance by a third party | |||
* 5. Exceptions | * 6.2.1 Discussion | |||
* 5.1 Introduction to exceptions | * 6.2.2 Examples | |||
* 5.2 Opt-In to site-specific exceptions | * 6.3 User-Granted Exceptions | |||
* 5.3 Interaction with existing user privacy controls | * 6.3.1 Interaction with existing user privacy controls | |||
* 5.4 Logged In | * 6.3.2 Logged In Transactions | |||
* 5.4.1 Option 1: Logged In Honors DNT | * 6.4 Disregarding Non-Compliant User Agents | |||
* 5.4.2 Option 2: Silence on Logged In | * 6.5 Degrading User Experience for DNT:1 users | |||
* 5.5 Enforcement/Compliance | * 6.6 Public Disclosure of Compliance | |||
* 5.5.1 Normative discussion | * 6.6.1 Third Party Auditing | |||
* 5.5.2 Non-normative discussion | ||||
* A. Acknowledgements | * A. Acknowledgements | |||
* B. References | * B. References | |||
* B.1 Normative references | * B.1 Normative references | |||
* B.2 Informative references | * B.2 Informative references | |||
1. Introduction | 1. Introduction | |||
Note | ||||
This introduction will be re-worked after details of substantive text is | ||||
closer to being finalized. | ||||
The World Wide Web (WWW, or Web) consists of millions of sites | The World Wide Web (WWW, or Web) consists of millions of sites | |||
interconnected through the use of hypertext. Hypertext provides a simple, | interconnected through the use of hypertext. Hypertext provides a simple, | |||
page-oriented view of a wide variety of information that can be traversed | page-oriented view of a wide variety of information that can be traversed | |||
by selecting links, manipulating controls, and supplying data via forms | by selecting links, manipulating controls, and supplying data via forms | |||
and search dialogs. A Web page is usually composed of many different | and search dialogs. A Web page is usually composed of many different | |||
information sources beyond the initial resource request, including | information sources beyond the initial resource request, including | |||
embedded references to stylesheets, inline images, javascript, and other | embedded references to stylesheets, inline images, javascript, and other | |||
elements that might be automatically requested as part of the rendering or | elements that might be automatically requested as part of the rendering or | |||
behavioral processing defined for that page. | behavioral processing defined for that page. | |||
Each of the hypertext actions and each of the embedded resource references | 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 | 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 | the user even though the pages might be composed of information requested | |||
from many different and possibly independent Web sites. From the user's | from many different and possibly independent Web sites. From the user's | |||
perspective, they are simply visiting and interacting with a single brand | perspective, they are simply visiting and interacting with a single brand | |||
- the first-party Web property - and all of the technical details and | -- the first-party Web property -- and all of the technical details and | |||
protocol mechanisms that are used to compose a page representing that | protocol mechanisms that are used to compose a page representing that | |||
brand are hidden behind the scenes. | brand are hidden behind the scenes. | |||
It has become common for Web site owners to collect data regarding the | 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 | 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 | 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 | 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 | (audience segmentation). In some cases, the data collected is used to | |||
dynamically adapt the content (personalization) or the advertising | dynamically adapt the content (personalization) or the advertising | |||
presented to the user (targeted advertising). Data collection can occur | presented to the user (targeted advertising). Data collection can occur | |||
skipping to change at line 213 | skipping to change at line 231 | |||
troubled by what they perceive as an invasion of their privacy. For them, | troubled by what they perceive as an invasion of their privacy. For them, | |||
the benefit of personalization is not worth their concerns about allowing | the benefit of personalization is not worth their concerns about allowing | |||
entities with whom they have no direct relationship to amass detailed | entities with whom they have no direct relationship to amass detailed | |||
profiles about their activities. | profiles about their activities. | |||
Therefore, users need a mechanism to express their own preference | Therefore, users need a mechanism to express their own preference | |||
regarding tracking that is both simple to configure and efficient when | regarding tracking that is both simple to configure and efficient when | |||
implemented. In turn, Web sites that are unwilling or unable to offer | implemented. In turn, Web sites that are unwilling or unable to offer | |||
content without such targeted advertising or data collection need a | content without such targeted advertising or data collection need a | |||
mechanism to indicate those requirements to the user and allow them (or | mechanism to indicate those requirements to the user and allow them (or | |||
their user agent) to make an individual choice regarding exceptions. | their user agent) to make an individual choice regarding user-granted | |||
exceptions. | ||||
This specification defines the terminology of tracking preferences, the | This specification defines the terminology of tracking preferences, the | |||
scope of its applicability, and the requirements on compliant first-party | scope of its applicability, and the requirements on compliant first-party | |||
and third-party participants when an indication of tracking preference is | and third-party participants when an indication of tracking preference is | |||
received. This specification defines the meaning of a Do Not Track | received. This specification defines the meaning of a Do Not Track | |||
preference and sets out practices for websites and other online companies | preference and sets out practices for websites and other online companies | |||
to comply with this preference. | to comply with this preference. | |||
A companion document, [[!!TRACKING-DNT]], defines the HTTP request header | A companion document, [TRACKING-DNT], defines the HTTP request header | |||
field DNT for expressing a tracking preference on the Web, a well-known | field DNT for expressing a tracking preference on the Web, a well-known | |||
location (URI) for providing a machine-readable tracking status resource | location (URI) for providing a machine-readable tracking status resource | |||
that describes a service's DNT compliance, the HTTP response header field | that describes a service's DNT compliance, the HTTP response header field | |||
Tk for resources to communicate their compliance or non-compliance with | Tk for resources to communicate their compliance or non-compliance with | |||
the user's expressed preference, and JavaScript APIs for determining DNT | the user's expressed preference, and JavaScript APIs for determining DNT | |||
status and requesting a site-specific exception. | status and requesting a site-specific, user-granted exception. | |||
ISSUE-117: Terms: tracking v. cross-site tracking | ||||
The WG has not come to consensus regarding the definition of tracking and | ||||
whether the scope of DNT includes all forms of user-identifying data | ||||
collection or just cross-site data collection/use. This issue will be | ||||
resolved in the TCS document, though its resolution is a necessary | ||||
prerequisite to understanding and correctly implementing the protocol | ||||
defined by this document. | ||||
2. Scope and Goals | 2. Scope and Goals | |||
2.1 Goals | Issue 6: What are the underlying concerns? Why are we doing this? | |||
This section consists of proposed text that is meant to address ISSUE-6 | This section consists of proposed text that is meant to address ISSUE-6 | |||
and is in active discussion. Currently, it satisfies no one. We will | and is in active discussion. Currently, it satisfies no one. Like the | |||
revisit and finalize once the document is more complete. | introduction, we will revisit and finalize once the document is more | |||
complete. | ||||
ISSUE-6: What are the underlying concerns? Why are we doing this? | ||||
While there are a variety of business models to monetize content on the | While there are a variety of business models to monetize content on the | |||
web, many rely on advertising. Advertisements can be targeted to a | web, many rely on advertising. Advertisements can be targeted to a | |||
particular user's interests based on information gathered about one's | particular user's interests based on information gathered about one's | |||
online activity. While the Internet industry believes many users | online activity. While the Internet industry believes many users | |||
appreciate such targeted advertising, as well as other personalized | appreciate such targeted advertising, as well as other personalized | |||
content, there is also an understanding that some people find the practice | content, there is also an understanding that some people find the practice | |||
intrusive. If this opinion becomes widespread, it could undermine the | intrusive. If this opinion becomes widespread, it could undermine the | |||
trust necessary to conduct business on the Internet. This Compliance | trust necessary to conduct business on the Internet. This Compliance | |||
specification and a companion [TRACKING-DNT] specification are intended to | specification and a companion [TRACKING-DNT] specification are intended to | |||
skipping to change at line 273 | skipping to change at line 283 | |||
sophistication of the Internet has grown, so too has its complexity which | sophistication of the Internet has grown, so too has its complexity which | |||
leaves all but the most technically savvy unable to deeply understand how | leaves all but the most technically savvy unable to deeply understand how | |||
web sites collect and use data about their online interactions. While on | 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 | 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 | 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 | to power a user's online experience. As an additional privacy tool, this | |||
specification provides both the technical and compliance guidelines to | specification provides both the technical and compliance guidelines to | |||
enable the online ecosystem to further empower users with the ability to | enable the online ecosystem to further empower users with the ability to | |||
communicate a tracking preferences to a web site and its partners. | communicate a tracking preferences to a web site and its partners. | |||
The accompanying [TRACKING-DNT] recommendation explains how a user, | The accompanying TRACKING-DNT recommendation explains how a user, through | |||
through a user agent, can clearly express a desire not to be tracked. This | a user agent, can clearly express a desire not to be tracked. This | |||
Tracking Compliance and Scope recommendation sets the standard for the | Tracking Compliance and Scope recommendation sets the standard for the | |||
obligations of a website that receives such a DNT message. | obligations of a website that receives such a DNT message. | |||
Taken together these two standards should have four substantial outcomes: | Taken together these two standards should have four substantial outcomes: | |||
1. Empower users to manage their preference around the collection and | 1. Empower users to manage their preference around the collection and | |||
correlation of data about Internet activities that occur on different | correlation of data about Internet activities that occur on different | |||
sites and spell out the obligations of sites in honoring those | sites and spell out the obligations of sites in honoring those | |||
preferences when DNT is enabled. | preferences when DNT is enabled. | |||
2. Provide an exceedingly straightforward way for users to gain | 2. Provide an exceedingly straightforward way for users to gain | |||
transparency and control over data usage and the personalization of | transparency and control over data usage and the personalization of | |||
content and advertising on the web. | content and advertising on the web. | |||
3. Enable a vibrant Internet to continue to flourish economically by | 3. Enable a vibrant Internet to continue to flourish economically by | |||
supporting innovative business models while protecting users' privacy. | supporting innovative business models while protecting users' privacy. | |||
4. Establish compliance metrics for operators of online services | 4. Establish compliance metrics for operators of online services | |||
This standard has limited applicability to any practices by first parties, | ||||
their service providers, subsidiaries, or affiliated companies. Under the | ||||
standard, first parties may and will continue to collect and use data for | ||||
tracking and other purposes. This standard is primarily directed at third | ||||
parties. | ||||
This solution is intended to be persistent, technology neutral, and | This solution is intended to be persistent, technology neutral, and | |||
reversible by the user. It aims to preserve a vibrant online ecosystem, | reversible by the user. It aims to preserve a vibrant online ecosystem, | |||
privacy-preserving secondary data uses necessary to ecommerce, and | privacy-preserving secondary data uses necessary to ecommerce, and | |||
adequate security measures. We seek a solution that is persistent, | adequate security measures. We seek a solution that is persistent, | |||
technology neutral, and [something that speaks with the ability to opt | technology neutral, and [something that speaks with the ability to opt | |||
back in], but that preserves a vibrant online ecosystem, | back in], but that preserves a vibrant online ecosystem, | |||
privacy-preserving secondary data uses, and adequate security measures. | privacy-preserving secondary data uses, and adequate security measures. | |||
3. Definitions | 3. Definitions | |||
The Definitions section of this document is in a high state of flux as of | 3.1 User | |||
this draft and contains a large number of controversial text proposals and | ||||
open issues for the working group. None of these definitions should be | ||||
considered definitive or final. | ||||
The term exemption is used to indicate a restricted set of conditions | A user is an individual human. When user-agent software accesses online | |||
under which tracking is allowed in spite of the user's DNT preference. The | resources, whether or not the user understands or has specific knowledge | |||
term exception is used when the user has permitted tracking, usually in | of a particular request, that request is made "by" the user. | |||
the form of a site-specific exception, for a given third-party. In | ||||
general: exemptions are additional permissions granted by the standard; | ||||
exceptions are additional permissions granted by the user. These words are | ||||
often confused when drafting new text. | ||||
3.1 Drafting Notes | 3.2 User Agent | |||
ISSUE-97 : A special rule for URL-shortening services remains an open | This specification uses the term user agent to refer to any of the various | |||
issue and is not addressed in the proposal put forward in 3.2 through 3.4. | client programs capable of initiating HTTP requests, including but not | |||
limited to browsers, spiders (web-based robots), command-line tools, | ||||
native applications, and mobile apps [HTTP11]. | ||||
ISSUE-26 : Providing data to 3rd-party widgets &emdash; does that imply | Note | |||
consent? | ||||
The proposal put forward here does not provided a special rule for | There has been recent discussion about whether the specification should | |||
widgets. The same first party vs. third party test for static content | differentiate among different types of users agents (such as general | |||
applies. | 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.2 Parties | 3.3 Party | |||
3.2.1 Option 1: User Expectations | 3.3.1 Option 1 | |||
3.2.1.1 Definition | A party is any commercial, nonprofit, or governmental organization, a | |||
subsidiary or unit of such an organization, or a person 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. | ||||
A "party" is any commercial, nonprofit, or governmental organization, a | 3.3.2 Option 2 | |||
subsidiary or unit of such an organization, or a person, that an ordinary | ||||
user would perceive to be a discrete entity for purposes of information | ||||
collection and sharing. Domain names, branding, and corporate ownership | ||||
may contribute to, but are not necessarily determinative of, user | ||||
perceptions of whether two parties are distinct. | ||||
3.2.1.2 Non-Normative Discussion | A party is any commercial, nonprofit, or governmental organization, a | |||
subsidiary or unit of such an organization, or a person. For unique | ||||
corporate entities to qualify as a common party with respect to this | ||||
document, those entities MUST be commonly owned and commonly controlled | ||||
(Affiliates) and MUST provide "easy discoverability" of affiliate | ||||
organizations. An "Affiliate List" MUST be provided within one click from | ||||
each page or the entity owner clearly identified within one click from | ||||
each page. | ||||
Our definition of what constitutes a "party" is guided by ordinary user | A website with a clear labeled link to the Affiliate List within the | |||
expectations. We decline to adopt a conflicting approach that would draw a | privacy policy would meet this requirement or the ownership brand clearly | |||
line at domain names, corporate affiliation, or branding, as discussed | labeled on the privacy policy itself and may choose to act as a single | |||
below. | party. | |||
3.2.1.2.1 Domain Names | 3.4 Service Providers/Outsourcers | |||
In an uncomplicated world, a party might be delineated by domain | Note | |||
boundaries. In practice, however, the domain approach can emphasize | ||||
differences that would not matter to ordinary users and would be | ||||
restrictive for many business uses. Suppose Example Company hosts dynamic | ||||
content on example.com and static images on example-static.com. An average | ||||
user would understand both domains are operated by Example Company, but a | ||||
domain name distinction would say the two domains are different parties. | ||||
Using domain names to differentiate parties would also impose an | ||||
unnecessary choice on large websites of either hosting all their content | ||||
on a single domain or having some of their content considered third party. | ||||
By adopting a user expectations standard, we allow a single website to | ||||
span multiple domains. | ||||
A domain name approach can also gloss over relevant differences from a | We seem to have general consensus in theory but not in language for the | |||
user expectations perspective. Suppose Example Company hires an analytics | definition of a service provider. However, the three options below | |||
company and aliases the domain analytics.example.com to the analytics | different significantly in how prescriptive and demanding the test to | |||
company's website. By user expectations, and corporate affiliation and | qualify as a service provider should be. | |||
branding, the analytics company would be a separate party. Moreover, | ||||
circumventing the limits imposed by this standard would require nothing | ||||
more than switching domain names. The user expectations standard we adopt | ||||
recognizes that multiple parties may exist at a single domain. | ||||
3.2.1.2.2 Corporate Affiliation | 3.4.1 Option 1: Service Provider/Outsourcer Definition | |||
Corporate families can consist of businesses in completely unrelated | Note | |||
industries; users may have limited understanding of how businesses are | ||||
related by corporate ownership or control. Moreover, by creating | ||||
affiliates for the purposes of data sharing, organizations could | ||||
circumvent the limits imposed by this standard. Under the user | ||||
expectations standards we adopt, a corporate affiliate is not, in general, | ||||
the same party as an organization. | ||||
3.2.1.2.3 Branding | This option contains both definitions and normative compliance | |||
requirements. | ||||
In many cases, branding aligns with ordinary user expectations. Unrelated | This section applies to parties engaging in an outsourcing relationship, | |||
websites rarely share branding. In company ownership scenarios, prominent | wherein one party "stands in the shoes" of another party to perform a | |||
language like "Brand A, provided by Company B" may be sufficient for the | specific task. Both parties have responsibilities, as detailed below. | |||
average user to understand that Brand A is owned by Company B and | ||||
information shared with Brand A may also be shared with Company B. | ||||
But, in some cases, branding does not align with user expectations. | A first party or a third party MAY outsource functionality to another | |||
Suppose Example Search owns a video sharing website, Example Video. Most | party, in which case the third party may act as the original first party | |||
users are aware that Example Video is a subsidiary of Example Search, and | or third party under this standard, with the following additional | |||
that the Example Video website differs from the Example Search website for | restrictions: | |||
historical reasons. The Example Video home page does not, however, include | ||||
any branding reference to Example Search. Under a branding test, Example | ||||
Search and Example Branding would be different parties. The user | ||||
expectations test allows for factors, other than branding, that influence | ||||
user understanding. | ||||
Branding may also fall short in informing user expectations. If most users | * Data collected by each outsourced company is separated for each party | |||
have never heard of Company B, language like "Brand A, provided by Company | they collect data for by both technical means and organizational | |||
B" may not be adequate for the average user to understand the relationship | process, AND | |||
between Brand A and Company B. A user expectations test recognizes there | * The outsourced company has no independent rights to the collected | |||
may be instances where even conspicuous branding is inadequate to inform | information, AND | |||
users. | * A contractual relationship exists between the outsourced and the party | |||
they collect data for that outlines and mandates these requirements. | ||||
3.2.2 Option 2: Discoverable Affiliates | 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.2.2.1 Normative Discussion | 3.4.1.1 Non-Normative | |||
A party is any commercial, nonprofit, or governmental organization, a | This section is non-normative. | |||
subsidiary or unit of such an organization, or a person. For unique | ||||
corporate entities to qualify as a common party with respect to this | ||||
standard, those entities must be commonly owned and commonly controlled, | ||||
and must make their parent affiliation (if any) easy discoverable to | ||||
users. | ||||
3.2.2.2 Non-Normative Discussion | 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. | ||||
This may be accomplished in many ways, including but not limited to, | For the data separation requirement, outsourced companies have technical | |||
prominent and common branding on site pages, "one click away" within | options to achieve appropriate separation but in each the critical element | |||
Privacy Policies, and, if available, a programmatic list of domains that | is that data is never reconstituted for users that have indicated a | |||
share common ownership (affiliation). | 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. | ||||
3.3 First Parties and Third Parties | 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.3.1 Option 1: Meaningful User Interaction | 3.4.1.2 Technical Precautions | |||
3.3.1.1 Definitions | 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. | ||||
A "first party" is any party, in a specific network interaction, that can | 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 | ||||
Outsourced service providers are considered to be the same party as their | ||||
clients if the outsourced service providers only act as data processors on | ||||
behalf of that party, silo the data so that it cannot be accessed by other | ||||
parties, and have no control over the use or sharing of that data except | ||||
as directed by that party. | ||||
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 | infer with high probability that the user knowingly and intentionally | |||
communicated with it. Otherwise, a party is a third party. | communicated with it. Otherwise, a party is a third party. | |||
A "third party" is any party, in a specific network interaction, that | A third party is any party, in a specific network interaction, that cannot | |||
cannot infer with high probability that the user knowingly and | infer with high probability that the user knowingly and intentionally | |||
intentionally communicated with it. | communicated with it. | |||
Some participants are concerned this proposal is not implementable as-is. | 3.5.1.2 Discussion | |||
3.3.1.2 Non-Normative Discussion | This section is non-normative. | |||
3.3.1.2.1 Overview | 3.5.1.2.1 Overview | |||
This section is non-normative. | ||||
We draw a distinction between those parties an ordinary user would or | We draw a distinction between those parties an ordinary user would or | |||
would not expect to share information with, "first parties" and "third | would not expect to share information with, "first parties" and "third | |||
parties" respectively. The delineation exists for three reasons. | parties" respectively. The delineation exists for three reasons. | |||
First, when a user expects to share information with a party, she can | First, when a user expects to share information with a party, she can | |||
often exercise control over the information flow. Take, for example, | often exercise control over the information flow. Take, for example, | |||
Example Social, a popular social network. The user may decide she does not | 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 | like Example Social's privacy or security practices, so she does not visit | |||
examplesocial.com. But if Example Social provides a social sharing widget | examplesocial.com. But if Example Social provides a social sharing widget | |||
skipping to change at line 466 | skipping to change at line 632 | |||
Second, we recognize that market pressures are an important factor in | Second, we recognize that market pressures are an important factor in | |||
encouraging good privacy and security practices. If users do not expect | encouraging good privacy and security practices. If users do not expect | |||
that they will share information with an organization, it is unlikely to | that they will share information with an organization, it is unlikely to | |||
experience market pressure from users to protect the security and privacy | experience market pressure from users to protect the security and privacy | |||
of their information. In practice, moreover, third parties may not | of their information. In practice, moreover, third parties may not | |||
experience sufficient market pressure from first parties since | experience sufficient market pressure from first parties since | |||
increasingly third parties do not have a direct business relationship with | increasingly third parties do not have a direct business relationship with | |||
the first party websites they appear on. We therefore require a greater | the first party websites they appear on. We therefore require a greater | |||
degree of user control over information sharing with such organizations. | degree of user control over information sharing with such organizations. | |||
Last, third parties are often in a position to collect a sizable | Last, third parties are often in a position to collect a sizeable | |||
proportion of a user's browsing history - information that can be uniquely | 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 | sensitive and easily associated with a user's identity. We wish to provide | |||
user control over such information flows. | user control over such information flows. | |||
We recognize that, unlike with a bright-line rule, there can be close | 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 | 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 | 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 | 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. | first party or third party, with few cases of ambiguity in practice. | |||
skipping to change at line 489 | skipping to change at line 655 | |||
whether a user has intentionally interacted with a party, it must consider | 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 | 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 | website is in the best position to understand its users' expectations. We | |||
therefore impose the burden of understanding user expectations on the | 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 | 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 | user expectations and protecting user privacy. If the standard is | |||
insufficiently protective, ordinary users have limited recourse; if the | insufficiently protective, ordinary users have limited recourse; if the | |||
standard imposes excessive limits, websites retain the safety valve of | standard imposes excessive limits, websites retain the safety valve of | |||
explicitly asking for user permission. | explicitly asking for user permission. | |||
3.3.1.2.1.1 Common Examples and Use Cases | 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 | 1. A user accesses an Example News article. The page includes an | |||
advertisement slot, which loads content from many companies other than | advertisement slot, which loads content from many companies other than | |||
Example News. Those companies are third parties. | Example News. Those companies are third parties. | |||
2. A user accesses an Example News article. The page includes an | 2. A user accesses an Example News article. The page includes an | |||
analytics script that is hosted by Example Analytics, an analytics | analytics script that is hosted by Example Analytics, an analytics | |||
service. Example Analytics is a third party. | service. Example Analytics is a third party. | |||
3. A user accesses an Example News article. It includes a social sharing | 3. A user accesses an Example News article. It includes a social sharing | |||
widget from Example Social, a popular social network. Example Social | widget from Example Social, a popular social network. Example Social | |||
is a third party. | is a third party. | |||
4. A user visits Example Diary, which is hosted by the free blogging | 4. A user visits Example Diary, which is hosted by the free blogging | |||
service Example Blog Hosting but located at examplediary.com. Example | service Example Blog Hosting but located at examplediary.com. Example | |||
Blog Hosting is a third party. | Blog Hosting is a third party. | |||
5. A user launches Example Application, an app on a mobile device. The | 5. A user launches Example Application, an app on a mobile device. The | |||
app includes a library from Example Advertising Network that displays | app includes a library from Example Advertising Network that displays | |||
ads. Example Advertising Network is a third party. | 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.3.1.2.2 Multiple First Parties | 3.5.1.2.2 Multiple First Parties | |||
While this is not closed the idea there may be multiple first parties on | Note | |||
one webpage based on meaningful interaction has little controversy, with | ||||
some discussion around the margins about details of co-run sites. | There has been some disagreement within the group over how many first | |||
parties there should be in any one network interaction. These three | ||||
options lay out the range of possibilities; the first is text that has | ||||
been before the group for some time, the others are new. | ||||
There will almost always be only one party that the average user would | There will almost always be only one party that the average user would | |||
expect to communicate with: the provider of the website the user has | expect to communicate with: the provider of the website the user has | |||
visited. But, in rare cases, users may expect that a website is provided | 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 | by more than one party. For example, suppose Example Sports, a well known | |||
sports league, collaborates with Example Streaming, a well known streaming | sports league, collaborates with Example Streaming, a well known streaming | |||
video website, to provide content at | video website, to provide content at | |||
www.examplesportsonexamplestreaming.com. The website is prominently | www.examplesportsonexamplestreaming.com. The website is prominently | |||
advertised and branded as being provided by both Example Sports and | advertised and branded as being provided by both Example Sports and | |||
Example Streaming. An ordinary user who visits the website may recognize | Example Streaming. An ordinary user who visits the website may recognize | |||
that it is operated by both Example Sports and Example Streaming. | that it is operated by both Example Sports and Example Streaming. | |||
3.3.1.2.3 User Interaction with Third-Party Content | There can be only one first party in any network transaction absent | |||
additional meaningful interaction with otherwise third party content on | ||||
the webpage. The first party is the registrant and operator of the domain | ||||
that the user intentionally communicated with. | ||||
If a user intends to communicate with a party that utilizes a different | ||||
party as a platform, then both parties are first parties in the network | ||||
transaction. | ||||
Example: ExampleSports franchise has a dedicated page on a ExampleSocial. | ||||
When a user visits this dedicated page, both ExampleSports and | ||||
ExampleSocial are first parties. | ||||
3.5.1.2.3 User Interaction with Third-Party Content | ||||
A party may start out as a third party but become a first party later on, | A party may start out as a third party but become a first party later on, | |||
after a user interacts with it. If content from a third party is embedded | after a user interacts with it. If content from a third party is embedded | |||
on a first party page, the third party may become an additional first | on a first party page, the third party may become an additional first | |||
party if it can infer with high probability that the average user | party if it can infer with high probability that the average user | |||
knowingly and intentionally communicated with it. If a user merely moused | knowingly and intentionally communicated with it. If a user merely moused | |||
over, closed, or muted third-party content, the party would not be able to | over, closed, or muted third-party content, the party would not be able to | |||
draw such an inference. | draw such an inference. | |||
3.3.1.2.3.1 Examples and Use Cases | Examples | |||
Little controversy, with some discussion of adding examples of co-run | ||||
sites unresolved by publication. Some think branding covers this case; | ||||
others want to add an additional example: A user visits a contest website | ||||
hosted by two parties (clearly branded): Company X and Company Y. The page | ||||
includes links to both parties legal information (Privacy Policy, Terms of | ||||
Service) with explanation that both parties are first parties on this | ||||
website. | ||||
Example: Example Weather offers an unbranded weather widget that is | ||||
embedded into websites, including Example News. The widget contains small | ||||
links to Example Weather's website and privacy policy. A user visits | ||||
Example News and scrolls through the weekly forecast in the Example | ||||
Weather widget. | ||||
Discussion: Example Weather is a third party. The user has interacted with | ||||
Example Weather's widget, but an ordinary user would not expect that | ||||
scrolling through the widget involves communicating with Example News. | ||||
Example: Example Social, a popular social network, hosts a social sharing | ||||
button that other websites can embed. The button is colored and styled in | ||||
the same fashion as Example Social's website, contains descriptive text | ||||
that is specific to Example Social, includes Example Social's logo, and | ||||
very frequently appears on Example Social's website. Example News embeds | ||||
the Example Social button, and a user clicks it. | ||||
Discussion: Example Social is a first party once the user clicks its | 1. Example Weather offers an unbranded weather widget that is embedded | |||
embedded social sharing button. The average user would understand that by | into websites, including Example News. The widget contains small links | |||
clicking the button she is communicating with Example Social. | to Example Weather's website and privacy policy. A user visits Example | |||
News and scrolls through the weekly forecast in the Example Weather | ||||
widget. Example Weather is a third party. The user has interacted with | ||||
Example Weather's widget, but an ordinary user would not expect that | ||||
scrolling through the widget involves communicating with Example News. | ||||
2. Example Social, a popular social network, hosts a social sharing | ||||
button that other websites can embed. The button is colored and styled | ||||
in the same fashion as Example Social's website, contains descriptive | ||||
text that is specific to Example Social, includes Example Social's | ||||
logo, and very frequently appears on Example Social's website. Example | ||||
News embeds the Example Social button, and a user clicks it. Example | ||||
Social is a first party once the user clicks its embedded social | ||||
sharing button. The average user would understand that by clicking the | ||||
button she is communicating with Example Social. | ||||
3.3.2 Option 2: Discoverable Ownership and Affiliates | 3.5.2 Option 2: First and Third Parties | |||
This language merely rehashes the discoverable affiliate definition of | First Party is the party that owns the Web site or has control over the | |||
"party" and does not provide guidance as to when a party is operating on a | Web site the consumer visits. A First Party also includes the owner of a | |||
first-party or third-party basis. This language would be better | widget, search box or similar service with which a consumer interacts. | |||
incorporated as non-normative discussion under the Option 2: Discoverable | ||||
Affiliates definition of party above. | ||||
3.3.2.1 Definitions | Note | |||
A First Party is the entity that owns the Web site or has Control over the | If a user merely mouses over, closes, or mutes third-party content, that | |||
Web site the consumer visits. A First Party also includes the owner of a | is not sufficient interaction to constitute a First Party widget | |||
widget, search box or similar service with which a consumer interacts, | interaction. | |||
even if such First Party does not own or have Control over the Web site | ||||
where the widget or services are displayed to the consumer. | ||||
A First Party includes Affiliates of that First Party, but only to the | A Third Party is any party other than a First Party, Service Provider, or | |||
extent that the Affiliate is (1) an entity that Controls, is Controlled | the user. It is possible to have multiple first parties on a single page | |||
by, or us under common Control with, the First Party; or (2) an entity | but each party must provide clear branding and a link to their respective | |||
where the relationship to the First Party is clear to consumers through | privacy policy (co-branded experience). | |||
co-branding or similar means. | ||||
A First Party must make reasonable efforts to disclose, in a manner easily | 3.6 Unlinkable Data | |||
discoverable by Users, its ownership or Control of a site or service, such | ||||
as through branding on the site or service, disclosures in the privacy | ||||
policy, or terms of use linked to that site or service. | ||||
Control of an entity means that one entity (1) is under significant common | Note | |||
ownership or operational control of the other entity, or (2) has the power | ||||
to exercise a controlling influence over the management or policies of the | ||||
other entity. In addition, for an entity to be under the Control of | ||||
another entity and be treated as a First Party under this standard, the | ||||
entity must also adhere to DNT standard in this specification. | ||||
3.4 Data Controller and Processor | There is debate about whether to use the terms unlinkable, unlinked, or | |||
unidentified to describe this type of data. | ||||
ISSUE-14 : How does what we talk about with 1st/3rd party relate to | 3.6.1 Option 1: Unlinkable Data | |||
European law about data collector vs data processor? [PENDING REVIEW] | ||||
The text that follows may move elsewhere or may ultimately be removed from | A party render a dataset unlinkable when it | |||
the document. | 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. | ||||
For the EU, the outsourcing scenario is clearly regulated. In the current | 3.6.2 Option 2: Unlinkable Data | |||
EU Directive 95/46/EC, but also in the suggested regulation reforming the | ||||
data protection regime, an entity using or processing data is subject to | ||||
data protection law. A First Party (EU: data controller) is an entity or | ||||
multiple entities (EU: joint data controller) who determines the purposes, | ||||
conditions and means of the data processing will be the data controller. A | ||||
service provider (EU: data processor) is an entity with a legal | ||||
contractual relation to the Data Controller. The Service Provider does | ||||
determine the purposes, conditions and means of the data processing, but | ||||
processes data on behalf of the controller. The data processor acts on | ||||
behalf of the data controller and is a separate legal entity. An entity | ||||
acting as a first party and contracting services of another party is | ||||
responsible for the overall processing. A third party is an entity with no | ||||
contractual relation to the Data Controller and no specific legitimacy or | ||||
authorization in processing personal data. If the third party has own | ||||
rights and privileges concerning the processing of the data collected by | ||||
the first party, it isn't a data processor anymore and thus not covered by | ||||
exemptions. This third party is then considered as a second data | ||||
controller with all duties attached to that status. As the pretensions of | ||||
users are based on law, they apply to first and third party alike unless | ||||
the third party acts as a mere data processor. | ||||
3.5 Network Interaction | A dataset is unlinkable when there is a high probability that it contains | |||
only information that could not be linked to a particular user, user | ||||
agents, or device by a skilled analyst. A party renders a dataset | ||||
unlinkable when either: | ||||
1. it publicly publishes information that is sufficiently detailed for a | ||||
skilled analyst to evaluate the implementation, or | ||||
2. ensure that the dataset is at least 1024-unlinkable. | ||||
3.5.1 Definition | 3.7 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. | |||
3.5.2 Non-Normative Discussion | Non-normative explanatory text: Determination of a party's status is | |||
limited to a single interaction because a party's status may be affected | ||||
Determination of a party's status is limited to a single interaction | by time, context, or any other factor that influences user expectations. | |||
because a party's status may be affected by time, context, or any other | ||||
factor that influences user expectations. | ||||
3.6 Transactional data | ||||
Transactional data is information about the user's interactions with | 3.8 Data collection, retention, use, and sharing | |||
various websites, services, or widgets which could be used to create a | ||||
record of a user's system information, online communications, transactions | ||||
and other activities, including websites visited, pages and ads viewed, | ||||
purchases made, etc. | ||||
3.7 Data collection, retention, use, and sharing | Note | |||
The following text consists of proposed text that is meant to address | We have not had time to substantially edit the definitions of collection | |||
ISSUE-16. This language is currently being actively debated. | 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 the data comes within its control. | |||
2. A party "retains" data if data remains within a party's control. | 2. A party "retains" data if data remains within a party's control beyond | |||
the scope of the current interaction. | ||||
3. A party "uses" data if the party processes the data for any purpose | 3. A party "uses" data if the party processes the data for any purpose | |||
other than storage. | other than storage or merely forwarding it to another party. | |||
4. A party "shares" data if the party enables another party to collect | 4. A party "shares" data if the party enables another party to receive or | |||
the data. | access that data. | |||
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 Tracking | 3.8.1 Exception for unknowing collection, retention, and use | |||
We are still working through how, or if, to define tracking. Some suggest | A party may receive, retain, and use data as otherwise prohibited by this | |||
the phrase "cross-site tracking" only. We will need to ensure both final | standard, so long as is unaware of such information practices and has made | |||
recommendations use the same terms in the same way. | reasonable efforts to understand its information practices. If a party | |||
learns that it possesses information in violation of this standard, it | ||||
must delete that information at the earliest practical opportunity. | ||||
3.8.1 Option 1: Non-first Party Identifiers | 3.9 Tracking | |||
Note | ||||
The term "tracking" is not used in the document. This section is likely to | ||||
be deleted, and the issues will be addressed in the definitions of | ||||
"collection" and "unlinkable" above. | ||||
Issue 117: Terms: tracking v. cross-site tracking | ||||
3.9.1 Option 1: Non-first Party Identifiers | ||||
Note | ||||
Concerns with this section include undefined term "user data" plus as | Concerns with this section include undefined term "user data" plus as | |||
written, this may apply more broadly than the authors intended | written, this may apply more broadly than the authors intended | |||
Tracking is the collection or use of user data via either a unique | Tracking is the collection or use of user data via either a unique | |||
identifier or a correlated set of data points being used to approximate a | identifier or a correlated set of data points being used to approximate a | |||
unique identifier, in a context other than "first party" as defined in | unique identifier, in a context other than "first party" as defined in | |||
this document. This includes: | this document. This includes: | |||
1. a party collecting data across multiple websites, even if it is a | 1. a party collecting data across multiple websites, even if it is a | |||
first party in one or more (but not all) of the multiple contexts | first party in one or more (but not all) of the multiple contexts | |||
2. a third party collecting data on a given website | 2. a third party collecting data on a given website | |||
3. a first party sharing user data collected from a DNT-on user with | 3. a first party sharing user data collected from a DNT:1 user with third | |||
third parties "after the fact". | parties "after the fact". | |||
Examples of tracking use cases include: | Examples of tracking use cases include: | |||
* personalized advertising | 1. personalized advertising | |||
* cross-site analytics or market research that has not been | 2. cross-site analytics or market research that has not been | |||
de-identified | de-identified | |||
* automatic preference sharing by social applications | 3. automatic preference sharing by social applications | |||
3.8.2 Option 2: Cross-site or Over Time | 3.9.2 Option 2: Cross-site or Over Time | |||
Tracking is defined as following or identifying a user, user agent, or | Tracking is defined as following or identifying a user, user agent, or | |||
device across multiple visits to a site (time) or across multiple sites | device across multiple visits to a site (time) or across multiple sites | |||
(space). | (space). | |||
Mechanisms for performing tracking include but are not limited to: | Mechanisms for performing tracking include but are not limited to: | |||
* assigning a unique identifier to the user, user agent, or device such | 1. assigning a unique identifier to the user, user agent, or device such | |||
that it will be conveyed back to the server on future visits; | that it will be conveyed back to the server on future visits; | |||
* personalizing references or referral information such that they will | 2. personalizing references or referral information such that they will | |||
convey the user, user agent, or device identity to other sites; | convey the user, user agent, or device identity to other sites; | |||
* correlating data provided in the request with identifying data | 3. correlating data provided in the request with identifying data | |||
collected from past requests or obtained from a third party; or, | collected from past requests or obtained from a third party; or, | |||
* combining data provided in the request with de-identified data | 4. combining data provided in the request with de-identified data | |||
collected or obtained from past requests in order to re-identify that | collected or obtained from past requests in order to re-identify that | |||
data or otherwise associate it with the user, user agent, or device. | 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 | A preference of "Do Not Track" means that the user does not want tracking | |||
to be engaged for this request, including any mechanism for performing | to be engaged for this request, including any mechanism for performing | |||
tracking, any use of data retained from prior tracking, and any retention | 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, | or sharing of data from this request for the purpose of future tracking, | |||
beyond what is necessary to enable: | beyond what is necessary to enable: | |||
1. the limited exemptions defined in this specification; | 1. the limited permitted uses defined in this specification; | |||
2. the first-party (and third-parties acting as the first-party) to | 2. the first-party (and third-parties acting as the first-party) to | |||
provide the service intentionally requested by the user; and | provide the service intentionally requested by the user; and | |||
3. other services for which the user has provided prior, specific, and | 3. other services for which the user has provided prior, specific, and | |||
informed consent. | informed consent. | |||
3.8.3 Option 3: Silence | 3.9.3 Option 3: Silence | |||
One proposal is not to define "tracking," but rather to list what is, or | One proposal is not to define "tracking," but rather to list what is, or | |||
is not, required and allowed in order to comply with the recommendation. | is not, required and allowed in order to comply with the recommendation. | |||
3.9 Consent | 3.10 Explicit and Informed Consent | |||
The term "affirmative, informed consent" is used throughout this document. | Note | |||
While this terminology may ultimately be modified, some options for | ||||
explaining the underlying idea are presented below: | ||||
ISSUE-69 : Should the spec say anything about minimal notice? (ie. don't | The spec currently envisions that users should consent to both the setting | |||
of a DNT preference as well as any user-granted exceptions. We have not | ||||
reached agreement on how precisely we need to define this term. | ||||
Issue 69: Should the spec say anything about minimal notice? (ie. don't | ||||
bury in a privacy policy) | bury in a privacy policy) | |||
3.9.1 Option 1 | 3.10.1 Option 1: Prescriptive | |||
"Affirmative, Informed Consent to be Tracked" means consent given by an | Explicit and informed choice must satisfy the following bright-line | |||
affirmative action such as clicking a consent box in response to a clear | requirements: | |||
and prominent request to ignore a "Do Not Track" setting that is distinct | 1. Actual presentation: The choice mechanism MUST be actually presented to | |||
and separate from any other notifications or requested permissions. | the user. It MUST NOT be on a linked page, such as a terms of service or | |||
privacy policy. | ||||
2. Clear Terms:The choice mechanism MUST use clear, non-confusing | ||||
technology. | ||||
3. Independent choice: The choice mechanism MUST be presented independent | ||||
of other choices. It MUST NOT be bundled with other user preferences. | ||||
4. No default permission: The choice MUST NOT have the user permission | ||||
selected by default. | ||||
3.9.2 Option 2 | 3.10.2 Option 2: Silence | |||
"Affirmative, Informed Consent to be Tracked" has been obtained when a | No definition, other than explicitly leaving the definition of consent to | |||
mechanism to provide for or facilitate the acquisition and storage of | local rules. | |||
permission to ignore the header has been made available to the user and | ||||
the user has meaningfully interacted with the mechanism in a way that | ||||
makes clear her intent to grant this permission. | ||||
3.9.3 Silence | 4. First Party Compliance | |||
The hope is that this option will ensure consistency with EU regulations; | Note | |||
it may not unless notice is included. | ||||
No definition, other than explicitly leaving the definition of consent to | This language is not consensus and must change. The parties are generally | |||
local rules. | 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. | ||||
3.10 Meaningful Interaction | If a First Party receives a network transaction to which a DNT:1 header is | |||
attached, First Parties may engage in their normal collection and use of | ||||
information. This includes the ability to customize the content, services, | ||||
and advertising in the context of the first party experience. | ||||
Wording needs polish to ensure it works with accessibility issues, but | The First Party must not pass information about this transaction to | |||
other than minor edits this is agreed upon. | non-service provider third parties who could not collect the data | |||
themselves under this Recommendation. | ||||
"Meaningful Interaction" with a widget or window initially presented on a | Issue 229: Draft crisp definition [of data append] | |||
third-party basis means clicking on such content (except to stop, close, | ||||
silence, or otherwise impair the rendering of such content) or otherwise | ||||
affirmatively engaging with the content in a manner that would reasonably | ||||
be interpreted to express an affirmative intention to interact with that | ||||
party. A user merely moving her cursor across the widget or window does | ||||
not constitute "meaningful interaction." | ||||
3.11 User | 5. User Agent Compliance | |||
A user is an individual human. When user-agent software accesses online | A user agent MUST offer a control to express a tracking preference to | |||
resources, whether or not the user understands or has specific knowledge | third parties. The control MUST communicate the user's preference in | |||
of a particular request, that request is made "by" the user. | accordance with the [TRACKING-DNT] recommendation and otherwise comply | |||
with that recommendation. A user agent MUST NOT express a tracking | ||||
preference for a user unless the user has given express and informed | ||||
consent to indicate a tracking preference. | ||||
3.12 User Agent | We do not specify how tracking preference choices are offered to the user | |||
or how the preference is enabled: each implementation is responsible for | ||||
determining the user experience by which a tracking preference is enabled. | ||||
For example, a user might select a check-box in their user agent's | ||||
configuration, install an extension or add-on that is specifically | ||||
designed to add a tracking preference expression, or make a choice for | ||||
privacy that then implicitly includes a tracking preference (e.g., | ||||
"Privacy settings: high"). Likewise, a user might install or configure a | ||||
proxy to add the expression to their own outgoing requests. | ||||
This specification uses the term user agent to refer to any of the various | Shane's proposal has suggested the additional compliance requirements of | |||
client programs capable of initiating HTTP requests, including but not | user agents: | |||
limited to browsers, spiders (web-based robots), command-line tools, | 1. The User Agent must also make available via a link in explanatory text | |||
native applications, and mobile apps [HTTP11]. | where DNT is enabled to provide more detailed information about DNT | |||
functionality | ||||
2. Any User Agent claiming compliance must have a functional | ||||
implementation of the browser exceptions in this specification | ||||
4. Compliance with an expressed tracking preference | Issue 150: DNT conflicts from multiple user agents | |||
4.1 Compliance by a first party | Issue 153: What are the implications on software that changes requests but | |||
does not necessarily initiate them? | ||||
This section consists of proposed text that is meant to address ISSUE-17: | 6. Third Party Compliance | |||
Data use by 1st Party, ISSUE-30: Will Do Not Track apply to offline | ||||
aggregating or selling of data?, ISSUE-54: Can first party provide | ||||
targeting based on registration information even while sending DNT, | ||||
ISSUE-59: Should the first party be informed about whether the user has | ||||
sent a DNT header to third parties on their site?, and ISSUE-91: Might | ||||
want prohibitions on first parties re-selling data to get around the | ||||
intent of DNT, and are pending discussion and [PENDING REVIEW]. | ||||
Additional text has been prepared for each of these five options. This | Note | |||
text will be added once an option has been decided upon. | ||||
The following are distinct options that have been proposed by members of | This section addresses the crux of what DNT is intended to accomplish, and | |||
the group: | as such, all of this section remains hotly debated. The specific language | |||
1. Only share if (1): If an operator of a first party domain stores a | is likely to change. See also alternative text proposed by Nick Doty. | |||
request to which a [DNT-ON] header is attached, that operator must not | ||||
share information about that stored communication to a third party, | ||||
outside of the exemptions as defined in this standard or specific | ||||
exceptions granted. | ||||
2. Only share if (2): For those users who send the DNT signal and have | ||||
not granted a site-specific exception to the first party, first | ||||
parties must NOT share user-specific data with third parties [This | ||||
will leave room for sharing with Agents/Service Providers/Vendors to | ||||
the 1st party &emdash; as well as sharing aggregate and anonymous data | ||||
with "others" (general reporting, for example).] | ||||
3. Do not remember: When DNT is enabled, a 1st party should treat each | ||||
session with a user as an entirely new session unless it has been | ||||
given permission to store his information and use it again. | ||||
4. Silence: This standard imposes no requirements on first-party | ||||
websites. A first-party website may take steps to protect user privacy | ||||
in responding to a Do Not Track request. | ||||
5. Do not circumvent: | ||||
1. Sharing of Data with a Third-Party Website: A first-party website | ||||
must not share data to a third-party website that the third-party | ||||
website could not collect itself under this standard. A | ||||
first-party website may otherwise transfer data to a third-party | ||||
website. | ||||
2. Additional Voluntary Measures: A first-party website may take | ||||
additional steps to protect user privacy in responding to a Do | ||||
Not Track request. | ||||
1. Example Voluntary Measures (Non-Normative) | ||||
3. Transfer of Data from a First-Party Website: If a third-party | ||||
website receives data from a first-party website, the data is | ||||
subject to the same collection, retention, sharing, and use | ||||
limitations under this standard as if the third-party website had | ||||
collected the data itself. | ||||
4.2 Intermediary compliance | If a third party receives a communication to which a DNT:1 header is | |||
attached: | ||||
This issue is being addressed in the [TRACKING-DNT] specification. | 1. that third party MUST NOT collect, share, or use information related | |||
to that communication outside of the permitted uses as defined within | ||||
this standard and any explicitly-granted exceptions, provided in | ||||
accordance with the requirements of this standard; | ||||
2. that third party MUST NOT use information about previous | ||||
communications in which it was a third party, outside of the permitted | ||||
uses as defined within this standard and any explicitly-granted | ||||
exceptions, provided in accordance with the requirements of this | ||||
standard; | ||||
3. that third party MAY delete information about previous communications | ||||
in which it was a third party. | ||||
4.3 Compliance by a third party | 6.1 Permitted Operational Uses for Third Parties and Service Providers | |||
This section consists of proposed text that is meant to address ISSUE-19 | Note | |||
and ISSUE-39 and is pending discussion and [PENDING REVIEW]. | ||||
4.3.1 General compliance | These are options that have been discussed in the group. While many have | |||
broad consensus within the group, some are debated both based on scope of | ||||
the draft and whether they should be permitted uses. There is also | ||||
substantial disagrement over the SCOPE of information that may be | ||||
collected, used, and retained for these purposes, most notably whether | ||||
persistent unique identifiers may be collected, used, and retained for | ||||
these purposes. | ||||
4.3.1.1 Option 1: Simple Formulation | If a third-party receives a communication to which a DNT:1 header is | |||
attached, that third party MAY nevertheless collect, use, and retain | ||||
information related to that communication for these permitted uses: | ||||
If the operator of a third-party domain receives a communication to which | * Short term collection and use, where information is not transmitted to | |||
a [DNT-ON] header is attached: | a third party or used to profile or personalize a user's experience; | |||
* Contextual content or ad delivery; | ||||
* Content or Ad Delivery Based on First Party Data | ||||
* Frequency Capping | ||||
* Financial Logging and Auditing | ||||
* Security and Fraud Prevention | ||||
* Aggregate Reporting | ||||
* Debugging | ||||
* Compliance With Local Laws and Public Purposes | ||||
1. that operator must not collect, share, or use information related to | As long as there is: | |||
that communication outside of the exemptions as defined within this | ||||
standard and any explicitly-granted exceptions, provided in accordance | ||||
with the requirements of this standard; | ||||
2. that operator must not use information about previous communications | ||||
in which the operator was a third party, outside of the explicitly | ||||
expressed exemptions as defined within this standard; | ||||
3. that operator [must not or should not] retain information about | ||||
previous communications in which the operator was a third party, | ||||
outside of the explicitly expressed exemptions as defined within this | ||||
standard. | ||||
4.3.1.2 Option 2: More Detailed Formulation | * No Secondary Use | |||
* Data Minimization and Transparency | ||||
* Reasonable Security | ||||
* No Personalization | ||||
The following consists of proposed text that is meant to address ISSUE-71 | These permitted uses and requirements are further discussed below. | |||
and is pending discussion and [PENDING REVIEW]. | ||||
ISSUE-71 : Does DNT also affect past collection or use of past collection | 6.1.1 Enumerated Uses | |||
of info? | ||||
1. When a third party receives a DNT signal, it must not relate | 6.1.1.1 Short Term Collection and Use | |||
additional data from that HTTP request to existing profiles associated | ||||
with that user-agent that are based on data that the third party has | ||||
previously collected across sites over time; this is except as | ||||
permitted by exemptions stated elsewhere in this specification | ||||
2. Three alternatives: | ||||
1. Additionally, the entity must not use identifiers that it can | ||||
determine were collected from the same user agent before the DNT | ||||
signal was received, except as permitted by exemptions, for as | ||||
long as it continues to receive a DNT signal from that | ||||
user-agent. | ||||
2. A third party must not associate collected data with either | ||||
previous or future user profiles. Any third party data collected | ||||
under operational purpose exemptions must NEVER be profiled | ||||
independently or associated with previous or future user | ||||
profiles. | ||||
3. When a third party receives a DNT signal, it must not retain data | ||||
from that HTTP request that could be associated with an existing | ||||
profile, except as permitted by exemptions stated elsewhere in | ||||
this specification. | ||||
3. The entity may take additional steps with respect to previously | ||||
collected DNXT data such as deleting data before its usual expiration. | ||||
However, as DNT signal affects only HTTP request that it accompanies | ||||
and may be modified by the user, it is not recommended that special | ||||
deletion take place without some notice to user(s). | ||||
Examples and use cases | Note | |||
1. User visits Site A, to which Ad Network B delivers advertisements. Ad | We have discussed allowing a N-week (anywhere from 1 week to 3 months) | |||
Network B has accumulated transactional information about User from | grace period where third parties could collect and use data, partly due to | |||
User's visits to Site A and other non-affiliated sites in the past. | concerns , partly as a compromise to the market research/aggregate | |||
However, User now sends DNT signal with HTTP request during this | reporting issue. We do not have consensus on this permitted use at this | |||
session on Site A. Ad Network B cannot add information from current | point. If we decide to allow this, we would need to add non-normative text | |||
HTTP request from Site A session to any profile it maintains on User. | explaining the rationale and providing examples. | |||
Since it must not collect and any data from this session and relate it | ||||
to previously collected data, Network B must regard and treat him like | ||||
completely unknown user to them, absent any exemptions or override | ||||
from user. | ||||
2. Same as above scenario. Based on transactional information collected | ||||
about User's visits to non-affiliated sites in the past, Ad Network B | ||||
has placed User into Technology Shopper Segment. Since Ad Network B | ||||
must not recognize User during sessions in which User is sending DNT | ||||
signal via that browser, it cannot deliver Technology Shopper | ||||
advertisement to User's browser, absent obtaining override from user. | ||||
Ad Network B may instead choose to deliver a random ad, an ad based on | ||||
the context of Site A, or an ad based on general location based on IP | ||||
address transmitted with HTTP. | ||||
4.3.2 Geolocation compliance by a third party | 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). | ||||
This section may move into, or have implications for, the section 3 | 6.1.1.2 Contextual Content or Ad Delivery | |||
definitions. | ||||
If the operator of a third-party domain receives a communication to which | Note | |||
a [DNT-ON] header is attached: | ||||
1. Geo-location information that is more granular than postal code is too | Note that it is not clear that this is in scope, per Shane; others | |||
granular. Geolocation data must not be used at any level more granular | disagree. Revisit whether contextual belongs in some place other than | |||
than postal code. Note that while the number of people living in a | permitted uses (potentially the definition of collection). | |||
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. | ||||
4.3.2.1 Non-Normative Discussion | 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. | ||||
It is acceptable to use data sent as part of this particular network | 6.1.1.2.1 Examples | |||
interaction when composing a response to a [DNT-ON] request, but it is not | ||||
acceptable to store that data any longer than needed to reply. For | ||||
instance, it would be appropriate to use an IP address to guess which | ||||
country a user is in, to avoid showing them an advertisement for products | ||||
or services unavailable where they live. | ||||
When using request-specific information to compose a reply, some levels of | This section is non-normative. | |||
detail may feel invasive to users, and may violate their expectations | ||||
about Do Not Track. These sorts of detailed assessments should be avoided. | ||||
4.3.2.2 Examples | 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. | ||||
Reasonable behavior | 6.1.1.3 Content or Ad Delivery Based on First Party Data | |||
A user visits you from an IP address which a general geo-IP | ||||
database suggests is in the NYC area, where it is 6pm on a Friday. | ||||
You choose to show an advertisement for theaters and restaurants | ||||
in the area. | ||||
Invasive behavior | Note | |||
A user visits you from an IP address which suggests that they are | ||||
in a particular ZIP+4, which has a distinctive demographic | ||||
profile. Their user-agent indicates that they are a Mac user, | ||||
further narrowing their expected profile. You serve them an ad for | ||||
business within a few blocks of them which specializes in items | ||||
which their expected profile indicates they may enjoy. | ||||
In this example, even though the decision about which ad to serve was | Note that it is not clear that this is in scope, per Shane; others | |||
based exclusively on request specific information, but was still tailored | disagree. Revisit whether contextual belongs in some place other than | |||
to a highly-specific user profile. In particular, the estimation of a | permitted uses (potentially the definition of collection). | |||
user's location to within a single ZIP+4 may make a user feel that they | ||||
are being followed closely, even if the decision was made on the fly, and | ||||
the information was only held ephemerally. | ||||
ISSUE-19 : Data collection / Data use (3rd party) | 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. | ||||
ISSUE-88 : different rules for impression of and interaction with | 6.1.1.3.1 Examples | |||
3rd-party ads/content | ||||
4.4 Cookie Syncing | This section is non-normative. | |||
The following consists of proposed text under review | 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. | ||||
ISSUE-32: Sharing of data between entities via cookie syncing / identity | 6.1.1.4 Frequency Capping | |||
brokering | ||||
4.4.1 Non-normative background | 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 a cookie syncing procedure a Demand-Side Platform (DSP) aim to match a | In Seattle, we discussed specifically limiting how data was stored for | |||
cookieXYZ (corresponding to its domain) to the cookieABC set by the Supply | frequency capping: | |||
Side Platform (SSP) for the same User-Agent U. Cookie syncing requires | ||||
that the SSP adds a 1x1 pixel from the DSP domain. The SSP has to pass the | ||||
string "cookieABC" corresponding to ids domain to the DSP through the URL | ||||
of this 1x1 pixel. The DSP parses the "cookieABC" in the URL and | ||||
associates it to the cookieXYZ for its domain. Once the cookies have been | ||||
matched, the DSP will be able to re-target U on the SSP affiliated sites. | ||||
The solution consists in not allowing cookie syncing when the SSP receives | Server-side frequency capping is allowed if the tracking identifier is | |||
DNT:ON. If it did not, the SSP may start the cookie syncing process but | only retained in a form that is unique to each super-campaign (e.g., | |||
the DSP must not synchronize the cookies if it received DNT:ON. The reason | one-way hashed with a campaign id) and does not include retention of the | |||
is that if the SSP publishes ads on a limited number of websites, the DSP | user's activity trail (page URIs on which the ads were delivered) aside | |||
would know that the client visited at least one of these websites. | from what is allowed for other permitted uses. | |||
4.4.2 Normative text | 6.1.1.4.1 Examples | |||
The operator of domain acting as a third party (SSP) on a website and | This section is non-normative. | |||
receiving [DNT-ON] must not load content from a second unaffiliated third | ||||
party domain (DSP) to transfer a user ID to this third party. | ||||
A third party receiving [DNT-ON] and a user ID through the URL loaded from | A user visits ExampleNews with DNT:1 enabled. ExamplesNews uses the third | |||
an unaffiliated entity acting as a third party must not associate the ID | party ExampleAds to serve content and advertisements on its site. | |||
of the cookie sent in the request to the user ID transmitted in the URL | ExampleAds is not an outsourcing partner of ExampleNews. ExampleAds has | |||
and must not collect or use other information related to that | previously shown the user an ad for ExampleCars fives times in the past | |||
communication and not covered by the 3rd party exemption. | 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. | ||||
Open issues: | 6.1.1.5 Financial Logging and Auditing | |||
1. This text does not cover Cross-Origin Resource Sharing (CORSE) and | Regardless of DNT signal, information may be collected, retained and used | |||
perhaps should. | for financial fulfillment purposes such as billing and audit compliance. | |||
2. Would rather not have discussion of specific technology, and isn't | This includes counting and verifying: | |||
this already prohibited? This section may be redundant. | ||||
3. Ad Exchanges use cookie synching for business purposes, including | ||||
third-party auditing to verify ad impressions. However, this might be | ||||
resolved with a service provider exemption. | ||||
4.5 Usage Exemptions | * 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 | ||||
This section outlines potential exemptions to the standard based on | One potential compromise on the unique identifier issue for logging would | |||
necessary business use. For all of these exemptions, the complying entity | be grandfather in existing contracts that require unique, cookie-based | |||
must make reasonable data minimization efforts to ensure that only the | counting. New contracts would not be able to require that ad networks use | |||
data necessary for the exempted purpose be retained. | cookies (or other unique identifiers) to uniquely count users who have | |||
DNT:1 enabled. | ||||
The following text consists of proposed text that is meant to address | 6.1.1.5.1 Examples | |||
ISSUE-23 , ISSUE-24 , ISSUE-25 , ISSUE-31 , ISSUE-34 , and ISSUE-49 and is | ||||
pending discussion and [PENDING REVIEW]. | ||||
Should we explicitly identify goals and use cases in order to evaluate | This section is non-normative. | |||
these exemptions? | ||||
4.5.1 Exemptions for operational use of data | Note | |||
This section consists of proposed text that is meant to address ISSUE-22 | Add examples for display verification, click verification, CPA, quality | |||
and is pending discussion and [PENDING REVIEW]. We have active discussions | measures | |||
in this area. | ||||
ISSUE-22 : Still have "operational use" of data (auditing of where ads are | 6.1.1.6 Security and Fraud Prevention | |||
shown, impression tracking, etc.) | ||||
4.5.1.1 Discussion | 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. | ||||
In order to preserve certain common and important data usages, while still | Note | |||
protecting consumer privacy concerns, it will be necessary to provide | ||||
operational purpose exemptions for necessary business activities when the | ||||
DNT signal is on. There are several key categories of data collection and | ||||
use that must remain intact such that web site operators who are (in the | ||||
vast majority) offering their services free of charge in exchange for | ||||
advertising on their properties. Proposed exemptions include: | ||||
1. Frequency Capping - A form of historical tracking to ensure the number | The more likely options at this point may be represented in Nick Doty's | |||
of times a user sees the same ad is kept to a minimum. Perhaps | proposed: | |||
related, sequential ad rotation. Withdrawn. | ||||
2. Financial Logging - Ad impressions and clicks (and sometimes | ||||
conversions) events are tied to financial transactions (this is how | ||||
online advertising is billed) and therefore must be collected and | ||||
stored for billing and auditing purposes. | ||||
3. 3rd Party Auditing - Online advertising is a billed event and there | ||||
are concerns with accuracy in impression counting and quality of | ||||
placement so 3rd party auditors provide an independent reporting | ||||
service to advertisers and agencies so they can compare reporting for | ||||
accuracy. | ||||
4. Security - From traditional security attacks to more elaborate | ||||
fraudulent activity, ad networks must have the ability to log data | ||||
about suspected bad actors to discern and filter their activities from | ||||
legitimate transactions. This information is sometimes shared across | ||||
3rd parties in cooperatives to help reduce the daisy-chain effect of | ||||
attacks across the ad ecosystem. | ||||
5. Contextual Content or Ad Serving: A third-party may collect and use | ||||
information contained with the user agent string (including IP address | ||||
and referrer url) to deliver content customized to that information. | ||||
6. Research / Market Analytics | ||||
7. Product Improvement, or, more narrowly, Debugging | ||||
Discussion is ongoing as to how to define these exemptions and whether or | To the extent reasonably necessary for protection of computers and | |||
not all should be included in an exemptions list. | networks and to detect ad or other fraud, third parties may engage in | |||
tracking. Use of graduated response is preferred. | ||||
4.5.2 Exemption for Outsourcing | or David Wainberg's proposed: | |||
This section consists of proposed text that is meant to address ISSUE-23 , | Parties may collect and use data in any way to the extent reasonably | |||
ISSUE-72 , ISSUE-73 and ISSUE-49 and are pending discussion and [PENDING | necessary for the detection and prevention of malicious or illegitimate | |||
REVIEW]. | activity. | |||
This section may be moved to the section titled "First Parties and Third | 6.1.1.6.1 Examples | |||
Parties" | ||||
ISSUE-49 : Third party as first party - is a third party that collects | This section is non-normative. | |||
data on behalf of the first party treated the same way as the first party? | ||||
4.5.2.1 Normative Discussion | Note | |||
A third-party site may operate as a first-party site if all the following | Add examples with and without outsourced parties | |||
conditions hold: | ||||
1. the third party's data collection, retention, and use practices comply | 6.1.1.7 Debugging | |||
with at least the requirements for first-parties; | ||||
2. the data collected by the third party is available only to the first | ||||
party, and the third party has no independent right to use the data; | ||||
3. the third party makes commitments that are consistent with compliance | ||||
with this standard and they do so in a form that is legally | ||||
enforceable (directly or indirectly) by the first party, individual | ||||
users, and regulators; data retention by the third party must not | ||||
survive the end of this legal enforceability; | ||||
4. the third party undertakes reasonable technical precautions to prevent | ||||
collecting [retention of?] data that could be correlated across first | ||||
parties. | ||||
4.5.2.2 Non-Normative Discussion | Regardless of DNT signal, information may be collected, retained and used | |||
for identifying and repairing errors that impair existing intended | ||||
functionality. | ||||
4.5.2.2.1 Overview | 6.1.1.7.1 Discussion | |||
The rationale for rule (2) is that we allow the third party to stand in | This section is non-normative. | |||
the first party's shoes - but go no further. The third party may not use | ||||
the data it collects for "product improvement," "aggregate analytics," or | ||||
any other purpose except to fulfill a request by a first party, where the | ||||
results are shared only with the first party. | ||||
Rule (3) allows for the possibility of more than one level of outsourcing. | 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. | ||||
In rule (4), one component of reasonable technical precautions will often | 6.1.1.7.2 Examples | |||
be using the same-origin policy to segregate information for each | ||||
first-party customer. | ||||
Note that any data collected by the third party that is used, or may be | This section is non-normative. | |||
used, in any way by any party other than the first party, is subject to | ||||
the requirements for third parties. | ||||
4.5.2.2.2 Examples and use cases | 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. | ||||
ExampleAnalytics collects analytic data for ExampleProducts Inc.. It | 6.1.1.8 Aggregate Reporting | |||
operates a site under the DNS analytics.exampleproducts.com. It collects | ||||
and analyzes data on visits to ExampleProducts, and provides that data | ||||
solely to ExampleProducts, and does not access or use it itself. | ||||
4.5.3 Exemption for unidentifiable data | 6.1.1.8.1 Option 1: Aggregate Reporting | |||
This section consists of proposed text that is meant to address ISSUE-34 | Regardless of DNT signal, information may be collected, retained and used | |||
and is pending discussion and [PENDING REVIEW]. | 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. | ||||
ISSUE-34 : Possible Exemption for aggregate analytics | 6.1.1.8.2 Option 2: Aggregate Reporting | |||
4.5.3.1 Normative Discussion | 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. | ||||
A third party may collect, retain, and use any information from a user or | 6.1.1.8.3 Option 3: No Aggregate Reporting | |||
user agent that, with high probability, could not be used to: | ||||
1. identify or nearly identify a user or user agent; or | There is no permitted use for aggregate reporting outside of the grace | |||
2. correlate the activities of a user or user agent across multiple | period described earlier. | |||
network interactions. | ||||
4.5.3.2 Non-Normative Discussion | Issue 25: Possible exception for research purposes | |||
4.5.3.2.1 Overview | 6.1.1.9 Compliance With Local Laws and Public Purposes | |||
Clarification is needed with regard to what is meant by the following text | Note | |||
This exemption (like all exemptions) may not be combined with other | The group has generally agreed that companies can collect and process data | |||
exemptions unless specifically allowed. A third party acting within the | as required by local law despite the DNT:1 signal and still comply with | |||
outsourcing exemption, for example, may not make independent use of the | this standard. We have also conceptually agreed that companies cannot | |||
data it has collected even though the use involves unidentifiable data. | 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. | ||||
A rule to the contrary would provide a perverse incentive for third | Regardless of DNT signal, information may be collected, retained and used | |||
parties to press all exemptions to the limit and then use the collected | for complying with local laws and public purposes, such as copyright | |||
data within this exemption. | protection and delivery of emergency services. | |||
A potential 'safe harbor' under this clause could be to retain only | 6.1.2 Additional Requirements for Permitted Uses | |||
aggregate counts, not per-transaction records. | ||||
4.5.3.2.2 Examples and use cases | In order to use the Permitted Uses outlined, a party must comply with | |||
these four requirements. | ||||
1. A third-party advertising network records the fact that it displayed | 6.1.2.1 No Secondary Uses | |||
an ad. | ||||
2. A third-party analytics service counts the number of times a popular | ||||
page was loaded. | ||||
4.5.4 Other issues raised around exemptions | Third Parties MUST NOT use data retained for permitted uses for | |||
non-permitted uses. | ||||
ISSUE-24 : Possible exemption for fraud detection and defense | 6.1.2.2 Data Minimization and Transparency | |||
ISSUE-25 : Possible exemption for research purposes | A third party MUST ONLY retain information for a Permitted Use for as long | |||
as is reasonably necessary for that use. Third parties MUST make | ||||
reasonable data minimization efforts to ensure that only the data | ||||
necessary for the permitted use is retained. A third party MUST provide | ||||
public transparency of their data retention period. The third party MAY | ||||
enumerate each individually if they vary across Permitted Uses. Once the | ||||
period of time for which you have declared data retention for a given use, | ||||
the data MUST NOT be used for that permitted use. After there are no | ||||
remaining Permitted Uses for given data, the data must be deleted or | ||||
rendered unlinkable. | ||||
The following consists of proposed text that is meant to address ISSUE-28 | Note | |||
and is pending discussion and [PENDING REVIEW]. | ||||
ISSUE-28 : Exemption for mandatory legal process | May be worthwhile to put some examples in around when it is or isn't a | |||
good idea to explain use, ie, Commonly Accepted Practices vs. security | ||||
data to address unique businesses | ||||
This specification is not intended to override applicable laws and | 6.1.2.3 Reasonable Security | |||
regulations. | ||||
Indeed, a party may take action contrary to the requirements of this | Third parties MUST use reasonable technical and organizational safeguards | |||
standard if compelled by applicable law. If compelled by applicable law to | to prevent further processing of data retained for Permitted Uses. While | |||
collect, retain, or transmit data despite receiving a DNT:1 signal for | physical separation of data maintained for permitted uses is not required, | |||
which there is no exemption, the party should notify affected users to the | best practices should be in place to ensure technical controls ensure | |||
extent practical and allowed by law. | access limitations and information security. Third parties SHOULD ensure | |||
that the access and use of data retained for Permitted Uses is auditable. | ||||
It should be noted that this allowance does not extend to the fulfillment | Note | |||
of a contractual obligation. | ||||
ISSUE-75 : How do companies claim exemptions and is that technical or not? | 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. | ||||
ISSUE-31 : Minimization &emdash; to what extent will minimization be | 6.1.2.4 No Personalization | |||
required for use of a particular exemption? (conditional exemptions) | ||||
ISSUE-92 : If data collection (even very specific with IP address, user | Outside of Security and Frequency Capping, data retained for Permitted | |||
agent, referrer) is time-limited, with very limited retention, is that | Uses MUST NOT be used to alter a specific user's online experience based | |||
still tracking? | on multi-site activity. | |||
ISSUE-89 : Does DNT mean at a high level: (a) no customization, users are | 6.1.2.5 No Persistent Identifiers | |||
seen for the first time, every time. (b) DNT is about data moving between | ||||
sites. | ||||
ISSUE-97: Re-direction, shortened URLs, click analytics &emdash; what kind | A third party may only collect, use, and retain for permitted uses | |||
of tracking is this? | information that a user agent necessarily shares with a web server when it | |||
communicates with the web server (e.g. IP address and User-Agent), and the | ||||
URL of the top-level page, communicated via a Referer header or other | ||||
means, unless the URL contains information that is not unlinkable (e.g. a | ||||
username or user ID). | ||||
5. Exceptions | A third party may not collect, use, or retain information that a web | |||
server could cause to not be sent but still be able to communicate with | ||||
the user agent (e.g. a cookie or a Request-URI parameter generated by the | ||||
user agent), except the URL of the top-level page, or any data added by a | ||||
network intermediary that the operator of a web server has actual | ||||
knowledge of (e.g. a unique device identifier HTTP header). | ||||
ISSUE-66 : Can user be allowed to consent to both third party and first | Note | |||
party to override general DNT? | ||||
ISSUE-93 : Should 1st parties be able to degrade a user experience or | The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement | |||
charge money for content based on DNT? | that permitted use data is not correlated to a unique cookie or other | |||
persistent identifier. This issue remains one of the biggest areas of | ||||
dispute in the working group, as the industry proposal allows for the use | ||||
of cookies and other unique identifiers by third parties despite a DNT:1 | ||||
instruction. | ||||
5.1 Introduction to exceptions | 6.2 Geolocation compliance by a third party | |||
For the purposes of this document, an exception is a user-granted override | Note | |||
of their default DNT status for one or more third parties within a given | ||||
first party context. | ||||
It is possible for first parties to request, and users to set, exceptions | Unclear whether this section reflects group consensus. | |||
to their default DNT status on a per-first party basis for the third | ||||
parties that the first party works with. The goal of this is to allow | ||||
first parties to communicate with their users about their options with | ||||
respect to DNT within the context of that first party's web pages. | ||||
Should Market Research be deemed an exception rather than an exemption? | Issue 39: Tracking of geographic data (however it's determined, or used) | |||
5.2 Opt-In to site-specific exceptions | If the operator of a third-party domain receives a communication to which | |||
a DNT:1 header is attached: | ||||
The following consists of proposed text and is pending discussion and | 1. Geo-location information that is more granular than postal code is too | |||
[PENDING REVIEW]. | 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. | ||||
When a DNT enabled user agent grants a site-specific exception, the site | 6.2.1 Discussion | |||
places a site-specific opt-in mechanism on the user agent allowing the | ||||
site to respond as a First Party. The DNT header must remain enabled so | ||||
that if the user returns to the site, both the user's general preference | ||||
for DNT and the site-specific exception will be clear. When seeking a | ||||
site-specific exception from the user, the site must describe to the user, | ||||
via a direct link from the exception page, all purposes for which the | ||||
tracking will be used. | ||||
5.3 Interaction with existing user privacy controls | This section is non-normative. | |||
As multiple systems may be setting, sending, and receiving DNT and/or | It is acceptable to use data sent as part of this particular network | |||
Opt-Out signals at the same time, it'll be important to ensure industry | interaction when composing a response to a DNT:1 request, but it is not | |||
and web browser vendors are on the same page with respect to honoring user | acceptable to store that data any longer than needed to reply. For | |||
choices in circumstances where "mixed signals" may be received. | instance, it would be appropriate to use an IP address to guess which | |||
country a user is in, to avoid showing them an advertisement for products | ||||
or services unavailable where they live. | ||||
When using request-specific information to compose a reply, some levels of | ||||
detail may feel invasive to users, and may violate their expectations | ||||
about Do Not Track. These sorts of detailed assessments should be avoided. | ||||
6.2.2 Examples | ||||
This section is non-normative. | ||||
Reasonable behavior: A user visits you from an IP address which a general | ||||
geo-IP database suggests is in the NYC area, where it is 6pm on a Friday. | ||||
You choose to show an advertisement for theaters and restaurants in the | ||||
area. | ||||
Invasive behavior: A user visits you from an IP address which suggests | ||||
that they are in a particular ZIP+4, which has a distinctive demographic | ||||
profile. Their user-agent indicates that they are a Mac user, further | ||||
narrowing their expected profile. You serve them an ad for business within | ||||
a few blocks of them which specializes in items which their expected | ||||
profile indicates they may enjoy. | ||||
In this example, even though the decision about which ad to serve was | ||||
based exclusively on request specific information, but was still tailored | ||||
to a highly-specific user profile. In particular, the estimation of a | ||||
user's location to within a single ZIP+4 may make a user feel that they | ||||
are being followed closely, even if the decision was made on the fly, and | ||||
the information was only held ephemerally. | ||||
6.3 User-Granted Exceptions | ||||
Note | ||||
Figure out which parts of UGE belong in which document. | ||||
The operator of a website may engage in practices otherwise described by | ||||
this standard if the user has given explicit and informed consent. This | ||||
consent may be obtained through the browser API defined in the companion | ||||
[TRACKING-DNT] document, or an operator of a website may also obtain | ||||
"out-of-band" consent to disregard a "Do Not Track" preference using a | ||||
different technology. If an operator is relying on "out of band" consent | ||||
to disregard a "Do Not Track" instruction, the operator must indicate this | ||||
consent to the user agent as described in the companion [TRACKING-DNT] | ||||
document. | ||||
6.3.1 Interaction with existing user privacy controls | ||||
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out | ||||
signals at the same time, it'll be important to ensure industry and web | ||||
browser vendors are on the same page with respect to honoring user choices | ||||
in circumstances where "mixed signals" may be received. | ||||
As a general principle, more specific settings override less specific | As a general principle, more specific settings override less specific | |||
settings. | settings. | |||
* No DNT Signal / No Opt-Out: Treat as DNT unset | 1. No DNT Signal / No Opt-Out: Treat as DNT unset | |||
* DNT Signal / No Opt-Out: Treat as DNT:1 | 2. DNT Signal / No Opt-Out: Treat as DNT:1 | |||
* Opt-Out / No DNT Signal: Treat as DNT:1 | 3. Opt-Out / No DNT Signal: Treat as DNT:1 | |||
* Opt-Out / DNT Exception: Treat as DNT:0 for that site; DNT Exception | 4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; | |||
is honored | DNT User-Granted Exception is honored | |||
NOTE: The above text will need to be modified to include the appropriate | 6.3.2 Logged In Transactions | |||
terminology as this is decided upon by the working group. For example, DNT | ||||
Exception would need to be replaced with "Site-Specific Exception" | ||||
depending on the outcome of that discussion. | ||||
ISSUE-83 : How do you opt out if already opted in? | Note | |||
ISSUE-67 : Should opt-back-in be stored on the client side? [Not sure this | Add note that we may be able to handle this section entirely within the | |||
doesn't belong in the technical spec] | consent definition, rather than calling it out; potentially thought an | |||
example in the consent section. Concern about UI creep. | ||||
5.4 Logged In | Issue 65: How does logged in and logged out state work | |||
ISSUE-65 : How does logged in and logged out state work | 6.4 Disregarding Non-Compliant User Agents | |||
5.4.1 Option 1: Logged In Honors DNT | Note | |||
If a user is logged into a first-party website and it receives a DNT:1 | this section is the topic of active debate. | |||
signal, the website must respect DNT:1 signal as a first party and should | ||||
handle the user login as it normally would. If a user is logged into a | ||||
third-party website, and the third party receives a DNT:1 signal, then it | ||||
must respect the DNT:1 signal unless it falls under an exemption described | ||||
in this document. | ||||
Example use cases: | Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly | |||
formed even if the third party does not believe that the DNT:1 header was | ||||
set with the explicit and informed consent of the user. | ||||
* A user with DNT:1 logs into a search service called "Searchy". Searchy | If the operator of a third-party domain has a good faith belief that a | |||
also operates advertisements on other websites. When the user is on a | user agent is sending a DNT:1 without the explicit and informed consent of | |||
news website, Searchy receives DNT:1, and it must respect it, as | the user, the operator MAY disregard the DNT:1 header and collect, use, | |||
Searchy is operating in a third-party context. | and retain information about the user as if no DNT signal had been sent. | |||
* A user with DNT:1 enabled visits a shopping website and logs in. The | If the operator disregards the DNT signal, the operator MUST signal to the | |||
shopping website continues to provide recommendations, order history, | user agent that it is disregarding the header as described in the | |||
etc. The shopping site includes third-party advertisements. Those | companion [TRACKING-DNT] document. | |||
third-parties continue to respect DNT:1. When the user purchases the | ||||
items in their basket, a third-party financial transaction service is | ||||
used. The user interacts with the third-party service, at which point | ||||
it becomes first-party and may use previously collected data. | ||||
* A user with DNT:1 visits a website (Website A) that uses a third-party | ||||
authentication service called "LogMeIn". The user logs into the site | ||||
with his LogMeIn credentials. The user has interacted with LogMeIn, | ||||
and now it can act as a first-party. Now the user vists Website B, | ||||
which also uses the LogMeIn service, but is branded differently than | ||||
Website A. LogMeIn must respect the DNT:1 signal until the user | ||||
chooses to interact with LogMeIn in order to log into Website B. | ||||
5.4.2 Option 2: Silence on Logged In | No provision on Disregarding Non-Compliant User Agents. | |||
No text on this topic at all, and let the existing rules work it out. | 6.5 Degrading User Experience for DNT:1 users | |||
5.5 Enforcement/Compliance | Note | |||
5.5.1 Normative discussion | We have consensus that it's fine to degrade the experience for DNT:1 | |||
transactions, but need to find the text. | ||||
Final wording awaits how the response is designed in the [TRACKING-DNT] | Issue 93: Should 1st parties be able to degrade a user experience or | |||
recommendation, but we agree upon the general direction below. | charge money for content based on DNT? | |||
In order to be in compliance with this specification, a party must make a | 6.6 Public Disclosure of Compliance | |||
public commitment that it complies with this standard. | ||||
5.5.2 Non-normative discussion | Note | |||
A "public commitment" may consist of a statement in a privacy policy, a | Final wording awaits how the response is designed in the TRACKING-DNT | |||
response header, a machine-readable tracking status resource at a | recommendation, but we agree upon the general direction below. | |||
well-known location, or any other reasonable means. This standard does not | ||||
require a specific form of "public commitment." | ||||
ISSUE-21 : Enable external audit of DNT compliance | In order to be in compliance with this specification, a third party must | |||
make a public commitment that it complies with this standard. A "public | ||||
commitment" may consist of a statement in a privacy policy, a response | ||||
header, a machine-readable tracking status resource at a well-known | ||||
location, or any other reasonable means. This standard does not require a | ||||
specific form of public commitment. | ||||
We have reviewed one audit proposal that we declined to adopt. We may | 6.6.1 Third Party Auditing | |||
include a smaller-scoped proposal in the future, or may drop auditing all | ||||
together. | 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), | |||
Rigo Wenning (W3C), and Shane Wiley (Yahoo!). | David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and | |||
Shane Wiley (Yahoo!). | ||||
The DNT header field is based on the original Do Not Track submission by | The DNT header field is based on the original Do Not Track submission by | |||
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. Internet 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). 13 March 2012. W3C Working Draft. (Work in progress.) URL: | (DNT). 2 October 2012. W3C Working Draft. (Work in progress.) URL: | |||
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ | http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/ | |||
B.2 Informative references | B.2 Informative references | |||
[KnowPrivacy] | [KnowPrivacy] | |||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | |||
2009. URL: | 2009. URL: | |||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | |||
End of changes. 239 change blocks. | ||||
817 lines changed or deleted | 1016 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/ |