This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.
This document is an editors' strawman reflecting a snapshot of live discussions within the Tracking Protection Working Group. It does not yet capture all of our work. For example, we have issues that are [PENDING REVIEW] with complete text proposals that have not yet made it into this draft. Text in blue boxes presents multiple options the group is considering. Options included in this draft should not be read as limitations on the potential outcome, but rather simply as possible options that are currently under consideration by the working group. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document.
This introduction will be re-worked after details of substantive text is closer to being finalized.
The World Wide Web (WWW, or Web) consists of millions of sites 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.
This section consists of proposed text that is meant to address ISSUE-6 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:
This standard has limited applicability to any practices by first parties, their service providers, subsidiaries, or affiliated companies. Under the standard, first parties may and will continue to collect and use data for tracking and other purposes. This standard is primarily directed at third parties.
This solution is intended to be persistent, technology neutral, and reversible by the user. It aims to preserve a vibrant online ecosystem, 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.
A user is an individual human. When user-agent software accesses online resources, whether or not the user understands or has specific knowledge of a particular request, that request is made "by" the user.
This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including but not limited to browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [[!HTTP11]].
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.
A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person which acts as a functional entity. A set of functional entities is considered affiliated when they are related by both common majority ownership and common control, and affiliation is made easily discoverable by a user.
A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person. For unique corporate entities to qualify as a common party with respect to this document, those entities MUST be commonly owned and commonly controlled (Affiliates) and MUST provide “easy discoverability” of affiliate organizations. An “Affiliate List” MUST be provided within one click from each page or the entity owner clearly identified within one click from each page.
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.
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.
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:
An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)
Outsourced companies that act purely as vendors for their customers (often first parties in this context) are not the intended target for the Tracking Preference Expression but it is important there are no unintended activities that are extended to another party through this allowance. In all cases, its expected an outsourced company acting on the part of a customer follows all of the same restrictions placed on that customer.
For the data separation requirement, outsourced companies have technical options to achieve appropriate separation but in each the critical element is that data is never reconstituted for users that have indicated a preference not to be tracked. One possible approach would be to leverage a per partner hash against a common cookie identifier, ensuring the resulting identifier is consistent for a specific customer, but is unable to be linked with another customer’s identifier.
Contractual requirements that enforce data rights and responsibilities for separation are a critical element of establishing an outsourcer acting on another party’s behalf. Contracts may occur directly through parties (for example, a Publisher in an Ad Network) or between intermediaries (for example, an Ad Network acting through an Ad Exchange). In either case, data separation and removal of independent rights are necessary elements that must survive intermediary contractual constructs.
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
are necessary, but not necessarily sufficient, technical precautions.
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.
The same-origin policy silos stored data by domain name. An outsourcing service can use a different domain name for each first party.
Example Analytics provides an outsourced analytics service to Example News
and Example Sports, two unrelated websites. Example Analytics stores its
cookies for Example News at examplenews.exampleanalytics.com, and it
stores its cookies for Example Sports at
examplesports.exampleanalytics.com.
The HTTP cookie path can be used to silo data to a first party.
Example Analytics stores its cookies for Example News with
"Path=/examplenews", and it stores its cookies for Example Sports with
"Path=/examplesports".
For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.
Example Analytics stores data for Example News at
window.localStorage["examplenews"] and data for Example Sports at
window.localStorage["examplesports"].
An outsourcing service should encrypt each first party's data with a different set of keys.
An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.
An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.
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.
Throughout all data collection, retention, and use, outsourced parties MUST use sufficient internal practices to prevent the identification of data from different parties.
An outsourcing service should establish a clear internal policy that gives guidance on how to collect, retain, and use outsourced data in compliance with this standard.
Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.
An outsourcing service should establish a supervision and reporting structure for detecting improper access.
External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices. Auditor reports should be made available to the public.
An outsourced service:
A party's representation that it is in compliance with this standard includes a representation that its outsourcing parties comply with this standard.
A First party or Third party MUST enter into a contract with an outsourced party that requires that outsourced party to comply with these requirements.
Outsourced service providers are considered to be the same party as their clients if the outsourced service providers only act as data processors on behalf of that party in relation to that party, silo the data so that it cannot be accessed by other parties, and have no control over the use or sharing of that data except as directed by that party.
Service Providers acting on the behalf of a First party or Third party, and with no independent rights to use that party’s data outside of the context of that party and Permitted Uses, are also considered to be acting as that party.
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.
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
There has been some disagreement within the group over how many first parties there should be in any one network interaction. These three options lay out the range of possibilities; the first is text that has been before the group for some time, the others are new.
There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.
There can be only one first party in any network transaction absent additional meaningful interaction with otherwise third party content on the webpage. The first party is the registrant and operator of the domain that the user intentionally communicated with.
If a user intends to communicate with a party that utilizes a
different party as a platform, then both parties are first
parties in the network transaction.
Example: ExampleSports franchise has a dedicated page on
a ExampleSocial. When a user visits this dedicated page, both
ExampleSports and ExampleSocial are first parties.
A party may start out as a third party but become a first party later on, after a user interacts with it. If content from a third party is embedded on a first party page, the third party may become an additional first party if it can infer with high probability that the average user knowingly and intentionally communicated with it. If a user merely moused over, closed, or muted third-party content, the party would not be able to draw such an inference.
Examples
First Party is the party that owns or has control over the resource the consumer visits. A First Party also includes the owner or controller of an embedded widget, search box or similar service with which a consumer interacts.
If a user merely mouses over, closes, or mutes third-party content, that 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 the user. It is possible to have multiple first parties on a single page but each party must provide clear branding and a link to their respective privacy policy (co-branded experience).
There is debate about whether to use the terms unlinkable, unlinked, or unidentified to describe this type of data.
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.
A dataset is unlinkable when there is a high probability
that it contains only information that could not be linked to a
particular user, user agents, or device by a skilled analyst. A
party renders a dataset unlinkable when either:
1. it publicly publishes information that is sufficiently detailed
for a skilled analyst to evaluate the implementation, or
2. ensure that the dataset is at least 1024-unlinkable.
A "network interaction" is an HTTP request and response, or any other sequence of logically related network traffic.
Non-normative explanatory text: Determination of a party's status is limited to a single interaction because a party's status may be affected by time, context, or any other factor that influences user expectations.
These continue to be actively debated issues, as the resolution of the use of unique identifiers is likely to end up in these definitions.
The definitions of collection, retention, use, and sharing are drafted expansively so as to comprehensively cover a party's user-information practices. These definitions do not require a party's intent; a party may inadvertently collect, retain, use, or share data. The definition of collection includes information that a party did not cause to be transmitted, such as protocol headers.
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.
A party may receive, retain, and use data as otherwise prohibited by this standard, so long as it is unaware of such information practices and has made reasonable efforts to understand its information practices. If a party learns that it possesses information in violation of this standard, it must delete that information at the earliest practical opportunity.
The term "tracking" is not used in the document. This section is likely to be deleted, and the issues will be addressed in the definitions of "collection" and "unlinkable" above.
Concerns with this section include undefined term "user data" plus as written, this may apply more broadly than the authors intended
Tracking is the collection or use of user data via either a unique identifier or a correlated set of data points being used to approximate a unique identifier, in a context other than "first party" as defined in this document. This includes:
Examples of tracking use cases include:
Tracking is defined as following or identifying a user, user agent, or device across multiple visits to a site (time) or across multiple sites (space).
Mechanisms for performing tracking include but are not limited to:
A preference of "Do Not Track" means that the user does not want tracking to be engaged for this request, including any mechanism for performing tracking, any use of data retained from prior tracking, and any retention or sharing of data from this request for the purpose of future tracking, beyond what is necessary to enable:
One proposal is not to define "tracking," but rather to list what is, or is not, required and allowed in order to comply with the recommendation.
The spec currently envisions that users should consent to both the setting of a DNT preference as well as any user-granted exceptions. We have not reached agreement on how precisely we need to define this term.
Explicit and informed choice must satisfy the following bright-line
requirements:
1. Actual presentation: The choice mechanism MUST be
actually presented to the user. It MUST NOT be on a linked page,
such as a terms of service or privacy policy.
2. Clear Terms:The choice mechanism MUST use clear,
non-confusing technology.
3. Independent choice: The choice mechanism MUST be
presented independent of other choices. It MUST NOT be bundled with
other user preferences.
4. No default permission: The choice MUST NOT have the user
permission selected by default.
No definition, other than explicitly leaving the definition of consent to local rules.
This language is not consensus and must change. The parties are generally 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 attached, First Parties may engage in their normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience.
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 Recommendation.
A user agent MUST offer a control to express a tracking preference to third parties. The control MUST communicate the user's preference in accordance with the [[!TRACKING-DNT]] recommendation and otherwise comply with that recommendation. A user agent MUST NOT express a tracking preference for a user unless the user has given express and informed consent to indicate a tracking preference.
We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., "Privacy settings: high"). Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.
Shane's proposal has suggested the additional compliance requirements
of user agents:
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 functionality
2. Any User Agent claiming compliance must have a functional
implementation of the browser exceptions in this specification
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 attached:
These are options that have been discussed in the group. While many have broad consensus within the group, some are debated both based on scope of the draft and whether they should be permitted uses. There is also substantial disagrement over the SCOPE of information that may be collected, used, and retained for these purposes, most notably whether persistent unique identifiers may be collected, used, and retained for these purposes.
If a third-party receives a communication to which a DNT:1 header is attached, that third party MAY nevertheless collect, use, and retain information related to that communication for these permitted uses:
As long as there is:
These permitted uses and requirements are further discussed below.
In order to use the Permitted Uses outlined below, a party MUST comply with these four requirements.
Third Parties MUST NOT use data retained for permitted uses for non-permitted uses.
Data retained by a party for permitted uses MUST be limited to the data reasonably necessary for such permitted uses, and MUST be retained no longer than is reasonably necessary for such permitted uses. Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained. A third party MUST provide public transparency of their data retention period. The third party MAY enumerate each individually if they vary across Permitted Uses. Once the period of time for which you have declared data retention for a given use has expired, the data MUST NOT be used for that permitted use. After there are no remaining Permitted Uses for given data, the data must be deleted or rendered unlinkable.
Jonathan Mayer to provide non-normative examples per ACTION-298.
Third parties MUST use reasonable technical and organizational safeguards to prevent further processing of data retained for Permitted Uses. While physical separation of data maintained for permitted uses is not required, best practices should be in place to ensure technical controls ensure access limitations and information security. Third parties SHOULD ensure that the access and use of data retained for Permitted Uses is auditable.
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.
Outside of Security and Frequency Capping, data retained for Permitted Uses MUST NOT be used to alter a specific user's online experience based on multi-site activity.
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 communicates with the web server (e.g. IP address
and User-Agent), and the URL of the top-level page, communicated
via a Referer header or other means, unless the URL contains
information that is not unlinkable (e.g. a username or user
ID).
A third party may not collect, use, or retain information that a
web server could cause to not be sent but still be able to
communicate with the user agent (e.g. a cookie or a Request-URI
parameter generated by the user agent), except the URL of the
top-level page, or any data added by a network intermediary that
the operator of a web server has actual knowledge of (e.g. a
unique device identifier HTTP header).
The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement that permitted use data is not correlated to a unique cookie or other persistent identifier. This issue remains one of the biggest areas of dispute in the working group, as the industry proposal allows for the use of cookies and other unique identifiers by third parties despite a DNT:1 instruction.
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).
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.
Regardless of DNT signal, information may be collected, retained and used for the display of content or advertisements based in part on data that the third party previously collected from the user when acting as a first party.
This text will be revised to offer two alternatives:
first parties can use any data to offer content in the third party
context, or first parties can only use declared data to offer
content in the third party context. The issue is also contingent
upon what identifiers third parties can use in when Do Not Track is
turned on. If third parties cannot read cookies, they may be
unable to associate first parties in third-party scenarios.
Others have argued that this language is unnecessary because the
standard places no limitations on the use of first party data.
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.
A user visits ExampleNews with DNT:1 enabled. ExampleNews 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 five 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.
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:
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.
Add examples for display verification, click verification, CPA, quality measures
To the extent reasonably necessary for detecting security risks and fraudulent or malicious activity, parties may collect, retain, and use data regardless of a DNT signal. 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.
Add examples with and without outsourced parties (J- not sure what this means)
Regardless of DNT signal, information may be collected, retained and used for identifying and repairing errors that impair existing intended functionality.
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.
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.
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.
There had previously been an open debate about whether Aggregate Reporting (including market research and product improvement) should be a dedicated Permitted Use. The group has since decided to address this issue through the exception for Unlinkable Data.
Unclear whether this section reflects group consensus.
If the operator of a third-party domain receives a communication to which a DNT:1 header is attached:
When using request-specific information to compose a reply, some levels of detail may feel invasive to users, and may violate their expectations about Do Not Track. These sorts of detailed assessments should be avoided.
Reasonable behavior: A user visits you from an IP address which a general geo-IP database suggests is in the NYC area, where it is 6pm on a Friday. You choose to show an advertisement for theaters and restaurants in the area.
Invasive behavior: A user visits you from an IP address which suggests that they are in a particular ZIP+4, which has a distinctive demographic profile. Their user-agent indicates that they are a Mac user, further narrowing their expected profile. You serve them an ad for business within a few blocks of them which specializes in items which their expected profile indicates they may enjoy.
In this example, even though the decision about which ad to serve was based exclusively on request specific information, but was still tailored to a highly-specific user profile. In particular, the estimation of a user's location to within a single ZIP+4 may make a user feel that they are being followed closely, even if the decision was made on the fly, and the information was only held ephemerally.
First and third paragraphs added per ACTION-251. Needs edits for fluency.
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 this standard if the user has given explicit and informed consent. This consent may be obtained through the browser API defined in the companion [[!TRACKING-DNT]] document, or an operator of a website may also obtain "out-of-band" consent to disregard a "Do Not Track" preference using a different technology. If an operator is relying on "out of band" consent to disregard a "Do Not Track" instruction, the operator must indicate this consent to the user agent as described in the companion [[!TRACKING-DNT]] document.
This protocol does not define what constitutes explicit consent in any jurisdiction; check with your lawyer.
Figure out which parts of UGE belong in which document.
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out signals at the same time, it'll be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.
As a general principle, more specific settings override less specific settings.
this section is the topic of active debate.
Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly formed even if the third party does not believe that the DNT:1 header was set with the explicit and informed consent of the user.
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 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. 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 companion [[!TRACKING-DNT]] document.
No provision on Disregarding Non-Compliant User Agents.
Final wording awaits how the response is designed in the TRACKING-DNT recommendation, but we agree upon the general direction below.
In order to be in compliance with this specification, a third party must make a public commitment that it complies with this standard. A "public commitment" may consist of a statement in a privacy policy, a response header, a machine-readable tracking status resource at a well-known location, or any other reasonable means. This standard does not require a specific form of public commitment.
Tracking Status Qualifiers may include a value to indicate auditing.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando (Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), David Wainberg (Network Advertising Initiative), Rigo Wenning (W3C), and Shane Wiley (Yahoo!).
The DNT header field is based on the original Do Not Track submission by Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.