W3C

Tracking Compliance and Scope

W3C Working Draft

This version:
http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/
Latest published version:
http://www.w3.org/TR/tracking-compliance/
Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
Previous version:
http://www.w3.org/TR/2012/WD-tracking-compliance-20121002/
Editors:
Justin Brookman, CDT
Heather West, Google
Sean Harvey, Google (until June 2012)
Erica Newland, CDT (until May 2012)

Abstract

This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.

Status of This Document

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 ongoing discussions within the Tracking Protection Working Group. Text present or not present in this document does not determine consensus within the Working Group; discussions and debates are ongoing. Text in option boxes (highlighted with light blue background color) present options that the group is currently considering, particularly where consensus is known to be lacking, and should be read as a set of proposals rather than as limitations on the potential outcome. Members of the Working Group wish to emphasize that this draft is a work in progress and not a decided outcome or guaranteed direction for future versions of 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 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 comments are 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.

Table of Contents

1. Introduction

Note

The introduction will be re-worked after details of substantive text is closer to being finalized.

2. Scope and Goals

This specification is designed to provide users a simple machine-readable preference expression mechanism to globally or selectively allow or limit online tracking.

"Tracking" is understood by this standard as the collection and retention of data across multiple parties' domains or services in a form such that it can be attributed to a specific user, user agent, or device.

Note

The scope language is not at consensus, but is an effort by the editors to offer a provisional definition of tracking.

3. Definitions

3.1 User

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.

3.2 User Agent

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].

3.3 Party

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 and MUST provide easy discoverability of affiliate organizations. An list of affiliates MUST be provided within one click from each page or the entity owner clearly identified within one click from each page.

3.4 Service Providers

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.

Outsourced service providers are considered to be the same party as their clients if the service provider

1. acts only as a data processor on behalf of the client;

2. ensures that the data can only be accessed and used as directed by that client;

3. has not independent right to use or share the data except as necessary to ensure the integrity, security, and correct operation of the service being provided; and

4. has a contract in place that outlines and mandates these requirements.

Issue 49: Third party as first party -- is a third party that collects data on behalf of a first party treated the same way as the first party

3.5 First Party

In a specific network interaction, a party with which the user intentionally interacts is a first party. In most cases on a traditional web browser, the first party will be the party that owns and operates the domain visible in the address bar. The party that owns and operates or has control over a branded/labelled embedded widget, search box, or similar service with which a user intentionally interacts is also considered a 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.

3.5.1 Multiple First Parties

In most network interactions, there will be only one first party with which the user intends to interact. However, in some cases, a network resource will be jointly operated by two or more parties, and a user would reasonably expect to communicate with all of them by accessing that resource. User understanding that multiple parties operate a particular resource could be accomplished through inclusion of multiple parties' brands in a domain name, or prominent branding on the resource indicating that multiple parties are responsible for content or functionality on the resource with which a user reasonably would expect to interact by accessing the resource. Simple branding of a party, without more, will not be sufficient to make that party a first party in any particular network interaction.

Issue 10: What is a first party?

3.6 Third Party

In a specific network interaction, any entity that is not the user, user agent, or a first party is considered a third party.

3.7 Deidentified Data

Data is deidentified when a party:
(1) has taken measures to ensure with a reasonable level of justified confidence that the data cannot be used to infer information about, or 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.

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

The first option above is based on the definition of unlinkable data in the 2012 FTC privacy report; the second option was proposed by Daniel Kaufman. The group has a fundamental disagreement about whether internal access controls within an organization could be sufficient to de-identify data for the purposes of this standard.

Issue 188: Definition of unlinkable data

Issue 191: Non-normative Discussion of De-Identification

3.8 Network Transaction

A network interaction is an HTTP request and response, or any other sequence of logically related network traffic.

3.9 Data collection, retention, use, and sharing

Issue 16: What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.)

  1. A party collects data if it receives the data and either shares the 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.
  3. A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.
  4. A party shares data if the party provides a copy or access to the data to a third party.

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.

3.9.1 Exception for unknowing collection, retention, and use

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.

3.10 Tracking

Note

The term "tracking" is not used in the normative text of this document. We may subsequently decide to define this term, or address the issue of what 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

4. First Party Compliance

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 standard.

4.1 Additional/Alternative First Party Compliance Requirements

When DNT:1 is received,

  1. A first party MUST NOT combine or otherwise use identifiable data received from another party with data it collected while a first party;
  2. A first party MUST NOT share identifiable data with another party 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.

4.1.1 Explanation

This section is non-normative.

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

This language is not consensus. The parties are generally agreed that this language should 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, 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 170: Definition of and what/whether limitations around data append

5. User Agent Compliance

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.

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:

1. The User Agent 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, 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;

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;

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.

Non-Normative:

The User Agent plays a key role in enacting the DNT functionality. As a result, it is appropriate for the User Agent to play an equally key role in describing DNT functionality and educating users about DNT in order for this standard to be meaningful.

While the user interface guidelines do not specify the exact presentation to the user, they are intended to help ensure that users understand their 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.

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.

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.

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.

Issue 150: DNT conflicts from multiple user agents

Issue 153: What are the implications on software that changes requests but does not necessarily initiate them?

6. Third Party Compliance

If a third party receives a communication to which a DNT:1 header is attached:

  1. that third party MUST NOT collect, retain, share, or use information related to that communication outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;
  2. that third party MUST NOT share or use information about previous communications in which it was a third party, outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;

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

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.

6.2.1 Global Requirements for Permitted Uses

In order to use the permitted uses outlined below, a party MUST comply with these four requirements.

6.2.1.1 No Secondary Uses

Third Parties MUST NOT use data retained for a permitted use for non-permitted uses.

6.2.1.2 Data Minimization and Transparency

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. A third party MUST make reasonable data minimization efforts to ensure that only data necessary for each permitted use is retained. A third party MUST provide public transparency of their data retention period for each permitted use. Once a retention period for a given use has expired, the data MUST NOT be used for that permitted use; when there are no remaining permitted uses for some data, that data MUST either be deleted or rendered unlinkable.

Additional proposed language:

Where feasible, a third party SHOULD NOT collect linkable data when that data is not reasonably necessary for one of the permitted uses. In 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.2.1.3 Reasonable Security

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.

6.2.1.4 No Personalization

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].

6.2.1.5 No Persistent Identifiers

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).

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

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.

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 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).

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.2.2.3 Content or Ad Delivery Based on First Party Data

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.

Note

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).

This text may 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. Shane Wiley has proposed defining "declared data" as Information directly and expressly supplied by a user to a party through meaningful interaction with that party.

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.

Issue 54: can first parties use declared data while in a 3rd party context?

6.2.2.4 Frequency Capping

Information may be collected, retained and used for limiting the number of times that a user sees a particular advertisement, often called "frequency capping."

Operators MAY retain data related to a communication in a third-party context to use for limiting how often advertisements are shown to a particular user if the data retained do not include the user's browsing history (for example, page URIs on which ads were past delivered). For this permitted use, operators MUST NOT construct profiles of users or user behavior based on their ad frequency history or otherwise alter the user's experience based on this data.

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

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 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.

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

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.

  1. No DNT Signal / No Opt-Out: Treat as DNT unset
  2. DNT Signal / No Opt-Out: 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; DNT User-Granted Exception is honored

6.4 Exception for Deidentified Data

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.

6.5 Disregarding Non-Compliant User Agents

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.

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 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.

Issue 161: Do we need a tracking status value for partial compliance or rejecting DNT?

On the [TRACKING-DNT] document, we have this pending-review issue regarding communicating disregarding a user/agent.

6.6 Public Disclosure of Compliance

Note

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.

A. Acknowledgements

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.

B. References

B.1 Normative references

[HTTP11]
R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
[TRACKING-DNT]
Roy T. Fielding; David Singer. Tracking Preference Expression (DNT). 02 October 2012. W3C Working Draft. URL: http://www.w3.org/TR/tracking-dnt/