Copyright © 2011-2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of 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/.
This document is 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 did not make it into this draft. Text in white is typically [CLOSED]: we have reached a consensus decision. Text in blue boxes presents multiple options the group is considering. In some cases we are close to agreement, and in others we have more to discuss. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document. This draft, published 13 March 2012, is substantially different from and more complete than the First Public Working Draft.
We have not yet reviewed comments from the Community Group associated with this work. We thank them for their time and detailed feedback, and will address their comments in the near future.
This document was published by the Tracking Protection Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-tracking@w3.org (subscribe, archives). All feedback is welcome.
Publication as a Working Draft does not imply endorsement by the W3C 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 document as other than work in progress.
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 made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
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 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 exception.
ISSUE-117:
Terms: tracking v. cross-site tracking
The WG has not come to
consensus regarding the definition of tracking and whether the scope of
DNT includes all forms of user-identifying data collection or just
cross-site data collection/use. This issue will be resolved in the TCS
document, though its resolution is a necessary prerequisite to
understanding and correctly implementing the protocol defined by this
document.
This section consists of proposed text that is meant to address ISSUE-6 and is in active discussion. Currently, it satisfies no one. We will revisit and finalize once the document is more complete.
ISSUE-6: What are the underlying concerns? Why are we doing this?
While there are a variety of business models to monetize content on the 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 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.
The Definitions section of this document is in a high state of flux as of this draft and contains a large number of controversial text proposals and open issues for the working group. None of these definitions should be considered definitive or final.
The term exemption is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference. The term exception is used when the user has permitted tracking, usually in the form of a site-specific exception, for a given third-party. In general: exemptions are additional permissions granted by the standard; exceptions are additional permissions granted by the user. These words are often confused when drafting new text.
ISSUE-97 : A special rule for URL-shortening services remains an open issue and is not addressed in the proposal put forward in 3.2 through 3.4.
ISSUE-26 : Providing data to 3rd-party widgets &emdash; does that imply consent?
The proposal put forward here does not provided a special rule for widgets. The same first party vs. third party test for static content applies.
A "party" is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person, that an ordinary user would perceive to be a discrete entity for purposes of information collection and sharing. Domain names, branding, and corporate ownership may contribute to, but are not necessarily determinative of, user perceptions of whether two parties are distinct.
Our definition of what constitutes a "party" is guided by ordinary user expectations. We decline to adopt a conflicting approach that would draw a line at domain names, corporate affiliation, or branding, as discussed below.
In an uncomplicated world, a party might be delineated by domain boundaries. In practice, however, the domain approach can emphasize differences that would not matter to ordinary users and would be restrictive for many business uses. Suppose Example Company hosts dynamic content on example.com and static images on example-static.com. An average user would understand both domains are operated by Example Company, but a domain name distinction would say the two domains are different parties. Using domain names to differentiate parties would also impose an unnecessary choice on large websites of either hosting all their content on a single domain or having some of their content considered third party. By adopting a user expectations standard, we allow a single website to span multiple domains.
A domain name approach can also gloss over relevant differences from a user expectations perspective. Suppose Example Company hires an analytics company and aliases the domain analytics.example.com to the analytics company's website. By user expectations, and corporate affiliation and branding, the analytics company would be a separate party. Moreover, circumventing the limits imposed by this standard would require nothing more than switching domain names. The user expectations standard we adopt recognizes that multiple parties may exist at a single domain.
Corporate families can consist of businesses in completely unrelated industries; users may have limited understanding of how businesses are related by corporate ownership or control. Moreover, by creating affiliates for the purposes of data sharing, organizations could circumvent the limits imposed by this standard. Under the user expectations standards we adopt, a corporate affiliate is not, in general, the same party as an organization.
In many cases, branding aligns with ordinary user expectations. Unrelated websites rarely share branding. In company ownership scenarios, prominent language like "Brand A, provided by Company B" may be sufficient for the average user to understand that Brand A is owned by Company B and information shared with Brand A may also be shared with Company B.
But, in some cases, branding does not align with user expectations. Suppose Example Search owns a video sharing website, Example Video. Most users are aware that Example Video is a subsidiary of Example Search, and that the Example Video website differs from the Example Search website for historical reasons. The Example Video home page does not, however, include any branding reference to Example Search. Under a branding test, Example Search and Example Branding would be different parties. The user expectations test allows for factors, other than branding, that influence user understanding.
Branding may also fall short in informing user expectations. If most users have never heard of Company B, language like "Brand A, provided by Company B" may not be adequate for the average user to understand the relationship between Brand A and Company B. A user expectations test recognizes there may be instances where even conspicuous branding is inadequate to inform users.
A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person. For unique corporate entities to qualify as a common party with respect to this standard, those entities must be commonly owned and commonly controlled, and must make their parent affiliation (if any) easy discoverable to users.
This may be accomplished in many ways, including but not limited to, prominent and common branding on site pages, "one click away" within Privacy Policies, and, if available, a programmatic list of domains that share common ownership (affiliation).
A "first party" is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party.
A "third party" is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it.
Some participants are concerned this proposal is not implementable as-is.
We draw a distinction between those parties an ordinary user would or would not expect to share information with, "first parties" and "third parties" respectively. The delineation exists for three reasons.
First, when a user expects to share information with a party, she can often exercise control over the information flow. Take, for example, Example Social, a popular social network. The user may decide she does not like Example Social's privacy or security practices, so she does not visit examplesocial.com. But if Example Social provides a social sharing widget embedded in another website, the user may be unaware she is giving information to Example Social and unable to exercise control over the information flow.
Second, we recognize that market pressures are an important factor in encouraging good privacy and security practices. If users do not expect that they will share information with an organization, it is unlikely to experience market pressure from users to protect the security and privacy of their information. In practice, moreover, third parties may not experience sufficient market pressure from first parties since increasingly third parties do not have a direct business relationship with the first party websites they appear on. We therefore require a greater degree of user control over information sharing with such organizations.
Last, third parties are often in a position to collect a sizable proportion of a user's browsing history – information that can be uniquely sensitive and easily associated with a user's identity. We wish to provide user control over such information flows.
We recognize that, unlike with a bright-line rule, there can be close calls in applying our standard for what constitutes a first party or a third party. But we believe that in practice, such close calls will be rare. The overwhelming majority of content on the web can be classified as first party or third party, with few cases of ambiguity in practice.
We require a confidence at a "high probability" before a party can consider itself a first party. Where there is reasonable ambiguity about whether a user has intentionally interacted with a party, it must consider itself a third party. Our rationale is that, in the rare close cases, a website is in the best position to understand its users' expectations. We therefore impose the burden of understanding user expectations on the website. We also wish, in close cases, to err on the side of conforming to user expectations and protecting user privacy. If the standard is insufficiently protective, ordinary users have limited recourse; if the standard imposes excessive limits, websites retain the safety valve of explicitly asking for user permission.
While this is not closed the idea there may be multiple first parties on one webpage based on meaningful interaction has little controversy, with some discussion around the margins about details of co-run sites.
There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.
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.
Little controversy, with some discussion of adding examples of co-run sites unresolved by publication. Some think branding covers this case; others want to add an additional example: A user visits a contest website hosted by two parties (clearly branded): Company X and Company Y. The page includes links to both parties legal information (Privacy Policy, Terms of Service) with explanation that both parties are first parties on this website.
Example: Example Weather offers an unbranded weather widget that is embedded into websites, including Example News. The widget contains small links to Example Weather's website and privacy policy. A user visits Example News and scrolls through the weekly forecast in the Example Weather widget.
Discussion: Example Weather is a third party. The user has interacted with Example Weather's widget, but an ordinary user would not expect that scrolling through the widget involves communicating with Example News.
Example: Example Social, a popular social network, hosts a social sharing button that other websites can embed. The button is colored and styled in the same fashion as Example Social's website, contains descriptive text that is specific to Example Social, includes Example Social's logo, and very frequently appears on Example Social's website. Example News embeds the Example Social button, and a user clicks it.
Discussion: Example Social is a first party once the user clicks its embedded social sharing button. The average user would understand that by clicking the button she is communicating with Example Social.
This language merely rehashes the discoverable affiliate definition of "party" and does not provide guidance as to when a party is operating on a first-party or third-party basis. This language would be better incorporated as non-normative discussion under the Option 2: Discoverable Affiliates definition of party above.
A First Party is the entity that owns the Web site or has Control over the Web site the consumer visits. A First Party also includes the owner of a widget, search box or similar service with which a consumer interacts, even if such First Party does not own or have Control over the Web site where the widget or services are displayed to the consumer.
A First Party includes Affiliates of that First Party, but only to the extent that the Affiliate is (1) an entity that Controls, is Controlled by, or us under common Control with, the First Party; or (2) an entity where the relationship to the First Party is clear to consumers through co-branding or similar means.
A First Party must make reasonable efforts to disclose, in a manner easily discoverable by Users, its ownership or Control of a site or service, such as through branding on the site or service, disclosures in the privacy policy, or terms of use linked to that site or service.
Control of an entity means that one entity (1) is under significant common ownership or operational control of the other entity, or (2) has the power to exercise a controlling influence over the management or policies of the other entity. In addition, for an entity to be under the Control of another entity and be treated as a First Party under this standard, the entity must also adhere to DNT standard in this specification.
ISSUE-14 : How does what we talk about with 1st/3rd party relate to European law about data collector vs data processor? [PENDING REVIEW]
The text that follows may move elsewhere or may ultimately be removed from the document.
For the EU, the outsourcing scenario is clearly regulated. In the current EU Directive 95/46/EC, but also in the suggested regulation reforming the data protection regime, an entity using or processing data is subject to data protection law. A First Party (EU: data controller) is an entity or multiple entities (EU: joint data controller) who determines the purposes, conditions and means of the data processing will be the data controller. A service provider (EU: data processor) is an entity with a legal contractual relation to the Data Controller. The Service Provider does determine the purposes, conditions and means of the data processing, but processes data on behalf of the controller. The data processor acts on behalf of the data controller and is a separate legal entity. An entity acting as a first party and contracting services of another party is responsible for the overall processing. A third party is an entity with no contractual relation to the Data Controller and no specific legitimacy or authorization in processing personal data. If the third party has own rights and privileges concerning the processing of the data collected by the first party, it isn't a data processor anymore and thus not covered by exemptions. This third party is then considered as a second data controller with all duties attached to that status. As the pretensions of users are based on law, they apply to first and third party alike unless the third party acts as a mere data processor.
A "network interaction" is an HTTP request and response, or any other sequence of logically related network traffic.
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.
Transactional data is information about the user's interactions with various websites, services, or widgets which could be used to create a record of a user’s system information, online communications, transactions and other activities, including websites visited, pages and ads viewed, purchases made, etc.
The following text consists of proposed text that is meant to address ISSUE-16. This language is currently being actively debated.
ISSUE-16 : What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.)
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.
We are still working through how, or if, to define tracking. Some suggest the phrase "cross-site tracking" only. We will need to ensure both final recommendations use the same terms in the same way.
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.
ISSUE-69 : Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)
"Affirmative, Informed Consent to be Tracked" means consent given by an affirmative action such as clicking a consent box in response to a clear and prominent request to ignore a "Do Not Track" setting that is distinct and separate from any other notifications or requested permissions.
"Affirmative, Informed Consent to be Tracked" has been obtained when a mechanism to provide for or facilitate the acquisition and storage of permission to ignore the header has been made available to the user and the user has meaningfully interacted with the mechanism in a way that makes clear her intent to grant this permission.
The hope is that this option will ensure consistency with EU regulations; it may not unless notice is included.
No definition, other than explicitly leaving the definition of consent to local rules.
Wording needs polish to ensure it works with accessibility issues, but other than minor edits this is agreed upon.
"Meaningful Interaction" with a widget or window initially presented on a third-party basis means clicking on such content (except to stop, close, silence, or otherwise impair the rendering of such content) or otherwise affirmatively engaging with the content in a manner that would reasonably be interpreted to express an affirmative intention to interact with that party. A user merely moving her cursor across the widget or window does not constitute "meaningful interaction."
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].
This section consists of proposed text that is meant to address ISSUE-17: Data use by 1st Party, ISSUE-30: Will Do Not Track apply to offline aggregating or selling of data?, ISSUE-54: Can first party provide targeting based on registration information even while sending DNT, ISSUE-59: Should the first party be informed about whether the user has sent a DNT header to third parties on their site?, and ISSUE-91: Might want prohibitions on first parties re-selling data to get around the intent of DNT, and are pending discussion and [PENDING REVIEW].
Additional text has been prepared for each of these five options. This text will be added once an option has been decided upon.
The following are distinct options that have been proposed by members of the group:This issue is being addressed in the [TRACKING-DNT] specification.
This section consists of proposed text that is meant to address ISSUE-19 and ISSUE-39 and is pending discussion and [PENDING REVIEW].
If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached:
The following consists of proposed text that is meant to address ISSUE-71 and is pending discussion and [PENDING REVIEW].
ISSUE-71 : Does DNT also affect past collection or use of past collection of info?
Examples and use cases
This section may move into, or have implications for, the section 3 definitions.
If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached:
It is acceptable to use data sent as part of this particular network interaction when composing a response to a [DNT-ON] request, but it is not acceptable to store that data any longer than needed to reply. For instance, it would be appropriate to use an IP address to guess which country a user is in, to avoid showing them an advertisement for products or services unavailable where they live.
When using request-specific information to compose a reply, some levels of detail may feel invasive to users, and may violate their expectations about Do Not Track. These sorts of detailed assessments should be avoided.
In this example, even though the decision about which ad to serve was based exclusively on request specific information, but was still tailored to a highly-specific user profile. In particular, the estimation of a user's location to within a single ZIP+4 may make a user feel that they are being followed closely, even if the decision was made on the fly, and the information was only held ephemerally.
ISSUE-19 : Data collection / Data use (3rd party)
ISSUE-88 : different rules for impression of and interaction with 3rd-party ads/content
This section outlines potential exemptions to the standard based on necessary business use. For all of these exemptions, the complying entity must make reasonable data minimization efforts to ensure that only the data necessary for the exempted purpose be retained.
The following text consists of proposed text that is meant to address ISSUE-23 , ISSUE-24 , ISSUE-25 , ISSUE-31 , ISSUE-34 , and ISSUE-49 and is pending discussion and [PENDING REVIEW].
Should we explicitly identify goals and use cases in order to evaluate these exemptions?
This section consists of proposed text that is meant to address ISSUE-22 and is pending discussion and [PENDING REVIEW]. We have active discussions in this area.
ISSUE-22 : Still have "operational use" of data (auditing of where ads are shown, impression tracking, etc.)
In order to preserve certain common and important data usages, while still protecting consumer privacy concerns, it will be necessary to provide operational purpose exemptions for necessary business activities when the DNT signal is on. There are several key categories of data collection and use that must remain intact such that web site operators who are (in the vast majority) offering their services free of charge in exchange for advertising on their properties. Proposed exemptions include:
Discussion is ongoing as to how to define these exemptions and whether or not all should be included in an exemptions list.
This section consists of proposed text that is meant to address ISSUE-23 , ISSUE-72 , ISSUE-73 and ISSUE-49 and are pending discussion and [PENDING REVIEW].
This section may be moved to the section titled "First Parties and Third Parties"
ISSUE-49 : Third party as first party - is a third party that collects data on behalf of the first party treated the same way as the first party?
The rationale for rule (2) is that we allow the third party to stand in the first party’s shoes – but go no further. The third party may not use the data it collects for "product improvement," "aggregate analytics," or any other purpose except to fulfill a request by a first party, where the results are shared only with the first party.
Rule (3) allows for the possibility of more than one level of outsourcing.
In rule (4), one component of reasonable technical precautions will often be using the same-origin policy to segregate information for each first-party customer.
Note that any data collected by the third party that is used, or may be used, in any way by any party other than the first party, is subject to the requirements for third parties.
ExampleAnalytics collects analytic data for ExampleProducts Inc.. It operates a site under the DNS analytics.exampleproducts.com. It collects and analyzes data on visits to ExampleProducts, and provides that data solely to ExampleProducts, and does not access or use it itself.
This section consists of proposed text that is meant to address ISSUE-34 and is pending discussion and [PENDING REVIEW].
ISSUE-34 : Possible Exemption for aggregate analytics
A third party may collect, retain, and use any information from a user or user agent that, with high probability, could not be used to:
Clarification is needed with regard to what is meant by the following text
This exemption (like all exemptions) may not be combined with other exemptions unless specifically allowed. A third party acting within the outsourcing exemption, for example, may not make independent use of the data it has collected even though the use involves unidentifiable data.
A rule to the contrary would provide a perverse incentive for third parties to press all exemptions to the limit and then use the collected data within this exemption.
A potential 'safe harbor' under this clause could be to retain only aggregate counts, not per-transaction records.
ISSUE-24 : Possible exemption for fraud detection and defense
ISSUE-25 : Possible exemption for research purposes
The following consists of proposed text that is meant to address ISSUE-28 and is pending discussion and [PENDING REVIEW].
ISSUE-28 : Exemption for mandatory legal process
This specification is not intended to override applicable laws and regulations.
Indeed, a party may take action contrary to the requirements of this standard if compelled by applicable law. If compelled by applicable law to collect, retain, or transmit data despite receiving a DNT:1 signal for which there is no exemption, the party should notify affected users to the extent practical and allowed by law.
It should be noted that this allowance does not extend to the fulfillment of a contractual obligation.
ISSUE-75 : How do companies claim exemptions and is that technical or not?
ISSUE-31 : Minimization &emdash; to what extent will minimization be required for use of a particular exemption? (conditional exemptions)
ISSUE-92 : If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking?
ISSUE-89 : Does DNT mean at a high level: (a) no customization, users are seen for the first time, every time. (b) DNT is about data moving between sites.
ISSUE-97: Re-direction, shortened URLs, click analytics &emdash; what kind of tracking is this?
ISSUE-66 : Can user be allowed to consent to both third party and first party to override general DNT?
ISSUE-93 : Should 1st parties be able to degrade a user experience or charge money for content based on DNT?
For the purposes of this document, an exception is a user-granted override of their default DNT status for one or more third parties within a given first party context.
It is possible for first parties to request, and users to set, exceptions to their default DNT status on a per-first party basis for the third parties that the first party works with. The goal of this is to allow first parties to communicate with their users about their options with respect to DNT within the context of that first party's web pages.
Should Market Research be deemed an exception rather than an exemption?
The following consists of proposed text and is pending discussion and [PENDING REVIEW].
When a DNT enabled user agent grants a site-specific exception, the site places a site-specific opt-in mechanism on the user agent allowing the site to respond as a First Party. The DNT header must remain enabled so that if the user returns to the site, both the user's general preference for DNT and the site-specific exception will be clear. When seeking a site-specific exception from the user, the site must describe to the user, via a direct link from the exception page, all purposes for which the tracking will be used.
As multiple systems may be setting, sending, and receiving DNT and/or Opt-Out signals at the same time, it’ll be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.
As a general principle, more specific settings override less specific settings.
NOTE: The above text will need to be modified to include the appropriate terminology as this is decided upon by the working group. For example, DNT Exception would need to be replaced with "Site-Specific Exception" depending on the outcome of that discussion.
ISSUE-83 : How do you opt out if already opted in?
ISSUE-67 : Should opt-back-in be stored on the client side? [Not sure this doesn't belong in the technical spec]
ISSUE-65 : How does logged in and logged out state work
If a user is logged into a first-party website and it receives a DNT:1 signal, the website must respect DNT:1 signal as a first party and should handle the user login as it normally would. If a user is logged into a third-party website, and the third party receives a DNT:1 signal, then it must respect the DNT:1 signal unless it falls under an exemption described in this document.
Example use cases:
No text on this topic at all, and let the existing rules work it out.
Final wording awaits how the response is designed in the [TRACKING-DNT] recommendation, but we agree upon the general direction below.
In order to be in compliance with this specification, a party must make a public commitment that it complies with this standard.
A "public commitment" may consist of a statement in a privacy policy, a response header, a machine-readable tracking status resource at a well-known location, or any other reasonable means. This standard does not require a specific form of "public commitment."
ISSUE-21 : Enable external audit of DNT compliance
We have reviewed one audit proposal that we declined to adopt. We may include a smaller-scoped proposal in the future, or may drop auditing all together.
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), 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.