tcs-wd3.txt | tcs-wd4.txt | |||
---|---|---|---|---|
W3C | W3C | |||
Tracking Compliance and Scope | Tracking Compliance and Scope | |||
W3C Working Draft 02 October 2012 | W3C Working Draft 30 April 2013 | |||
This version: | This version: | |||
http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/ | http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/ | |||
Latest published version: | Latest published version: | |||
http://www.w3.org/TR/tracking-compliance/ | http://www.w3.org/TR/tracking-compliance/ | |||
Latest editor's draft: | Latest editor's draft: | |||
http://www.w3.org/2011/tracking-protection/drafts/tracking-complian ce.html | http://www.w3.org/2011/tracking-protection/drafts/tracking-complian ce.html | |||
Previous version: | Previous version: | |||
http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ | http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/ | |||
Editors: | Editors: | |||
Justin Brookman, CDT | Justin Brookman, CDT | |||
Sean Harvey, Google | ||||
Erica Newland, CDT | ||||
Heather West, Google | Heather West, Google | |||
Sean Harvey, Google (until June 2012) | ||||
Erica Newland, CDT (until May 2012) | ||||
Copyright (c) 2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C | Copyright (c) 2013 W3C(R) (MIT, ERCIM, Keio, Beihang), All Rights | |||
liability, trademark and document use rules apply. | Reserved. W3C liability, trademark and document use rules apply. | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
Abstract | Abstract | |||
This specification defines the meaning of a Do Not Track (DNT) preference | This specification defines the meaning of a Do Not Track (DNT) preference | |||
and sets out practices for websites to comply with this preference. | and sets out practices for websites to comply with this preference. | |||
Status of This Document | Status of This Document | |||
This section describes the status of this document at the time of its | This section describes the status of this document at the time of its | |||
publication. Other documents may supersede this document. A list of | publication. Other documents may supersede this document. A list of | |||
current W3C publications and the latest revision of this technical report | current W3C publications and the latest revision of this technical report | |||
can be found in the W3C technical reports index at http://www.w3.org/TR/. | can be found in the W3C technical reports index at http://www.w3.org/TR/. | |||
This document is a snapshot of live discussions within the Tracking | This document is a snapshot of ongoing discussions within the Tracking | |||
Protection Working Group. It does not yet capture all of our work. For | Protection Working Group. Text present or not present in this document | |||
example, we have issues that are [PENDING REVIEW] with complete text | does not determine consensus within the Working Group; discussions and | |||
proposals that have not yet made it into this draft. Text in blue boxes | debates are ongoing. Text in option boxes (highlighted with light blue | |||
presents multiple options the group is considering. Options included in | background color) present options that the group is currently considering, | |||
this draft should not be read as limitations on the potential outcome, but | particularly where consensus is known to be lacking, and should be read as | |||
rather simply as possible options that are currently under consideration | a set of proposals rather than as limitations on the potential outcome. | |||
by the working group. This draft is substantially revised from the | Members of the Working Group wish to emphasize that this draft is a work | |||
previous Working Draft. An issue tracking system is available for | in progress and not a decided outcome or guaranteed direction for future | |||
recording raised, open, pending review, closed, and postponed issues | versions of this document. | |||
regarding this document. | ||||
This draft is substantially revised from the previous Working Draft; much | ||||
non-normative text has been removed to provide clarity for the reader and | ||||
many options have been condensed by the editors and participants in the | ||||
group. Non-normative examples or appendices may be added in subsequent | ||||
revisions. An issue tracking system is available for recording raised, | ||||
open, pending review, closed, and postponed issues regarding this | ||||
document. | ||||
This document was published by the Tracking Protection Working Group as a | This document was published by the Tracking Protection Working Group as a | |||
Working Draft. This document is intended to become a W3C Recommendation. | Working Draft. This document is intended to become a W3C Recommendation. | |||
If you wish to make comments regarding this document, please send them to | If you wish to make comments regarding this document, please send them to | |||
public-tracking@w3.org (subscribe, archives). All feedback is welcome. | public-tracking@w3.org (subscribe, archives). All comments are welcome. | |||
Publication as a Working Draft does not imply endorsement by the W3C | Publication as a Working Draft does not imply endorsement by the W3C | |||
Membership. This is a draft document and may be updated, replaced or | Membership. This is a draft document and may be updated, replaced or | |||
obsoleted by other documents at any time. It is inappropriate to cite this | obsoleted by other documents at any time. It is inappropriate to cite this | |||
document as other than work in progress. | document as other than work in progress. | |||
This document was produced by a group operating under the 5 February 2004 | This document was produced by a group operating under the 5 February 2004 | |||
W3C Patent Policy. W3C maintains a public list of any patent disclosures | W3C Patent Policy. W3C maintains a public list of any patent disclosures | |||
made in connection with the deliverables of the group; that page also | made in connection with the deliverables of the group; that page also | |||
includes instructions for disclosing a patent. An individual who has | includes instructions for disclosing a patent. An individual who has | |||
skipping to change at line 80 | skipping to change at line 87 | |||
section 6 of the W3C Patent Policy. | section 6 of the W3C Patent Policy. | |||
Table of Contents | Table of Contents | |||
* 1. Introduction | * 1. Introduction | |||
* 2. Scope and Goals | * 2. Scope and Goals | |||
* 3. Definitions | * 3. Definitions | |||
* 3.1 User | * 3.1 User | |||
* 3.2 User Agent | * 3.2 User Agent | |||
* 3.3 Party | * 3.3 Party | |||
* 3.3.1 Option 1 | * 3.4 Service Providers | |||
* 3.3.2 Option 2 | * 3.5 First Party | |||
* 3.4 Service Providers/Outsourcers | * 3.5.1 Multiple First Parties | |||
* 3.4.1 Option 1: Service Provider/Outsourcer Definition | * 3.6 Third Party | |||
* 3.4.1.1 Non-Normative | * 3.7 Deidentified Data | |||
* 3.4.1.2 Technical Precautions | * 3.8 Network Transaction | |||
* 3.4.1.3 Non-Normative Discussion | * 3.9 Data collection, retention, use, and sharing | |||
* 3.4.1.3.1 Siloing in the Browser | * 3.9.1 Exception for unknowing collection, retention, and use | |||
* 3.4.1.3.1.1 Same-Origin Policy | * 3.10 Tracking | |||
* 3.4.1.3.1.2 Cookie Path Attribute | * 3.11 Explicit and Informed Consent | |||
* 3.4.1.3.1.3 Storage Key | ||||
* 3.4.1.3.2 Siloing in the Backend | ||||
* 3.4.1.3.2.1 Encryption Keys | ||||
* 3.4.1.3.2.2 Access Controls | ||||
* 3.4.1.3.2.3 Access Monitoring | ||||
* 3.4.1.3.3 Retention in the Backend | ||||
* 3.4.1.4 Internal Practices | ||||
* 3.4.1.4.1 Non-Normative Discussion | ||||
* 3.4.1.4.1.1 Policy | ||||
* 3.4.1.4.1.2 Training | ||||
* 3.4.1.4.1.3 Supervision and Reporting | ||||
* 3.4.1.4.1.4 Auditing | ||||
* 3.4.1.5 Use Direction | ||||
* 3.4.1.6 First Party or Third Party Requirements | ||||
* 3.4.1.6.1 Representation | ||||
* 3.4.1.6.2 Contract | ||||
* 3.4.2 Option 2: Service Provider/Outsourcer Definition | ||||
* 3.4.3 Option 3: Service Provider/Outsourcer Definition | ||||
* 3.5 First and Third Parties | ||||
* 3.5.1 Option 1: First and Third Parties | ||||
* 3.5.1.1 Definitions | ||||
* 3.5.1.2 Discussion | ||||
* 3.5.1.2.1 Overview | ||||
* 3.5.1.2.2 Multiple First Parties | ||||
* 3.5.1.2.3 User Interaction with Third-Party | ||||
Content | ||||
* 3.5.2 Option 2: First and Third Parties | ||||
* 3.6 Unlinkable Data | ||||
* 3.6.1 Option 1: Unlinkable Data | ||||
* 3.6.2 Option 2: Unlinkable Data | ||||
* 3.7 Network Transaction | ||||
* 3.8 Data collection, retention, use, and sharing | ||||
* 3.8.1 Exception for unknowing collection, retention, and use | ||||
* 3.9 Tracking | ||||
* 3.9.1 Option 1: Non-first Party Identifiers | ||||
* 3.9.2 Option 2: Cross-site or Over Time | ||||
* 3.9.3 Option 3: Silence | ||||
* 3.10 Explicit and Informed Consent | ||||
* 3.10.1 Option 1: Prescriptive | ||||
* 3.10.2 Option 2: Silence | ||||
* 4. First Party Compliance | * 4. First Party Compliance | |||
* 4.1 Additional/Alternative First Party Compliance Requirements | ||||
* 4.1.1 Explanation | ||||
* 5. User Agent Compliance | * 5. User Agent Compliance | |||
* 6. Third Party Compliance | * 6. Third Party Compliance | |||
* 6.1 Permitted Operational Uses for Third Parties and Service | * 6.1 Geolocation compliance by a third party | |||
Providers | * 6.2 Permitted Operational Uses for Third Parties | |||
* 6.1.1 Enumerated Uses | * 6.2.1 Global Requirements for Permitted Uses | |||
* 6.1.1.1 Short Term Collection and Use | * 6.2.1.1 No Secondary Uses | |||
* 6.1.1.2 Contextual Content or Ad Delivery | * 6.2.1.2 Data Minimization and Transparency | |||
* 6.1.1.2.1 Examples | * 6.2.1.3 Reasonable Security | |||
* 6.1.1.3 Content or Ad Delivery Based on First Party | * 6.2.1.4 No Personalization | |||
* 6.2.1.5 No Persistent Identifiers | ||||
* 6.2.2 Enumerated Permitted Uses | ||||
* 6.2.2.1 Short Term Collection and Use | ||||
* 6.2.2.2 Contextual Content or Ad Delivery | ||||
* 6.2.2.3 Content or Ad Delivery Based on First Party | ||||
Data | Data | |||
* 6.1.1.3.1 Examples | * 6.2.2.4 Frequency Capping | |||
* 6.1.1.4 Frequency Capping | * 6.2.2.5 Financial Logging and Auditing | |||
* 6.1.1.4.1 Examples | * 6.2.2.6 Security and Fraud Prevention | |||
* 6.1.1.5 Financial Logging and Auditing | * 6.2.2.7 Debugging | |||
* 6.1.1.5.1 Examples | * 6.2.2.8 Audience Measurement | |||
* 6.1.1.6 Security and Fraud Prevention | * 6.2.2.9 Compliance With Local Laws and Public Purposes | |||
* 6.1.1.6.1 Examples | ||||
* 6.1.1.7 Debugging | ||||
* 6.1.1.7.1 Discussion | ||||
* 6.1.1.7.2 Examples | ||||
* 6.1.1.8 Aggregate Reporting | ||||
* 6.1.1.8.1 Option 1: Aggregate Reporting | ||||
* 6.1.1.8.2 Option 2: Aggregate Reporting | ||||
* 6.1.1.8.3 Option 3: No Aggregate Reporting | ||||
* 6.1.1.9 Compliance With Local Laws and Public Purposes | ||||
* 6.1.2 Additional Requirements for Permitted Uses | ||||
* 6.1.2.1 No Secondary Uses | ||||
* 6.1.2.2 Data Minimization and Transparency | ||||
* 6.1.2.3 Reasonable Security | ||||
* 6.1.2.4 No Personalization | ||||
* 6.1.2.5 No Persistent Identifiers | ||||
* 6.2 Geolocation compliance by a third party | ||||
* 6.2.1 Discussion | ||||
* 6.2.2 Examples | ||||
* 6.3 User-Granted Exceptions | * 6.3 User-Granted Exceptions | |||
* 6.3.1 Interaction with existing user privacy controls | * 6.3.1 Interaction with existing user privacy controls | |||
* 6.3.2 Logged In Transactions | * 6.4 Exception for Deidentified Data | |||
* 6.4 Disregarding Non-Compliant User Agents | * 6.5 Disregarding Non-Compliant User Agents | |||
* 6.5 Degrading User Experience for DNT:1 users | ||||
* 6.6 Public Disclosure of Compliance | * 6.6 Public Disclosure of Compliance | |||
* 6.6.1 Third Party Auditing | ||||
* A. Acknowledgements | * A. Acknowledgements | |||
* B. References | * B. References | |||
* B.1 Normative references | * B.1 Normative references | |||
* B.2 Informative references | ||||
1. Introduction | 1. Introduction | |||
Note | Note | |||
This introduction will be re-worked after details of substantive text is | The introduction will be re-worked after details of substantive text is | |||
closer to being finalized. | closer to being finalized. | |||
The World Wide Web (WWW, or Web) consists of millions of sites | ||||
interconnected through the use of hypertext. Hypertext provides a simple, | ||||
page-oriented view of a wide variety of information that can be traversed | ||||
by selecting links, manipulating controls, and supplying data via forms | ||||
and search dialogs. A Web page is usually composed of many different | ||||
information sources beyond the initial resource request, including | ||||
embedded references to stylesheets, inline images, javascript, and other | ||||
elements that might be automatically requested as part of the rendering or | ||||
behavioral processing defined for that page. | ||||
Each of the hypertext actions and each of the embedded resource references | ||||
might refer to any site on the Web, leading to a seamless interaction with | ||||
the user even though the pages might be composed of information requested | ||||
from many different and possibly independent Web sites. From the user's | ||||
perspective, they are simply visiting and interacting with a single brand | ||||
-- the first-party Web property -- and all of the technical details and | ||||
protocol mechanisms that are used to compose a page representing that | ||||
brand are hidden behind the scenes. | ||||
It has become common for Web site owners to collect data regarding the | ||||
usage of their sites for a variety of purposes, including what led the | ||||
user to visit their site (referrals), how effective the user experience is | ||||
within the site (web analytics), and the nature of who is using their site | ||||
(audience segmentation). In some cases, the data collected is used to | ||||
dynamically adapt the content (personalization) or the advertising | ||||
presented to the user (targeted advertising). Data collection can occur | ||||
both at the first-party site and via third-party providers through the | ||||
insertion of tracking elements on each page. A survey of these techniques | ||||
and their privacy implications can be found in [KnowPrivacy]. | ||||
People have the right to know how data about them will be collected and | ||||
how it will be used. Empowered with that knowledge, individuals can decide | ||||
whether to allow their online activities to be tracked and data about them | ||||
to be collected. Many Internet companies use data gathered about people's | ||||
online activities to personalize content and target advertising based on | ||||
their perceived interests. While some people appreciate this | ||||
personalization of content and ads in certain contexts, others are | ||||
troubled by what they perceive as an invasion of their privacy. For them, | ||||
the benefit of personalization is not worth their concerns about allowing | ||||
entities with whom they have no direct relationship to amass detailed | ||||
profiles about their activities. | ||||
Therefore, users need a mechanism to express their own preference | ||||
regarding tracking that is both simple to configure and efficient when | ||||
implemented. In turn, Web sites that are unwilling or unable to offer | ||||
content without such targeted advertising or data collection need a | ||||
mechanism to indicate those requirements to the user and allow them (or | ||||
their user agent) to make an individual choice regarding user-granted | ||||
exceptions. | ||||
This specification defines the terminology of tracking preferences, the | ||||
scope of its applicability, and the requirements on compliant first-party | ||||
and third-party participants when an indication of tracking preference is | ||||
received. This specification defines the meaning of a Do Not Track | ||||
preference and sets out practices for websites and other online companies | ||||
to comply with this preference. | ||||
A companion document, [TRACKING-DNT], defines the HTTP request header | ||||
field DNT for expressing a tracking preference on the Web, a well-known | ||||
location (URI) for providing a machine-readable tracking status resource | ||||
that describes a service's DNT compliance, the HTTP response header field | ||||
Tk for resources to communicate their compliance or non-compliance with | ||||
the user's expressed preference, and JavaScript APIs for determining DNT | ||||
status and requesting a site-specific, user-granted exception. | ||||
2. Scope and Goals | 2. Scope and Goals | |||
Issue 6: What are the underlying concerns? Why are we doing this? | This specification is designed to provide users a simple machine-readable | |||
preference expression mechanism to globally or selectively allow or limit | ||||
This section consists of proposed text that is meant to address ISSUE-6 | online tracking. | |||
and is in active discussion. Currently, it satisfies no one. Like the | ||||
introduction, we will revisit and finalize once the document is more | ||||
complete. | ||||
While there are a variety of business models to monetize content on the | ||||
web, many rely on advertising. Advertisements can be targeted to a | ||||
particular user's interests based on information gathered about one's | ||||
online activity. While the Internet industry believes many users | ||||
appreciate such targeted advertising, as well as other personalized | ||||
content, there is also an understanding that some people find the practice | ||||
intrusive. If this opinion becomes widespread, it could undermine the | ||||
trust necessary to conduct business on the Internet. This Compliance | ||||
specification and a companion [TRACKING-DNT] specification are intended to | ||||
give users a means to indicate their tracking preference and to spell out | ||||
the obligations of compliant websites that receive the Do Not Track | ||||
message. The goal is to provide the user with choice, while allowing | ||||
practices necessary for a smoothly functioning Internet. This should be a | ||||
win-win for business and consumers alike. The Internet brings millions of | ||||
users and web sites together in a vibrant and rich ecosystem. As the | ||||
sophistication of the Internet has grown, so too has its complexity which | ||||
leaves all but the most technically savvy unable to deeply understand how | ||||
web sites collect and use data about their online interactions. While on | ||||
the surface many web sites may appear to be served by a single entity, in | ||||
fact, many web sites are an assembly of multiple parties coming together | ||||
to power a user's online experience. As an additional privacy tool, this | ||||
specification provides both the technical and compliance guidelines to | ||||
enable the online ecosystem to further empower users with the ability to | ||||
communicate a tracking preferences to a web site and its partners. | ||||
The accompanying TRACKING-DNT recommendation explains how a user, through | ||||
a user agent, can clearly express a desire not to be tracked. This | ||||
Tracking Compliance and Scope recommendation sets the standard for the | ||||
obligations of a website that receives such a DNT message. | ||||
Taken together these two standards should have four substantial outcomes: | ||||
1. Empower users to manage their preference around the collection and | "Tracking" is understood by this standard as the collection and retention | |||
correlation of data about Internet activities that occur on different | of data across multiple parties' domains or services in a form such that | |||
sites and spell out the obligations of sites in honoring those | it can be attributed to a specific user, user agent, or device. | |||
preferences when DNT is enabled. | ||||
2. Provide an exceedingly straightforward way for users to gain | ||||
transparency and control over data usage and the personalization of | ||||
content and advertising on the web. | ||||
3. Enable a vibrant Internet to continue to flourish economically by | ||||
supporting innovative business models while protecting users' privacy. | ||||
4. Establish compliance metrics for operators of online services | ||||
This standard has limited applicability to any practices by first parties, | Note | |||
their service providers, subsidiaries, or affiliated companies. Under the | ||||
standard, first parties may and will continue to collect and use data for | ||||
tracking and other purposes. This standard is primarily directed at third | ||||
parties. | ||||
This solution is intended to be persistent, technology neutral, and | The scope language is not at consensus, but is an effort by the editors to | |||
reversible by the user. It aims to preserve a vibrant online ecosystem, | offer a provisional definition of tracking. | |||
privacy-preserving secondary data uses necessary to ecommerce, and | ||||
adequate security measures. We seek a solution that is persistent, | ||||
technology neutral, and [something that speaks with the ability to opt | ||||
back in], but that preserves a vibrant online ecosystem, | ||||
privacy-preserving secondary data uses, and adequate security measures. | ||||
3. Definitions | 3. Definitions | |||
3.1 User | 3.1 User | |||
A user is an individual human. When user-agent software accesses online | A user is an individual human. When user-agent software accesses online | |||
resources, whether or not the user understands or has specific knowledge | resources, whether or not the user understands or has specific knowledge | |||
of a particular request, that request is made "by" the user. | of a particular request, that request is made "by" the user. | |||
3.2 User Agent | 3.2 User Agent | |||
This specification uses the term user agent to refer to any of the various | This specification uses the term user agent to refer to any of the various | |||
client programs capable of initiating HTTP requests, including but not | client programs capable of initiating HTTP requests, including but not | |||
limited to browsers, spiders (web-based robots), command-line tools, | limited to browsers, spiders (web-based robots), command-line tools, | |||
native applications, and mobile apps [HTTP11]. | native applications, and mobile apps [HTTP11]. | |||
Note | ||||
There has been recent discussion about whether the specification should | ||||
differentiate among different types of users agents (such as general | ||||
purpose browsers, add-ons, and stand-alone software programs), and | ||||
possibly specify different compliance obligations depending on the type of | ||||
user agent, or priority among different categories of user agents in the | ||||
event of conflicting settings. There is currently no open ISSUE associated | ||||
with this discussion. | ||||
3.3 Party | 3.3 Party | |||
3.3.1 Option 1 | ||||
A party is any commercial, nonprofit, or governmental organization, a | ||||
subsidiary or unit of such an organization, or a person which acts as a | ||||
functional entity. A set of functional entities is considered affiliated | ||||
when they are related by both common majority ownership and common | ||||
control, and affiliation is made easily discoverable by a user. | ||||
3.3.2 Option 2 | ||||
A party is any commercial, nonprofit, or governmental organization, a | A party is any commercial, nonprofit, or governmental organization, a | |||
subsidiary or unit of such an organization, or a person. For unique | subsidiary or unit of such an organization, or a person. For unique | |||
corporate entities to qualify as a common party with respect to this | corporate entities to qualify as a common party with respect to this | |||
document, those entities MUST be commonly owned and commonly controlled | document,those entities MUST be commonly owned and commonly controlled and | |||
(Affiliates) and MUST provide "easy discoverability" of affiliate | MUST provide easy discoverability of affiliate organizations. An list of | |||
organizations. An "Affiliate List" MUST be provided within one click from | affiliates MUST be provided within one click from each page or the entity | |||
each page or the entity owner clearly identified within one click from | owner clearly identified within one click from each page. | |||
each page. | ||||
A website with a clear labeled link to the Affiliate List within the | ||||
privacy policy would meet this requirement or the ownership brand clearly | ||||
labeled on the privacy policy itself and may choose to act as a single | ||||
party. | ||||
3.4 Service Providers/Outsourcers | ||||
Note | ||||
We seem to have general consensus in theory but not in language for the | ||||
definition of a service provider. However, the three options below | ||||
different significantly in how prescriptive and demanding the test to | ||||
qualify as a service provider should be. | ||||
3.4.1 Option 1: Service Provider/Outsourcer Definition | ||||
Note | ||||
This option contains both definitions and normative compliance | ||||
requirements. | ||||
This section applies to parties engaging in an outsourcing relationship, | ||||
wherein one party "stands in the shoes" of another party to perform a | ||||
specific task. Both parties have responsibilities, as detailed below. | ||||
A first party or a third party MAY outsource functionality to another | ||||
party, in which case the third party may act as the original first party | ||||
or third party under this standard, with the following additional | ||||
restrictions: | ||||
* Data collected by each outsourced company is separated for each party | ||||
they collect data for by both technical means and organizational | ||||
process, AND | ||||
* The outsourced company has no independent rights to the collected | ||||
information, AND | ||||
* A contractual relationship exists between the outsourced and the party | ||||
they collect data for that outlines and mandates these requirements. | ||||
An outsourced company acting on the behalf of another party is subject to | ||||
all of the same restrictions on that party (for First or Third party, as | ||||
appropriate.) | ||||
3.4.1.1 Non-Normative | ||||
This section is non-normative. | ||||
Outsourced companies that act purely as vendors for their customers (often | ||||
first parties in this context) are not the intended target for the | ||||
Tracking Preference Expression but it is important there are no unintended | ||||
activities that are extended to another party through this allowance. In | ||||
all cases, its expected an outsourced company acting on the part of a | ||||
customer follows all of the same restrictions placed on that customer. | ||||
For the data separation requirement, outsourced companies have technical | ||||
options to achieve appropriate separation but in each the critical element | ||||
is that data is never reconstituted for users that have indicated a | ||||
preference not to be tracked. One possible approach would be to leverage a | ||||
per partner hash against a common cookie identifier, ensuring the | ||||
resulting identifier is consistent for a specific customer, but is unable | ||||
to be linked with another customer's identifier. | ||||
Contractual requirements that enforce data rights and responsibilities for | ||||
separation are a critical element of establishing an outsourcer acting on | ||||
another party's behalf. Contracts may occur directly through parties (for | ||||
example, a Publisher in an Ad Network) or between intermediaries (for | ||||
example, an Ad Network acting through an Ad Exchange). In either case, | ||||
data separation and removal of independent rights are necessary elements | ||||
that must survive intermediary contractual constructs. | ||||
3.4.1.2 Technical Precautions | ||||
Throughout all data collection, retention, and use, outsourced parties | ||||
MUST use all feasible technical precautions to both mitigate the | ||||
identifiability of and prevent the identification of data from different | ||||
first parties. | ||||
Structural separation ("siloing") of data per first party, including both | ||||
1. separate data structures and | ||||
2. avoidance of shared unique identifiers | ||||
are necessary, but not necessarily sufficient, technical precautions. | ||||
3.4.1.3 Non-Normative Discussion | ||||
This section is non-normative. | ||||
3.4.1.3.1 Siloing in the Browser | ||||
This section is non-normative. | ||||
Outsourcing services should use browser access control features so that | ||||
stored data specific to one party is never accessed or collected when the | ||||
user visits another party. | ||||
3.4.1.3.1.1 Same-Origin Policy | ||||
The same-origin policy silos stored data by domain name. An outsourcing | ||||
service can use a different domain name for each first party. | ||||
Example 1 | ||||
Example Analytics provides an outsourced analytics service to Example News | ||||
and Example Sports, two unrelated websites. Example Analytics stores its | ||||
cookies for Example News at examplenews.exampleanalytics.com, and it | ||||
stores its cookies for Example Sports at | ||||
examplesports.exampleanalytics.com. | ||||
3.4.1.3.1.2 Cookie Path Attribute | ||||
The HTTP cookie path can be used to silo data to a first party. | ||||
Example 2 | ||||
Example Analytics stores its cookies for Example News with | ||||
"Path=/examplenews", and it stores its cookies for Example Sports with | ||||
"Path=/examplesports". | ||||
3.4.1.3.1.3 Storage Key | ||||
For key/value storage APIs, such as Web Storage and Indexed Database, an | ||||
outsourcing service can use a different key or key prefix for each first | ||||
party. | ||||
Example 3 | ||||
Example Analytics stores data for Example News at | ||||
window.localStorage["examplenews"] and data for Example Sports at | ||||
window.localStorage["examplesports"]. | ||||
3.4.1.3.2 Siloing in the Backend | ||||
3.4.1.3.2.1 Encryption Keys | ||||
An outsourcing service should encrypt each first party's data with a | ||||
different set of keys. | ||||
3.4.1.3.2.2 Access Controls | ||||
An outsourcing service should deploy access controls so that only | ||||
authorized personnel are able to access siloed data, and only for | ||||
authorized purposes. | ||||
3.4.1.3.2.3 Access Monitoring | ||||
An outsourcing service should deploy access monitoring mechanisms to | ||||
detect improper use of siloed data. | ||||
3.4.1.3.3 Retention in the Backend | ||||
An outsourcing service should retain information only so long as necessary | ||||
to provide necessary functionality to a first party. If a service creates | ||||
periodic reports, for example, it should delete the data used for a report | ||||
once it is generated. An outsourcing service should be particularly | ||||
sensitive to retaining protocol logs, since they may allow correlating | ||||
user activity across multiple first parties. | ||||
3.4.1.4 Internal Practices | ||||
Throughout all data collection, retention, and use, outsourced parties | ||||
MUST use sufficient internal practices to prevent the identification of | ||||
data from different parties. | ||||
3.4.1.4.1 Non-Normative Discussion | ||||
This section is non-normative. | ||||
3.4.1.4.1.1 Policy | ||||
An outsourcing service should establish a clear internal policy that gives | ||||
guidance on how to collect, retain, and use outsourced data in compliance | ||||
with this standard. | ||||
3.4.1.4.1.2 Training | ||||
Personnel that interact with outsourced data should be familiarized with | ||||
internal policy on compliance with this standard. | ||||
3.4.1.4.1.3 Supervision and Reporting | ||||
An outsourcing service should establish a supervision and reporting | ||||
structure for detecting improper access. | ||||
3.4.1.4.1.4 Auditing | ||||
External auditors should periodically examine an outsourcing service to | ||||
assess whether it is in compliance with this standard and has adopted best | ||||
practices. Auditor reports should be made available to the public. | ||||
3.4.1.5 Use Direction | ||||
An outsourced service: | ||||
1. MUST use data retained on behalf of a party ONLY on behalf of that | ||||
party, and | ||||
2. MUST NOT use data retained on behalf of a party for their own business | ||||
purposes, or for any other reasons. | ||||
3.4.1.6 First Party or Third Party Requirements | ||||
3.4.1.6.1 Representation | ||||
A party's representation that it is in compliance with this standard | ||||
includes a representation that its outsourcing parties comply with this | ||||
standard. | ||||
3.4.1.6.2 Contract | ||||
A first party MUST enter into a contract with an outsourced party that | ||||
requires that outsourced party to comply with these requirements. | ||||
3.4.2 Option 2: Service Provider/Outsourcer Definition | 3.4 Service Providers | |||
Outsourced service providers are considered to be the same party as their | Outsourced service providers are considered to be the same party as their | |||
clients if the outsourced service providers only act as data processors on | clients if the outsourced service providers only act as data processors on | |||
behalf of that party, silo the data so that it cannot be accessed by other | behalf of that party in relation to that party, silo the data so that it | |||
parties, and have no control over the use or sharing of that data except | cannot be accessed by other parties, and have no control over the use or | |||
as directed by that party. | sharing of that data except as directed by that party. | |||
3.4.3 Option 3: Service Provider/Outsourcer Definition | ||||
Service Providers acting on the behalf of a First Party and with no | ||||
independent rights to use the First Party's data outside of the context of | ||||
that First Party and Permitted Uses are also considered to be acting as | ||||
the First Party. | ||||
3.5 First and Third Parties | ||||
3.5.1 Option 1: First and Third Parties | ||||
3.5.1.1 Definitions | ||||
A first party is any party, in a specific network interaction, that can | ||||
infer with high probability that the user knowingly and intentionally | ||||
communicated with it. Otherwise, a party is a third party. | ||||
A third party is any party, in a specific network interaction, that cannot | ||||
infer with high probability that the user knowingly and intentionally | ||||
communicated with it. | ||||
3.5.1.2 Discussion | ||||
This section is non-normative. | ||||
3.5.1.2.1 Overview | ||||
This section is non-normative. | ||||
We draw a distinction between those parties an ordinary user would or | ||||
would not expect to share information with, "first parties" and "third | ||||
parties" respectively. The delineation exists for three reasons. | ||||
First, when a user expects to share information with a party, she can | ||||
often exercise control over the information flow. Take, for example, | ||||
Example Social, a popular social network. The user may decide she does not | ||||
like Example Social's privacy or security practices, so she does not visit | ||||
examplesocial.com. But if Example Social provides a social sharing widget | ||||
embedded in another website, the user may be unaware she is giving | ||||
information to Example Social and unable to exercise control over the | ||||
information flow. | ||||
Second, we recognize that market pressures are an important factor in | ||||
encouraging good privacy and security practices. If users do not expect | ||||
that they will share information with an organization, it is unlikely to | ||||
experience market pressure from users to protect the security and privacy | ||||
of their information. In practice, moreover, third parties may not | ||||
experience sufficient market pressure from first parties since | ||||
increasingly third parties do not have a direct business relationship with | ||||
the first party websites they appear on. We therefore require a greater | ||||
degree of user control over information sharing with such organizations. | ||||
Last, third parties are often in a position to collect a sizeable | ||||
proportion of a user's browsing history - information that can be uniquely | ||||
sensitive and easily associated with a user's identity. We wish to provide | ||||
user control over such information flows. | ||||
We recognize that, unlike with a bright-line rule, there can be close | ||||
calls in applying our standard for what constitutes a first party or a | ||||
third party. But we believe that in practice, such close calls will be | ||||
rare. The overwhelming majority of content on the web can be classified as | ||||
first party or third party, with few cases of ambiguity in practice. | ||||
We require a confidence at a "high probability" before a party can | ||||
consider itself a first party. Where there is reasonable ambiguity about | ||||
whether a user has intentionally interacted with a party, it must consider | ||||
itself a third party. Our rationale is that, in the rare close cases, a | ||||
website is in the best position to understand its users' expectations. We | ||||
therefore impose the burden of understanding user expectations on the | ||||
website. We also wish, in close cases, to err on the side of conforming to | ||||
user expectations and protecting user privacy. If the standard is | ||||
insufficiently protective, ordinary users have limited recourse; if the | ||||
standard imposes excessive limits, websites retain the safety valve of | ||||
explicitly asking for user permission. | ||||
In some cases, web requests are redirected through intermediary domains, | ||||
such as url shorteners or framing pages, before eventually delivering the | ||||
content that the user was attempting to access. The operators of these | ||||
intermediary domains are third parties, unless they are a common party to | ||||
the operator of either the referring page or the eventual landing page. | ||||
Examples | ||||
1. A user accesses an Example News article. The page includes an | ||||
advertisement slot, which loads content from many companies other than | ||||
Example News. Those companies are third parties. | ||||
2. A user accesses an Example News article. The page includes an | ||||
analytics script that is hosted by Example Analytics, an analytics | ||||
service. Example Analytics is a third party. | ||||
3. A user accesses an Example News article. It includes a social sharing | ||||
widget from Example Social, a popular social network. Example Social | ||||
is a third party. | ||||
4. A user visits Example Diary, which is hosted by the free blogging | ||||
service Example Blog Hosting but located at examplediary.com. Example | ||||
Blog Hosting is a third party. | ||||
5. A user launches Example Application, an app on a mobile device. The | ||||
app includes a library from Example Advertising Network that displays | ||||
ads. Example Advertising Network is a third party. | ||||
6. A user visits Example Social and sees the language: "Check out this | ||||
Example News article on cooking: sho.rt/1234". The user clicks the | ||||
link which directs the user to a page operated by the company Example | ||||
Sho.rt which then redirects the user to a page operated by Example | ||||
News. Example Social and Example News and first parties, and Example | ||||
Sho.rt is a third party. | ||||
7. A user visits Example Social and sees a hyperlink reading: "Check out | ||||
this Example News article on cooking." A user clicks the link which | ||||
points to framing.com/news1234. This page loads nothing but a frame | ||||
which contains the cooking article from Example News, but all links | ||||
are rewritten to pass through framing.com which is operated by Example | ||||
Framing. Example Social and Example News are first parties and Example | ||||
Framing is a third party. | ||||
3.5.1.2.2 Multiple First Parties | ||||
Note | Outsourced service providers are considered to be the same party as their | |||
clients if the service provider | ||||
There has been some disagreement within the group over how many first | 1. acts only as a data processor on behalf of the client; | |||
parties there should be in any one network interaction. These three | ||||
options lay out the range of possibilities; the first is text that has | ||||
been before the group for some time, the others are new. | ||||
There will almost always be only one party that the average user would | 2. ensures that the data can only be accessed and used as directed by that | |||
expect to communicate with: the provider of the website the user has | client; | |||
visited. But, in rare cases, users may expect that a website is provided | ||||
by more than one party. For example, suppose Example Sports, a well known | ||||
sports league, collaborates with Example Streaming, a well known streaming | ||||
video website, to provide content at | ||||
www.examplesportsonexamplestreaming.com. The website is prominently | ||||
advertised and branded as being provided by both Example Sports and | ||||
Example Streaming. An ordinary user who visits the website may recognize | ||||
that it is operated by both Example Sports and Example Streaming. | ||||
There can be only one first party in any network transaction absent | 3. has not independent right to use or share the data except as necessary | |||
additional meaningful interaction with otherwise third party content on | to ensure the integrity, security, and correct operation of the service | |||
the webpage. The first party is the registrant and operator of the domain | being provided; and | |||
that the user intentionally communicated with. | ||||
If a user intends to communicate with a party that utilizes a different | 4. has a contract in place that outlines and mandates these requirements. | |||
party as a platform, then both parties are first parties in the network | ||||
transaction. | ||||
Example: ExampleSports franchise has a dedicated page on a ExampleSocial. | Issue 49: Third party as first party -- is a third party that collects | |||
When a user visits this dedicated page, both ExampleSports and | data on behalf of a first party treated the same way as the first party | |||
ExampleSocial are first parties. | ||||
3.5.1.2.3 User Interaction with Third-Party Content | 3.5 First Party | |||
A party may start out as a third party but become a first party later on, | In a specific network interaction, a party with which the user | |||
after a user interacts with it. If content from a third party is embedded | intentionally interacts is a first party. In most cases on a traditional | |||
on a first party page, the third party may become an additional first | web browser, the first party will be the party that owns and operates the | |||
party if it can infer with high probability that the average user | domain visible in the address bar. The party that owns and operates or has | |||
knowingly and intentionally communicated with it. If a user merely moused | control over a branded/labelled embedded widget, search box, or similar | |||
over, closed, or muted third-party content, the party would not be able to | service with which a user intentionally interacts is also considered a | |||
draw such an inference. | First Party. If a user merely mouses over, closes, or mutes such content, | |||
that is not sufficient interaction to render the party a first party. | ||||
Examples | 3.5.1 Multiple First Parties | |||
1. Example Weather offers an unbranded weather widget that is embedded | In most network interactions, there will be only one first party with | |||
into websites, including Example News. The widget contains small links | which the user intends to interact. However, in some cases, a network | |||
to Example Weather's website and privacy policy. A user visits Example | resource will be jointly operated by two or more parties, and a user would | |||
News and scrolls through the weekly forecast in the Example Weather | reasonably expect to communicate with all of them by accessing that | |||
widget. Example Weather is a third party. The user has interacted with | resource. User understanding that multiple parties operate a particular | |||
Example Weather's widget, but an ordinary user would not expect that | resource could be accomplished through inclusion of multiple parties' | |||
scrolling through the widget involves communicating with Example News. | brands in a domain name, or prominent branding on the resource indicating | |||
2. Example Social, a popular social network, hosts a social sharing | that multiple parties are responsible for content or functionality on the | |||
button that other websites can embed. The button is colored and styled | resource with which a user reasonably would expect to interact by | |||
in the same fashion as Example Social's website, contains descriptive | accessing the resource. Simple branding of a party, without more, will not | |||
text that is specific to Example Social, includes Example Social's | be sufficient to make that party a first party in any particular network | |||
logo, and very frequently appears on Example Social's website. Example | interaction. | |||
News embeds the Example Social button, and a user clicks it. Example | ||||
Social is a first party once the user clicks its embedded social | ||||
sharing button. The average user would understand that by clicking the | ||||
button she is communicating with Example Social. | ||||
3.5.2 Option 2: First and Third Parties | Issue 10: What is a first party? | |||
First Party is the party that owns the Web site or has control over the | 3.6 Third Party | |||
Web site the consumer visits. A First Party also includes the owner of a | ||||
widget, search box or similar service with which a consumer interacts. | ||||
Note | In a specific network interaction, any entity that is not the user, user | |||
agent, or a first party is considered a third party. | ||||
If a user merely mouses over, closes, or mutes third-party content, that | 3.7 Deidentified Data | |||
is not sufficient interaction to constitute a First Party widget | ||||
interaction. | ||||
A Third Party is any party other than a First Party, Service Provider, or | Data is deidentified when a party: | |||
the user. It is possible to have multiple first parties on a single page | (1) has taken measures to ensure with a reasonable level of justified | |||
but each party must provide clear branding and a link to their respective | confidence that the data cannot be used to infer information about, or | |||
privacy policy (co-branded experience). | otherwise be linked to, a particular consumer, computer, or other device; | |||
(2) does not to try to reidentify the data; and | ||||
(3) contractually prohibits downstream recipients from trying to | ||||
re-identify the data. | ||||
3.6 Unlinkable Data | Data can be considered sufficiently deidentified to the extent that it has | |||
been deleted, modified, aggregated, anonymized or otherwise manipulated in | ||||
order to achieve a reasonable level of justified confidence that the data | ||||
cannot reasonably be used to infer information about, or otherwise be | ||||
linked to, a particular user, user agent, or device. | ||||
Note | Note | |||
There is debate about whether to use the terms unlinkable, unlinked, or | The first option above is based on the definition of unlinkable data in | |||
unidentified to describe this type of data. | the 2012 FTC privacy report; the second option was proposed by Daniel | |||
Kaufman. The group has a fundamental disagreement about whether internal | ||||
3.6.1 Option 1: Unlinkable Data | access controls within an organization could be sufficient to de-identify | |||
data for the purposes of this standard. | ||||
A party render a dataset unlinkable when it | ||||
1. takes commercially reasonable steps have been taken to de-identify data | ||||
such that there is confidence that it contains information which could not | ||||
be linked to a specific user, user agent, or device in a production | ||||
environment | ||||
2. publicly commits to retain and use the data in unlinkable fashion, and | ||||
not to attempt to re-identify the data | ||||
3. contracually prohibits any third party that it transmits the unlinkable | ||||
data to from attempting to re-identify the data. Parties SHOULD provide | ||||
transparency to their delinking process (to the extent that it will not | ||||
provided confidential details into security practices) so external experts | ||||
and auditors can assess if the steps are reasonably given the particular | ||||
data set. | ||||
3.6.2 Option 2: Unlinkable Data | Issue 188: Definition of unlinkable data | |||
A dataset is unlinkable when there is a high probability that it contains | Issue 191: Non-normative Discussion of De-Identification | |||
only information that could not be linked to a particular user, user | ||||
agents, or device by a skilled analyst. A party renders a dataset | ||||
unlinkable when either: | ||||
1. it publicly publishes information that is sufficiently detailed for a | ||||
skilled analyst to evaluate the implementation, or | ||||
2. ensure that the dataset is at least 1024-unlinkable. | ||||
3.7 Network Transaction | 3.8 Network Transaction | |||
A "network interaction" is an HTTP request and response, or any other | A network interaction is an HTTP request and response, or any other | |||
sequence of logically related network traffic. | sequence of logically related network traffic. | |||
Non-normative explanatory text: Determination of a party's status is | 3.9 Data collection, retention, use, and sharing | |||
limited to a single interaction because a party's status may be affected | ||||
by time, context, or any other factor that influences user expectations. | ||||
3.8 Data collection, retention, use, and sharing | ||||
Note | ||||
We have not had time to substantially edit the definitions of collection | ||||
and tracking. These continue to be actively debated issues, as the | ||||
resolution of the use of unique identifiers is likely to end up in these | ||||
definitions. | ||||
Issue 16: What does it mean to collect data? (caching, logging, storage, | Issue 16: What does it mean to collect data? (caching, logging, storage, | |||
retention, accumulation, profile etc.) | retention, accumulation, profile etc.) | |||
1. A party "collects" data if the data comes within its control. | 1. A party collects data if it receives the data and either shares the | |||
2. A party "retains" data if data remains within a party's control beyond | data with other parties or stores the data for more than a transient | |||
period. | ||||
2. A party retains data if data remains within a party's control beyond | ||||
the scope of the current interaction. | the scope of the current interaction. | |||
3. A party "uses" data if the party processes the data for any purpose | 3. A party uses data if the party processes the data for any purpose | |||
other than storage or merely forwarding it to another party. | other than storage or merely forwarding it to another party. | |||
4. A party "shares" data if the party enables another party to receive or | 4. A party shares data if the party provides a copy or access to the data | |||
access that data. | to a third party. | |||
The definitions of collection, retention, use, and sharing are drafted | The definitions of collection, retention, use, and sharing are drafted | |||
expansively so as to comprehensively cover a party's user-information | expansively so as to comprehensively cover a party's user-information | |||
practices. These definitions do not require a party's intent; a party may | practices. These definitions do not require a party's intent; a party may | |||
inadvertently collect, retain, use, or share data. The definition of | inadvertently collect, retain, use, or share data. The definition of | |||
collection includes information that a party did not cause to be | collection includes information that a party did not cause to be | |||
transmitted, such as protocol headers. | transmitted, such as protocol headers. | |||
3.8.1 Exception for unknowing collection, retention, and use | Alternative: A party "collects" data when it assembles data from or about | |||
one or more network interactions and retains or shares that data beyond | ||||
the scope of responding to the current request or in a form that remains | ||||
linkable to a specific user, user agent, or device. | ||||
3.9.1 Exception for unknowing collection, retention, and use | ||||
A party may receive, retain, and use data as otherwise prohibited by this | A party may receive, retain, and use data as otherwise prohibited by this | |||
standard, so long as is unaware of such information practices and has made | standard, so long as it is unaware of such information practices and has | |||
reasonable efforts to understand its information practices. If a party | made reasonable efforts to understand its information practices. If a | |||
learns that it possesses information in violation of this standard, it | party learns that it possesses information in violation of this standard, | |||
must delete that information at the earliest practical opportunity. | it must delete that information at the earliest practical opportunity. | |||
3.9 Tracking | 3.10 Tracking | |||
Note | Note | |||
The term "tracking" is not used in the document. This section is likely to | The term "tracking" is not used in the normative text of this document. We | |||
be deleted, and the issues will be addressed in the definitions of | may subsequently decide to define this term, or address the issue of what | |||
"collection" and "unlinkable" above. | is "tracking" in the Introduction or Scope section. A definition proposed | |||
by the editors is available in the Scope section above. | ||||
Issue 117: Terms: tracking v. cross-site tracking | Issue 117: Terms: tracking v. cross-site tracking | |||
3.9.1 Option 1: Non-first Party Identifiers | 3.11 Explicit and Informed Consent | |||
Note | Note | |||
Concerns with this section include undefined term "user data" plus as | The spec currently envisions that users should consent to both the setting | |||
written, this may apply more broadly than the authors intended | of a DNT preference as well as any user-granted exceptions. We have not | |||
reached agreement on how precisely we need to define this term. | ||||
Tracking is the collection or use of user data via either a unique | Explicit and informed choice must satisfy the following bright-line | |||
identifier or a correlated set of data points being used to approximate a | requirements: | |||
unique identifier, in a context other than "first party" as defined in | ||||
this document. This includes: | ||||
1. a party collecting data across multiple websites, even if it is a | 1. Actual presentation: The choice mechanism MUST be actually presented | |||
first party in one or more (but not all) of the multiple contexts | to the user. It MUST NOT be on a linked page, such as a terms of | |||
2. a third party collecting data on a given website | service or privacy policy. | |||
3. a first party sharing user data collected from a DNT:1 user with third | 2. Clear Terms: The choice mechanism MUST use clear, non-confusing | |||
parties "after the fact". | technology. | |||
3. Independent choice: The choice mechanism MUST be presented independent | ||||
of other choices. It MUST NOT be bundled with other user preferences. | ||||
4. No default permission: The choice MUST NOT have the user permission | ||||
selected by default. | ||||
Examples of tracking use cases include: | No definition, other than explicitly leaving the definition of consent to | |||
local rules. | ||||
1. personalized advertising | Issue 69: Should the spec say anything about minimal notice? (ie. don't | |||
2. cross-site analytics or market research that has not been | bury in a privacy policy) | |||
de-identified | ||||
3. automatic preference sharing by social applications | ||||
3.9.2 Option 2: Cross-site or Over Time | 4. First Party Compliance | |||
Tracking is defined as following or identifying a user, user agent, or | If a first party receives a network transaction to which a DNT:1 header is | |||
device across multiple visits to a site (time) or across multiple sites | attached, First Parties may engage in their normal collection and use of | |||
(space). | information. This includes the ability to customize the content, services, | |||
and advertising in the context of the first party experience. | ||||
Mechanisms for performing tracking include but are not limited to: | The first party must not pass information about this transaction to | |||
non-service provider third parties who could not collect the data | ||||
themselves under this standard. | ||||
1. assigning a unique identifier to the user, user agent, or device such | 4.1 Additional/Alternative First Party Compliance Requirements | |||
that it will be conveyed back to the server on future visits; | ||||
2. personalizing references or referral information such that they will | ||||
convey the user, user agent, or device identity to other sites; | ||||
3. correlating data provided in the request with identifying data | ||||
collected from past requests or obtained from a third party; or, | ||||
4. combining data provided in the request with de-identified data | ||||
collected or obtained from past requests in order to re-identify that | ||||
data or otherwise associate it with the user, user agent, or device. | ||||
A preference of "Do Not Track" means that the user does not want tracking | When DNT:1 is received, | |||
to be engaged for this request, including any mechanism for performing | ||||
tracking, any use of data retained from prior tracking, and any retention | ||||
or sharing of data from this request for the purpose of future tracking, | ||||
beyond what is necessary to enable: | ||||
1. the limited permitted uses defined in this specification; | 1. A first party MUST NOT combine or otherwise use identifiable data | |||
2. the first-party (and third-parties acting as the first-party) to | received from another party with data it collected while a first | |||
provide the service intentionally requested by the user; and | party; | |||
3. other services for which the user has provided prior, specific, and | 2. A first party MUST NOT share identifiable data with another party | |||
informed consent. | unless the data was provided voluntarily by the user and is necessary | |||
to complete a business transaction with the user; and | ||||
3. A party MUST NOT use data gathered while a first party when operating | ||||
as a third party. | ||||
3.9.3 Option 3: Silence | 4.1.1 Explanation | |||
One proposal is not to define "tracking," but rather to list what is, or | This section is non-normative. | |||
is not, required and allowed in order to comply with the recommendation. | ||||
3.10 Explicit and Informed Consent | When DNT:1 is received, a first party retains the ability to customize | |||
content, services, and advertising only within the context of the first | ||||
party experience. A first party takes the user interaction outside of the | ||||
first party experience if it receives identifiable data from another party | ||||
and uses that data for customization of content, services, or advertising. | ||||
When DNT:1 is received the first Party may continue to utilize user | ||||
provided data in order to complete or fulfill a user initiated business | ||||
transaction such as fulfilling an order for goods or a subscription. | ||||
When DNT:1 is received and a Party has become a third party it is | ||||
interacting with the user outside of the first party experience. Using | ||||
data gathered while a first party is incompatible with interaction as a | ||||
third party. | ||||
Note | Note | |||
The spec currently envisions that users should consent to both the setting | This language is not consensus. The parties are generally agreed that this | |||
of a DNT preference as well as any user-granted exceptions. We have not | language should prohibit first parties from enabling third parties to | |||
reached agreement on how precisely we need to define this term. | circumvent "Do Not Track" by providing them with correlatable cross-site | |||
data in a different context. There is an open debate about the extent to | ||||
which this should prohibit "data append" practices, where first parties | ||||
query data brokers about their users (and thus trasmit information to the | ||||
brokers) order to augment their own records on users, or whether third | ||||
parties may use data they previously collected in a first party context. | ||||
One proposed compromise to the first issue would be to allow data append | ||||
only when the data broker would qualify as a service provider, having no | ||||
independent right to use the data associated with the append inquiry. | ||||
Issue 69: Should the spec say anything about minimal notice? (ie. don't | Issue 170: Definition of and what/whether limitations around data append | |||
bury in a privacy policy) | ||||
3.10.1 Option 1: Prescriptive | 5. User Agent Compliance | |||
Explicit and informed choice must satisfy the following bright-line | A user agent MUST offer a control to express a tracking preference to | |||
requirements: | third parties. The control MUST communicate the user's preference in | |||
1. Actual presentation: The choice mechanism MUST be actually presented to | accordance with the [TRACKING-DNT] recommendation and otherwise comply | |||
the user. It MUST NOT be on a linked page, such as a terms of service or | with that recommendation. A user agent MUST NOT express a tracking | |||
privacy policy. | preference for a user unless the user has given express and informed | |||
2. Clear Terms:The choice mechanism MUST use clear, non-confusing | consent to indicate a tracking preference. | |||
technology. | ||||
3. Independent choice: The choice mechanism MUST be presented independent | ||||
of other choices. It MUST NOT be bundled with other user preferences. | ||||
4. No default permission: The choice MUST NOT have the user permission | ||||
selected by default. | ||||
3.10.2 Option 2: Silence | While we do not specify how tracking preference choices are offered to the | |||
user or how the preference is enabled, each implementation MUST follow the | ||||
following user interface guidelines: | ||||
No definition, other than explicitly leaving the definition of consent to | 1. The User Agent is responsible for determining the user experience by | |||
local rules. | which a tracking preference is enabled. For example, a user might select a | |||
check-box in their user agent's configuration, or install an extension or | ||||
add-on that is specifically designed to add a tracking preference | ||||
expression so long as the checkbox, extension or add-on otherwise follows | ||||
these user interface guidelines; | ||||
4. First Party Compliance | 2. The User Agent MUST ensure that the tracking preference choices are | |||
communicated to users clearly and conspicuously, and shown at the time and | ||||
place the tracking preference choice is made available to a user; | ||||
Note | 3. The User Agent MUST ensure that the tracking preference choices | |||
accurately describe DNT, including the parties to whom DNT applies, and | ||||
MUST make available via a link in explanatory text where DNT is enabled to | ||||
provide more detailed information about DNT functionality. | ||||
This language is not consensus and must change. The parties are generally | Non-Normative: | |||
agreed that this language should only prohibit first parties from enabling | ||||
third parties to circumvent "Do Not Track" by providing them with | ||||
correlatable cross-site data in a different context. There is an open | ||||
debate about the extent to which this should prohibit "data append" | ||||
practices, where first parties query data brokers about their users (and | ||||
thus trasmit information to the brokers) order to augment their own | ||||
records on users. | ||||
If a First Party receives a network transaction to which a DNT:1 header is | The User Agent plays a key role in enacting the DNT functionality. As a | |||
attached, First Parties may engage in their normal collection and use of | result, it is appropriate for the User Agent to play an equally key role | |||
information. This includes the ability to customize the content, services, | in describing DNT functionality and educating users about DNT in order for | |||
and advertising in the context of the first party experience. | this standard to be meaningful. | |||
The First Party must not pass information about this transaction to | While the user interface guidelines do not specify the exact presentation | |||
non-service provider third parties who could not collect the data | to the user, they are intended to help ensure that users understand their | |||
themselves under this Recommendation. | choices with respect to DNT. For example, outlining the parties (e.g., | |||
First Parties, Service Providers, Third Parties) to whom DNT applies and | ||||
using language that a reasonable user is likely to understand is critical | ||||
for ensuring that users are in position to provide their informed consent | ||||
to a tracking preference. | ||||
Issue 229: Draft crisp definition [of data append] | Moreover, as DNT functionality is complex, it is important that User | |||
Agents educate users about DNT, including but not limited to offering a | ||||
clearly described link that takes the user to additional information about | ||||
DNT functionality. For example, given that some parties may chose not to | ||||
comply with DNT, it would be helpful for browsers to educate users about | ||||
how to check the response header and/or tokens to see if a server is | ||||
responding with a "public commitment" of compliance. | ||||
5. User Agent Compliance | Finally, recognizing that DNT settings may be set by non-browser User | |||
Agents acting in violation of the user interface guidelines, the browsers | ||||
should take reasonable steps to ensure that DNT settings are valid. | ||||
A user agent MUST offer a control to express a tracking preference to | User agents and web sites MUST obtain express and informed consent when | |||
third parties. The control MUST communicate the user's preference in | setting controls that affect the tracking preference expression. The | |||
accordance with the [TRACKING-DNT] recommendation and otherwise comply | controls MUST communicate the user's preference in accordance with the | |||
with that recommendation. A user agent MUST NOT express a tracking | [TRACKING-DNT] recommendation. | |||
preference for a user unless the user has given express and informed | ||||
consent to indicate a tracking preference. | ||||
We do not specify how tracking preference choices are offered to the user | User agents and web sites offering tracking preference choices to users | |||
or how the preference is enabled: each implementation is responsible for | MUST follow the following user interface guidelines: | |||
determining the user experience by which a tracking preference is enabled. | ||||
For example, a user might select a check-box in their user agent's | ||||
configuration, install an extension or add-on that is specifically | ||||
designed to add a tracking preference expression, or make a choice for | ||||
privacy that then implicitly includes a tracking preference (e.g., | ||||
"Privacy settings: high"). Likewise, a user might install or configure a | ||||
proxy to add the expression to their own outgoing requests. | ||||
Shane's proposal has suggested the additional compliance requirements of | 1. User agents and web sites are responsible for determining the user | |||
user agents: | experience by which a tracking preference is controlled; | |||
1. The User Agent must also make available via a link in explanatory text | ||||
where DNT is enabled to provide more detailed information about DNT | 2. User agents and web sites MUST ensure that tracking preference choices | |||
functionality | are communicated to users clearly and accurately, and shown at the time | |||
2. Any User Agent claiming compliance must have a functional | and place the tracking preference choice is made available to a user; | |||
implementation of the browser exceptions in this specification | ||||
3. User agents and web sites SHOULD ensure that the tracking preference | ||||
choices describe the parties to whom DNT applies and SHOULD make available | ||||
explanatory text to provide more detailed information about DNT | ||||
functionality. | ||||
Issue 150: DNT conflicts from multiple user agents | Issue 150: DNT conflicts from multiple user agents | |||
Issue 153: What are the implications on software that changes requests but | Issue 153: What are the implications on software that changes requests but | |||
does not necessarily initiate them? | does not necessarily initiate them? | |||
6. Third Party Compliance | 6. Third Party Compliance | |||
Note | ||||
This section addresses the crux of what DNT is intended to accomplish, and | ||||
as such, all of this section remains hotly debated. The specific language | ||||
is likely to change. See also alternative text proposed by Nick Doty. | ||||
If a third party receives a communication to which a DNT:1 header is | If a third party receives a communication to which a DNT:1 header is | |||
attached: | attached: | |||
1. that third party MUST NOT collect, share, or use information related | 1. that third party MUST NOT collect, retain, share, or use information | |||
to that communication outside of the permitted uses as defined within | related to that communication outside of the permitted uses as defined | |||
this standard and any explicitly-granted exceptions, provided in | within this standard and any explicitly-granted exceptions, provided | |||
accordance with the requirements of this standard; | in accordance with the requirements of this standard; | |||
2. that third party MUST NOT use information about previous | 2. that third party MUST NOT share or use information about previous | |||
communications in which it was a third party, outside of the permitted | communications in which it was a third party, outside of the permitted | |||
uses as defined within this standard and any explicitly-granted | uses as defined within this standard and any explicitly-granted | |||
exceptions, provided in accordance with the requirements of this | exceptions, provided in accordance with the requirements of this | |||
standard; | standard; | |||
3. that third party MAY delete information about previous communications | ||||
in which it was a third party. | ||||
6.1 Permitted Operational Uses for Third Parties and Service Providers | 6.1 Geolocation compliance by a third party | |||
If the operator of a third-party domain receives a communication to which | ||||
a DNT:1 header is attached: | ||||
1. Geo-location information that is more granular than postal code is too | ||||
granular. Geolocation data must not be used at any level more granular | ||||
than postal code. Note that while the number of people living in a | ||||
postal code varies from country to country, postal codes are extant | ||||
world-wide. | ||||
2. If specific consent has been granted for the use of more granular | ||||
location data, than that consent prevails. | ||||
6.2 Permitted Operational Uses for Third Parties | ||||
Note | Note | |||
These are options that have been discussed in the group. While many have | These are options that have been discussed in the group. While many have | |||
broad consensus within the group, some are debated both based on scope of | broad consensus within the group, some are debated both based on scope of | |||
the draft and whether they should be permitted uses. There is also | the draft and whether they should be permitted uses. There is also | |||
substantial disagrement over the SCOPE of information that may be | substantial disagrement over the SCOPE of information that may be | |||
collected, used, and retained for these purposes, most notably whether | collected, used, and retained for these purposes, most notably whether | |||
persistent unique identifiers may be collected, used, and retained for | persistent unique identifiers may be collected, used, and retained for | |||
these purposes. | these purposes. | |||
skipping to change at line 1063 | skipping to change at line 545 | |||
As long as there is: | As long as there is: | |||
* No Secondary Use | * No Secondary Use | |||
* Data Minimization and Transparency | * Data Minimization and Transparency | |||
* Reasonable Security | * Reasonable Security | |||
* No Personalization | * No Personalization | |||
These permitted uses and requirements are further discussed below. | These permitted uses and requirements are further discussed below. | |||
6.1.1 Enumerated Uses | 6.2.1 Global Requirements for Permitted Uses | |||
6.1.1.1 Short Term Collection and Use | ||||
Note | ||||
We have discussed allowing a N-week (anywhere from 1 week to 3 months) | ||||
grace period where third parties could collect and use data, partly due to | ||||
concerns , partly as a compromise to the market research/aggregate | ||||
reporting issue. We do not have consensus on this permitted use at this | ||||
point. If we decide to allow this, we would need to add non-normative text | ||||
explaining the rationale and providing examples. | ||||
Information may be collected and used any purpose, so long as the | ||||
information is retained for no longer than N weeks and the information is | ||||
not transmitted to a third party and the information is not used to build | ||||
a profile about a user or otherwise alter any individual's user experience | ||||
(apart from changes that are made based on aggregate data or security | ||||
concerns). | ||||
6.1.1.2 Contextual Content or Ad Delivery | ||||
Note | ||||
Note that it is not clear that this is in scope, per Shane; others | ||||
disagree. Revisit whether contextual belongs in some place other than | ||||
permitted uses (potentially the definition of collection). | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for the display of contextual content or advertisements, including content | ||||
or advertisements based on the first-party domain that the user visited. | ||||
6.1.1.2.1 Examples | ||||
This section is non-normative. | ||||
1. A user visits ExampleSports.com with DNT:1 enabled to read a news | ||||
article about a baseball game. ExampleSports uses the third party | ||||
ExampleAds to serve ads on ExampleSports.com. ExampleAds is not an | ||||
outsourcing partner of ExampleSports, and often uses third-party | ||||
behavioral data to serve targeted ads to users who have not enabled | ||||
DNT:1. ExampleAds may collect and use information about the user in | ||||
order to render an advertisement (including IP address and information | ||||
about the user agent) and information about the url of the news | ||||
article in order to render an advertisement related to the baseball | ||||
game. | ||||
2. A user visits ExampleLocalNews.com with DNT:1 enabled to read a news | ||||
article about a local fire. ExampleLocalNews uses the third party | ||||
ExampleWeather to display a weather widget on its site. ExampleWeather | ||||
is not an outsourcing partner of ExampleLocalNews. ExampleWeather may | ||||
collect and user information about the user in order to render the | ||||
weather widget (including IP address and information about the user | ||||
agent) and information about the domain of the news site in order to | ||||
render weather information related to the city which ExampleLocalNews | ||||
reports on. | ||||
6.1.1.3 Content or Ad Delivery Based on First Party Data | ||||
Note | ||||
Note that it is not clear that this is in scope, per Shane; others | ||||
disagree. Revisit whether contextual belongs in some place other than | ||||
permitted uses (potentially the definition of collection). | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for the display of content or advertisements based in part of data that | ||||
the third party previously collected from the user when acting as a first | ||||
party. | ||||
6.1.1.3.1 Examples | ||||
This section is non-normative. | ||||
1. A user visits ExampleNews.com with DNT:1 enabled to read a story about | ||||
a national election. ExamplesNews uses the third party ExamplePortal | ||||
to serve content and advertisements on its site. ExamplePortal is not | ||||
an outsourcing partner of ExampleNews. The user had previously visited | ||||
ExamplePortal.com with DNT:1 enabled and read several stories about | ||||
golf. ExamplePortal may serve an advertisement related to golf to that | ||||
same user on ExampleNews. However, ExamplePortal may not use the fact | ||||
that user went to ExampleNews to add to the user's ExamplePortal | ||||
profile, and may only retain and use information about that fact for a | ||||
permitted operational use. | ||||
2. A user visits Example Music with DNT:1 enabled to listen to recently | ||||
released albums streamed online. Example Music uses the third party | ||||
Example Social to provide a widget that shows users what their Example | ||||
Social friends have done on ExampleMusic. ExampleSocial is not an | ||||
outsourcing partner of ExampleMusic. The user is a member of | ||||
ExampleSocial and has several friends who also share information about | ||||
what they do on ExampleMusic on ExampleSocial. ExampleSocial may | ||||
display information that the users' friends had shared on | ||||
ExampleSocial related to ExampleMusic within its third-party widget on | ||||
ExampleMusic. However, ExampleSocial may not use the fact that user | ||||
went to ExampleMusic to add to the user's ExampleSocial profile, and | ||||
may only retain and use information about that fact for a permitted | ||||
operational use. | ||||
6.1.1.4 Frequency Capping | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for limiting the number of times that a user sees a particular | ||||
advertisement, often called "frequency capping". | ||||
In Seattle, we discussed specifically limiting how data was stored for | ||||
frequency capping: | ||||
Server-side frequency capping is allowed if the tracking identifier is | ||||
only retained in a form that is unique to each super-campaign (e.g., | ||||
one-way hashed with a campaign id) and does not include retention of the | ||||
user's activity trail (page URIs on which the ads were delivered) aside | ||||
from what is allowed for other permitted uses. | ||||
6.1.1.4.1 Examples | ||||
This section is non-normative. | ||||
A user visits ExampleNews with DNT:1 enabled. ExamplesNews uses the third | ||||
party ExampleAds to serve content and advertisements on its site. | ||||
ExampleAds is not an outsourcing partner of ExampleNews. ExampleAds has | ||||
previously shown the user an ad for ExampleCars fives times in the past | ||||
week on other sites. ExampleCars' contract with Example Ads states that | ||||
Example Ads will be paid less for impressions where the user sees an ad | ||||
more than five times in a week. ExampleAds may opt not to show the user | ||||
the ad for ExampleCars because the user has already seen the ad five times | ||||
on other sites. | ||||
6.1.1.5 Financial Logging and Auditing | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for financial fulfillment purposes such as billing and audit compliance. | ||||
This includes counting and verifying: | ||||
* ad impressions to unique visitors | ||||
* clicks by unique visitors | ||||
* subsequent action or conversion by unique visitors | ||||
* quality measures such as ad position on sites and the sites on which | ||||
the ads were served | ||||
Note | ||||
One potential compromise on the unique identifier issue for logging would | ||||
be grandfather in existing contracts that require unique, cookie-based | ||||
counting. New contracts would not be able to require that ad networks use | ||||
cookies (or other unique identifiers) to uniquely count users who have | ||||
DNT:1 enabled. | ||||
6.1.1.5.1 Examples | ||||
This section is non-normative. | ||||
Note | ||||
Add examples for display verification, click verification, CPA, quality | ||||
measures | ||||
6.1.1.6 Security and Fraud Prevention | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for detecting security risks and fraudulent activity, defending from | ||||
attacks and fraud, and maintaining integrity of the service. This includes | ||||
data reasonably necessary for enabling authentication/verification, | ||||
detecting hostile transactions and attacks, providing fraud prevention, | ||||
and maintaining system integrity. In this example specifically, this | ||||
information may be used to alter the user's experience in order to | ||||
reasonably keep a service secure or prevent fraud. | ||||
Note | ||||
The more likely options at this point may be represented in Nick Doty's | ||||
proposed: | ||||
To the extent reasonably necessary for protection of computers and | ||||
networks and to detect ad or other fraud, third parties may engage in | ||||
tracking. Use of graduated response is preferred. | ||||
or David Wainberg's proposed: | ||||
Parties may collect and use data in any way to the extent reasonably | ||||
necessary for the detection and prevention of malicious or illegitimate | ||||
activity. | ||||
6.1.1.6.1 Examples | ||||
This section is non-normative. | ||||
Note | ||||
Add examples with and without outsourced parties | ||||
6.1.1.7 Debugging | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for identifying and repairing errors that impair existing intended | ||||
functionality. | ||||
6.1.1.7.1 Discussion | ||||
This section is non-normative. | ||||
Detailed information is often necessary to replicate a specific user's | ||||
experience to understand why their particular set of variables is | ||||
resulting in a failure of expected functionality or presentation. These | ||||
variables could include items such as cookie IDs, page URLs, device or UA | ||||
details, content specifics, and activity/event specifics to narrow in on | ||||
the cause of the discrepancy. | ||||
6.1.1.7.2 Examples | ||||
This section is non-normative. | ||||
A user visits ExampleBlog with DNT:1 enabled. Example News uses the third | ||||
party ExampleAds to serve content and advertisements on its site. | ||||
ExampleAds is not an outsourcing partner of ExampleBlog. ExampleAds | ||||
retains [to be determined data fields] in order to later replicate users' | ||||
experiences in receiving its ads to subsequently diagnose problems and | ||||
understand why their particular set of variables resulted in a failure of | ||||
expected functionality or presentation. | ||||
6.1.1.8 Aggregate Reporting | ||||
6.1.1.8.1 Option 1: Aggregate Reporting | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for aggregate reporting, such as market research and product improvement. | ||||
Data MAY be collected and retained on an individual level, but the use of | ||||
the data must only be aggregate reporting, and the products of the | ||||
reporting MUST be unlinkable as defined in this document. | ||||
6.1.1.8.2 Option 2: Aggregate Reporting | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for aggregate reporting, such as market research and product improvement, | ||||
if that information is collected and retained for another enumerated | ||||
permitted use. Data MAY be collected and retained on an individual level, | ||||
but the use of the data must only be aggregate reporting, and the products | ||||
of the reporting MUST be unlinkable as defined in this document. If the | ||||
operator no longer has another enumerated permitted use for which to use | ||||
and retain the data, the operator MAY NOT use and retain the data for | ||||
aggregate reporting unless the data has been rendered unlinkable as | ||||
defined in this document. | ||||
6.1.1.8.3 Option 3: No Aggregate Reporting | ||||
There is no permitted use for aggregate reporting outside of the grace | ||||
period described earlier. | ||||
Issue 25: Possible exception for research purposes | ||||
6.1.1.9 Compliance With Local Laws and Public Purposes | ||||
Note | ||||
The group has generally agreed that companies can collect and process data | ||||
as required by local law despite the DNT:1 signal and still comply with | ||||
this standard. We have also conceptually agreed that companies cannot | ||||
exploit this language by creating contractual requirements between | ||||
companies to collect data as a "legally required" basis for the collection | ||||
and use of data despite a DNT:1 signal. | ||||
Regardless of DNT signal, information may be collected, retained and used | ||||
for complying with local laws and public purposes, such as copyright | ||||
protection and delivery of emergency services. | ||||
6.1.2 Additional Requirements for Permitted Uses | ||||
In order to use the Permitted Uses outlined, a party must comply with | In order to use the permitted uses outlined below, a party MUST comply | |||
these four requirements. | with these four requirements. | |||
6.1.2.1 No Secondary Uses | 6.2.1.1 No Secondary Uses | |||
Third Parties MUST NOT use data retained for permitted uses for | Third Parties MUST NOT use data retained for a permitted use for | |||
non-permitted uses. | non-permitted uses. | |||
6.1.2.2 Data Minimization and Transparency | 6.2.1.2 Data Minimization and Transparency | |||
A third party MUST ONLY retain information for a Permitted Use for as long | Data retained by a party for permitted uses MUST be limited to the data | |||
as is reasonably necessary for that use. Third parties MUST make | reasonably necessary for such permitted uses, and MUST be retained no | |||
reasonable data minimization efforts to ensure that only the data | longer than is reasonably necessary for such permitted uses. A third party | |||
necessary for the permitted use is retained. A third party MUST provide | MUST make reasonable data minimization efforts to ensure that only data | |||
public transparency of their data retention period. The third party MAY | necessary for each permitted use is retained. A third party MUST provide | |||
enumerate each individually if they vary across Permitted Uses. Once the | public transparency of their data retention period for each permitted use. | |||
period of time for which you have declared data retention for a given use, | Once a retention period for a given use has expired, the data MUST NOT be | |||
the data MUST NOT be used for that permitted use. After there are no | used for that permitted use; when there are no remaining permitted uses | |||
remaining Permitted Uses for given data, the data must be deleted or | for some data, that data MUST either be deleted or rendered unlinkable. | |||
rendered unlinkable. | ||||
Note | Additional proposed language: | |||
May be worthwhile to put some examples in around when it is or isn't a | Where feasible, a third party SHOULD NOT collect linkable data when that | |||
good idea to explain use, ie, Commonly Accepted Practices vs. security | data is not reasonably necessary for one of the permitted uses. In | |||
data to address unique businesses | particular, data not necessary for a communication (for example, cookie | |||
data, URI parameters, unique identifiers inserted by a network | ||||
intermediary) MUST NOT be retained unless reasonably necessary for a | ||||
particular permitted use. | ||||
6.1.2.3 Reasonable Security | 6.2.1.3 Reasonable Security | |||
Third parties MUST use reasonable technical and organizational safeguards | Third parties MUST use reasonable technical and organizational safeguards | |||
to prevent further processing of data retained for Permitted Uses. While | to prevent further processing of data retained for Permitted Uses. While | |||
physical separation of data maintained for permitted uses is not required, | physical separation of data maintained for permitted uses is not required, | |||
best practices should be in place to ensure technical controls ensure | best practices should be in place to ensure technical controls ensure | |||
access limitations and information security. Third parties SHOULD ensure | access limitations and information security. Third parties SHOULD ensure | |||
that the access and use of data retained for Permitted Uses is auditable. | that the access and use of data retained for Permitted Uses is auditable. | |||
Note | 6.2.1.4 No Personalization | |||
Whether or not an audit, or the type of audit, is mandated is still in | ||||
discussion; an optional field exists in the TPE spec for auditors and | ||||
self-regulatory commitments. The audit section of the TPE should be | ||||
cross-referenced here. | ||||
6.1.2.4 No Personalization | ||||
Outside of Security and Frequency Capping, data retained for Permitted | Outside of Security and Frequency Capping, data retained for Permitted | |||
Uses MUST NOT be used to alter a specific user's online experience based | Uses MUST NOT be used to alter a specific user's online experience [based | |||
on multi-site activity. | on multi-site activity]. | |||
6.1.2.5 No Persistent Identifiers | 6.2.1.5 No Persistent Identifiers | |||
A third party may only collect, use, and retain for permitted uses | A third party may only collect, use, and retain for permitted uses | |||
information that a user agent necessarily shares with a web server when it | information that a user agent necessarily shares with a web server when it | |||
communicates with the web server (e.g. IP address and User-Agent), and the | communicates with the web server (e.g. IP address and User-Agent), and the | |||
URL of the top-level page, communicated via a Referer header or other | URL of the top-level page, communicated via a Referer header or other | |||
means, unless the URL contains information that is not unlinkable (e.g. a | means, unless the URL contains information that is not unlinkable (e.g. a | |||
username or user ID). | username or user ID). | |||
A third party may not collect, use, or retain information that a web | A third party may not collect, use, or retain information that a web | |||
server could cause to not be sent but still be able to communicate with | server could cause to not be sent but still be able to communicate with | |||
the user agent (e.g. a cookie or a Request-URI parameter generated by the | the user agent (e.g. a cookie or a Request-URI parameter generated by the | |||
user agent), except the URL of the top-level page, or any data added by a | user agent), except the URL of the top-level page, or any data added by a | |||
network intermediary that the operator of a web server has actual | network intermediary that the operator of a web server has actual | |||
knowledge of (e.g. a unique device identifier HTTP header). | knowledge of (e.g. a unique device identifier HTTP header). | |||
Flexibility is provided to implementers on how they accomplish permitted | ||||
uses and minimize data retention and use. Implementers are advised to | ||||
avoid data collection for DNT:1 users where feasible to enable external | ||||
confidence. | ||||
Placing third-party cookies with unique identifiers (and other techniques | ||||
for linking data to a user, user agent or device) are permitted where | ||||
reasonably necessary for a permitted use. Requirements on minimization and | ||||
secondary use, however, provide limitations on when any collection | ||||
technique is compatible with a Do Not Track preference and what the | ||||
implications of that collection are. | ||||
To give flexibility to implementers in accomplishing the requirements of | ||||
this specification and the listed permitted uses, no particular data | ||||
collection techniques are prescribed or prohibited. Implementers are | ||||
advised that collection of user data under a Do Not Track preference | ||||
(including using unique tracking cookies or browser fingerprinting) may | ||||
reduce external auditability, monitoring and user confidence and that | ||||
retention of such data may imply liability in certain jurisdictions in | ||||
cases of secondary use; for more information, see the Global | ||||
Considerations. | ||||
Note | Note | |||
The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement | The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement | |||
that permitted use data is not correlated to a unique cookie or other | that permitted use data is not correlated to a unique cookie or other | |||
persistent identifier. This issue remains one of the biggest areas of | persistent identifier. This issue remains one of the biggest areas of | |||
dispute in the working group, as the industry proposal allows for the use | dispute in the working group, as the industry proposal allows for the use | |||
of cookies and other unique identifiers by third parties despite a DNT:1 | of cookies and other unique identifiers by third parties despite a DNT:1 | |||
instruction. | instruction. | |||
6.2 Geolocation compliance by a third party | 6.2.2 Enumerated Permitted Uses | |||
6.2.2.1 Short Term Collection and Use | ||||
Information may be collected, retained, and used any purpose, so long as | ||||
the information is retained for no longer than N weeks and the information | ||||
is not transmitted to a third party and the information is not used to | ||||
build a profile about a user or otherwise alter any individual's user | ||||
experience (apart from changes that are made based on aggregate data or | ||||
security concerns). | ||||
Operators MAY collect and retain data related to a communication in a | ||||
third-party context for up to N weeks. During this time, operators may | ||||
render data deidentified or perform processing of the data for any of the | ||||
other permitted uses. | ||||
Issue 134: Would we additionally permit logs that are retained for a short | ||||
enough period? | ||||
Issue 142: How should protocol data be allowed to be used in the first N | ||||
weeks? | ||||
6.2.2.2 Contextual Content or Ad Delivery | ||||
Note | Note | |||
Unclear whether this section reflects group consensus. | Note that it is not clear that this is in scope. Revisit whether | |||
contextual belongs in some place other than permitted uses (potentially | ||||
the definition of collection). | ||||
Issue 39: Tracking of geographic data (however it's determined, or used) | Information may be collected, retained and used for the display of | |||
contextual content or advertisements, including content or advertisements | ||||
based on the first-party domain that the user visited. | ||||
If the operator of a third-party domain receives a communication to which | 6.2.2.3 Content or Ad Delivery Based on First Party Data | |||
a DNT:1 header is attached: | ||||
1. Geo-location information that is more granular than postal code is too | Information may be collected, retained and used for the display of content | |||
granular. Geolocation data must not be used at any level more granular | or advertisements based in part on data that the third party previously | |||
than postal code. Note that while the number of people living in a | collected from the user when acting as a first party. | |||
postal code varies from country to country, postal codes are extant | ||||
world-wide. | ||||
2. If specific consent has been granted for the use of more granular | ||||
location data, than that consent prevails. | ||||
6.2.1 Discussion | Note | |||
This section is non-normative. | This permitted use does not reflect consensus. Some members of the group | |||
do not think first party data should be used in a third-party context | ||||
(this option is reflected in the optional text for First Party Compliance | ||||
above). | ||||
It is acceptable to use data sent as part of this particular network | This text may be revised to offer two alternatives: first parties can use | |||
interaction when composing a response to a DNT:1 request, but it is not | any data to offer content in the third party context, or first parties can | |||
acceptable to store that data any longer than needed to reply. For | only use declared data to offer content in the third party context. Shane | |||
instance, it would be appropriate to use an IP address to guess which | Wiley has proposed defining "declared data" as Information directly and | |||
country a user is in, to avoid showing them an advertisement for products | expressly supplied by a user to a party through meaningful interaction | |||
or services unavailable where they live. | with that party. | |||
When using request-specific information to compose a reply, some levels of | The issue is also contingent upon what identifiers third parties can use | |||
detail may feel invasive to users, and may violate their expectations | in when Do Not Track is turned on. If third parties cannot read cookies, | |||
about Do Not Track. These sorts of detailed assessments should be avoided. | they may be unable to associate first parties in third-party scenarios. | |||
6.2.2 Examples | Others have argued that this language is unnecessary because the standard | |||
places no limitations on the use of first party data. | ||||
This section is non-normative. | Issue 54: can first parties use declared data while in a 3rd party | |||
context? | ||||
Reasonable behavior: A user visits you from an IP address which a general | 6.2.2.4 Frequency Capping | |||
geo-IP database suggests is in the NYC area, where it is 6pm on a Friday. | ||||
You choose to show an advertisement for theaters and restaurants in the | ||||
area. | ||||
Invasive behavior: A user visits you from an IP address which suggests | Information may be collected, retained and used for limiting the number of | |||
that they are in a particular ZIP+4, which has a distinctive demographic | times that a user sees a particular advertisement, often called "frequency | |||
profile. Their user-agent indicates that they are a Mac user, further | capping." | |||
narrowing their expected profile. You serve them an ad for business within | ||||
a few blocks of them which specializes in items which their expected | ||||
profile indicates they may enjoy. | ||||
In this example, even though the decision about which ad to serve was | Operators MAY retain data related to a communication in a third-party | |||
based exclusively on request specific information, but was still tailored | context to use for limiting how often advertisements are shown to a | |||
to a highly-specific user profile. In particular, the estimation of a | particular user if the data retained do not include the user's browsing | |||
user's location to within a single ZIP+4 may make a user feel that they | history (for example, page URIs on which ads were past delivered). For | |||
are being followed closely, even if the decision was made on the fly, and | this permitted use, operators MUST NOT construct profiles of users or user | |||
the information was only held ephemerally. | behavior based on their ad frequency history or otherwise alter the user's | |||
experience based on this data. | ||||
6.3 User-Granted Exceptions | 6.2.2.5 Financial Logging and Auditing | |||
Information may be collected, retained and used for billing and auditing | ||||
of concurrent transactions. This may include counting ad impressions to | ||||
unique visitors, verifying positioning and quality of ad impressions and | ||||
auditing compliance with this and other standards. | ||||
Issue 22: Still have operational use of data (auditing of where ads are | ||||
shown, impression tracking, etc.) | ||||
6.2.2.6 Security and Fraud Prevention | ||||
Information may be collected, retained and used to the extent reasonably | ||||
necessary for detecting security risks and fraudulent or malicious | ||||
activity. This includes data reasonably necessary for enabling | ||||
authentication/verification, detecting hostile and invalid transactions | ||||
and attacks, providing fraud prevention, and maintaining system integrity. | ||||
In this example specifically, this information may be used to alter the | ||||
user's experience in order to reasonably keep a service secure or prevent | ||||
fraud. Graduated response is preferred when feasible. | ||||
Note | Note | |||
Figure out which parts of UGE belong in which document. | There has been an unresolved discussion on whether "graduated response" | |||
should be in the normative text, defined, addressed through non-normative | ||||
examples, or not included at all. | ||||
Issue 24: Possible exemption for fraud detection and defense | ||||
6.2.2.7 Debugging | ||||
Information may be collected, retained and used for identifying and | ||||
repairing errors that impair existing intended functionality. | ||||
6.2.2.8 Audience Measurement | ||||
Note | ||||
The group has recently debated whether to include a permitted use for the | ||||
collection of third-party data to calibrate audience measurement primarily | ||||
conducted through the use of opt-in panels. The most recent proposal by | ||||
ESOMAR is available, but the language is not consensus, and the working | ||||
group has not decided whether such a permitted use is even appropriate. | ||||
Issue 25: Possible exemption for research purposes | ||||
6.2.2.9 Compliance With Local Laws and Public Purposes | ||||
Adherence to laws, legal and judicial process, and regulations take | ||||
precedence over this standard when applicable, but contractual obligations | ||||
do not. | ||||
6.3 User-Granted Exceptions | ||||
When a user sends the DNT:0 signal, they are expressing a preference for a | ||||
personalized experience. This signal indicates explicit consent for data | ||||
collection, retention, processing, disclosure, and use by the recipient of | ||||
this signal to provide a personalized experience for the user. This | ||||
recommendation places no restrictions on data collected from requests | ||||
received with DNT:0. | ||||
The operator of a website may engage in practices otherwise described by | The operator of a website may engage in practices otherwise described by | |||
this standard if the user has given explicit and informed consent. This | this standard if the user has given explicit and informed consent. This | |||
consent may be obtained through the browser API defined in the companion | consent may be obtained through the browser API defined in the companion | |||
[TRACKING-DNT] document, or an operator of a website may also obtain | [TRACKING-DNT] document, or an operator of a website may also obtain | |||
"out-of-band" consent to disregard a "Do Not Track" preference using a | "out-of-band" consent to disregard a "Do Not Track" preference using a | |||
different technology. If an operator is relying on "out of band" consent | different technology. If an operator is relying on "out of band" consent | |||
to disregard a "Do Not Track" instruction, the operator must indicate this | to disregard a "Do Not Track" instruction, the operator must indicate this | |||
consent to the user agent as described in the companion [TRACKING-DNT] | consent to the user agent as described in the companion [TRACKING-DNT] | |||
document. | document. | |||
This protocol does not define what constitutes explicit consent in any | ||||
jurisdiction; check with your lawyer. | ||||
User agents and web sites MUST obtain express and informed consent when | ||||
setting controls that affect the tracking preference expression. The | ||||
controls MUST communicate the user's preference in accordance with the | ||||
[TRACKING-DNT] recommendation. | ||||
User agents and web sites offering tracking preference choices to users | ||||
MUST follow the following user interface guidelines: | ||||
1. User agents and web sites are responsible for determining the user | ||||
experience by which a tracking preference is controlled; | ||||
2. User agents and web sites MUST ensure that tracking preference choices | ||||
are communicated to users clearly and accurately, and shown at the time | ||||
and place the tracking preference choice is made available to a user; | ||||
3. User agents and web sites SHOULD ensure that the tracking preference | ||||
choices describe the parties to whom DNT applies and SHOULD make available | ||||
explanatory text to provide more detailed information about DNT | ||||
functionality. | ||||
6.3.1 Interaction with existing user privacy controls | 6.3.1 Interaction with existing user privacy controls | |||
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out | Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out | |||
signals at the same time, it'll be important to ensure industry and web | signals at the same time, it'll be important to ensure industry and web | |||
browser vendors are on the same page with respect to honoring user choices | browser vendors are on the same page with respect to honoring user choices | |||
in circumstances where "mixed signals" may be received. | in circumstances where "mixed signals" may be received. | |||
As a general principle, more specific settings override less specific | As a general principle, more specific settings override less specific | |||
settings. | settings. | |||
1. No DNT Signal / No Opt-Out: Treat as DNT unset | 1. No DNT Signal / No Opt-Out: Treat as DNT unset | |||
2. DNT Signal / No Opt-Out: Treat as DNT:1 | 2. DNT Signal / No Opt-Out: Treat as DNT:1 | |||
3. Opt-Out / No DNT Signal: Treat as DNT:1 | 3. Opt-Out / No DNT Signal: Treat as DNT:1 | |||
4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; | 4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; | |||
DNT User-Granted Exception is honored | DNT User-Granted Exception is honored | |||
6.3.2 Logged In Transactions | 6.4 Exception for Deidentified Data | |||
Note | ||||
Add note that we may be able to handle this section entirely within the | ||||
consent definition, rather than calling it out; potentially thought an | ||||
example in the consent section. Concern about UI creep. | ||||
Issue 65: How does logged in and logged out state work | ||||
6.4 Disregarding Non-Compliant User Agents | ||||
Note | If a third party receives a communication to which a DNT:1 header is | |||
attached, that third party MAY neverthess collect, retain, share, or use | ||||
data related to that communication if the data is or has been rendered | ||||
deidentified. | ||||
this section is the topic of active debate. | 6.5 Disregarding Non-Compliant User Agents | |||
Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly | Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly | |||
formed even if the third party does not believe that the DNT:1 header was | formed even if the third party does not believe that the DNT:1 header was | |||
set with the explicit and informed consent of the user. | set with the explicit and informed consent of the user. | |||
If the operator of a third-party domain has a good faith belief that a | If the operator of a third-party domain has a good faith belief that a | |||
user agent is sending a DNT:1 without the explicit and informed consent of | user agent is sending a DNT:1 without the explicit and informed consent of | |||
the user, the operator MAY disregard the DNT:1 header and collect, use, | the user, the operator MAY disregard the DNT:1 header and collect, use, | |||
and retain information about the user as if no DNT signal had been sent. | and retain information about the user as if no DNT signal had been sent. | |||
If the operator disregards the DNT signal, the operator MUST signal to the | If the operator disregards the DNT signal, the operator MUST signal to the | |||
user agent that it is disregarding the header as described in the | user agent that it is disregarding the header as described in the | |||
companion [TRACKING-DNT] document. | companion [TRACKING-DNT] document. | |||
No provision on Disregarding Non-Compliant User Agents. | If the operator of a third-party domain does not intend to comply with a | |||
DNT:1 signal whose syntax is correctly formed, the operator MUST send a | ||||
6.5 Degrading User Experience for DNT:1 users | signal to the user agent that it is disregarding the header as described | |||
in the companion [TRACKING-DNT] document. | ||||
Note | No provision on disregarding non-compliant user agents. | |||
We have consensus that it's fine to degrade the experience for DNT:1 | Issue 161: Do we need a tracking status value for partial compliance or | |||
transactions, but need to find the text. | rejecting DNT? | |||
Issue 93: Should 1st parties be able to degrade a user experience or | On the [TRACKING-DNT] document, we have this pending-review issue | |||
charge money for content based on DNT? | regarding communicating disregarding a user/agent. | |||
6.6 Public Disclosure of Compliance | 6.6 Public Disclosure of Compliance | |||
Note | Note | |||
Final wording awaits how the response is designed in the TRACKING-DNT | Final wording awaits how the response is designed in the TRACKING-DNT | |||
recommendation, but we agree upon the general direction below. | recommendation, but we agree upon the general direction below. | |||
In order to be in compliance with this specification, a third party must | In order to be in compliance with this specification, a third party must | |||
make a public commitment that it complies with this standard. A "public | make a public commitment that it complies with this standard. A "public | |||
commitment" may consist of a statement in a privacy policy, a response | commitment" may consist of a statement in a privacy policy, a response | |||
header, a machine-readable tracking status resource at a well-known | header, a machine-readable tracking status resource at a well-known | |||
location, or any other reasonable means. This standard does not require a | location, or any other reasonable means. This standard does not require a | |||
specific form of public commitment. | specific form of public commitment. | |||
6.6.1 Third Party Auditing | ||||
Issue 21: Enable external audit of DNT compliance | ||||
Tracking Status Qualifiers may include a value to indicate auditing. | ||||
A. Acknowledgements | A. Acknowledgements | |||
This specification consists of input from many discussions within and | This specification consists of input from many discussions within and | |||
around the W3C Tracking Protection Working Group, along with written | around the W3C Tracking Protection Working Group, along with written | |||
contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando | contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando | |||
(Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), | (Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), | |||
Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), | Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), | |||
Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson | Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson | |||
(Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), | (Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), | |||
David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and | David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and | |||
skipping to change at line 1573 | skipping to change at line 897 | |||
Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm | Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm | |||
(Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web | (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web | |||
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot | Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot | |||
Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. | Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. | |||
B. References | B. References | |||
B.1 Normative references | B.1 Normative references | |||
[HTTP11] | [HTTP11] | |||
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June | R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June | |||
1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt | 1999. RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt | |||
[TRACKING-DNT] | [TRACKING-DNT] | |||
Roy T. Fielding; David Singer. Tracking Preference Expression | Roy T. Fielding; David Singer. Tracking Preference Expression | |||
(DNT). 2 October 2012. W3C Working Draft. (Work in progress.) URL: | (DNT). 02 October 2012. W3C Working Draft. URL: | |||
http://www.w3.org/TR/2012/WD-tracking-dnt-20121002/ | http://www.w3.org/TR/tracking-dnt/ | |||
B.2 Informative references | ||||
[KnowPrivacy] | ||||
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June | ||||
2009. URL: | ||||
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf | ||||
End of changes. 130 change blocks. | ||||
1188 lines changed or deleted | 512 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |