Showing content from http://lists.w3.org/Archives/Public/public-tracking/2012Jul/att-0109/tpe_diff.html below:
Diff: b.txt - c.txt
b.txt c.txt ***** ***** W3C W3C Tracking Preference Expression (DNT) Tracking Preference Expression (DNT) W3C Working Draft 13 March 2012 W3C Editor's Draft 18 July 2012 This version: This version: http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html Latest published version: Latest published version: http://www.w3.org/TR/tracking-dnt/ http://www.w3.org/TR/tracking-dnt/ Latest editor's draft: Latest editor's draft: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html Previous version: Previous version: http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/ http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/ Editors: Editors: Roy T. Fielding, Adobe Roy T. Fielding, Adobe David Singer, Apple David Singer, Apple Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. W3C liability, trademark and document use rules apply. ---------------------------------------------------------------------- ---------------------------------------------------------------------- skipping to change at line 57 skipping to change at line 57 can be found in the W3C technical reports index at http://www.w3.org/TR/. can be found in the W3C technical reports index at http://www.w3.org/TR/. This document is a snapshot of live discussions within the Tracking This document is a snapshot of live discussions within the Tracking Protection Working Group. It does not yet capture all of our work. For Protection Working Group. It does not yet capture all of our work. For example, we have issues that are [PENDING REVIEW] with complete text example, we have issues that are [PENDING REVIEW] with complete text proposals that did not make it into this draft. Text in white is typically proposals that did not make it into this draft. Text in white is typically [CLOSED]: we have reached a consensus decision. Text in blue boxes [CLOSED]: we have reached a consensus decision. Text in blue boxes presents multiple options the group is considering. In some cases we are 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 close to agreement, and in others we have more to discuss. An issue tracking system is available for recording raised, open, pending review, tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document. This draft, closed, and postponed issues regarding this document. 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 This document was published by the Tracking Protection Working Group as an Working Draft. This document is intended to become a W3C Recommendation. Editor's Draft. If you wish to make comments regarding this document, If you wish to make comments regarding this document, please send them to please send them to public-tracking@w3.org (subscribe, archives). All public-tracking@w3.org (subscribe, archives). All feedback is welcome. feedback is welcome. Publication as a Working Draft does not imply endorsement by the W3C Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. document as other than work in progress. This document was produced by a group operating under the 5 February 2004 This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with Essential Claim(s) must disclose the information in accordance with skipping to change at line 101 skipping to change at line 95 * 4. Expressing a Tracking Preference * 4. Expressing a Tracking Preference * 4.1 Expression Format * 4.1 Expression Format * 4.2 DNT Header Field for HTTP Requests * 4.2 DNT Header Field for HTTP Requests * 4.3 JavaScript API to Detect Preference * 4.3 JavaScript API to Detect Preference * 4.3.1 Interface * 4.3.1 Interface * 4.3.2 Attributes * 4.3.2 Attributes * 4.3.3 Implements * 4.3.3 Implements * 4.4 Plug-In APIs * 4.4 Plug-In APIs * 4.5 Tracking Preference Expressed in Other Protocols * 4.5 Tracking Preference Expressed in Other Protocols * 5. Communicating a Tracking Status * 5. Communicating a Tracking Status * 5.1 Tracking Status Resource * 5.1 Overview * 5.1.1 Resource Definition * 5.2 Tracking Status Value * 5.1.2 Tracking Status Representation * 5.3 Tracking Status Resource * 5.1.3 Using the Tracking Status * 5.3.1 Definition * 5.1.4 Tracking Status Caching * 5.3.2 Representation * 5.1.5 Tracking Status ABNF * 5.3.3 Qualifier Value * 5.2 Tk Header Field for HTTP Responses * 5.3.4 Using the Tracking Status * 5.2.1 Motivation * 5.3.5 Caching * 5.2.2 Tk ABNF * 5.3.6 Status-object ABNF * 5.2.3 Tk Semantics * 5.4 Tk Header Field for HTTP Responses * 5.2.4 More Information * 5.4.1 Definition * 5.2.5 Implementation and Usage Considerations * 5.4.2 Indicating Tracking Design * 5.2.6 Examples * 5.4.3 Indicating an Interactive Status Change * 5.3 Status Code for Tracking Required * 5.4.4 Indicating a Specific Tracking Status Resource * 6. Site-specific Exceptions * 5.5 Status Code for Tracking Required * 6. User-Granted Exceptions * 6.1 Overview * 6.1 Overview * 6.2 Motivating principles and use cases * 6.2 Motivating principles and use cases * 6.3 Exception model * 6.3 Exception model * 6.3.1 Site pairs * 6.3.1 Introduction * 6.3.2 Exception use by browsers * 6.3.2 Exception use by browsers * 6.4 JavaScript API for site-specific exceptions * 6.4 JavaScript API for site-specific exceptions * 6.4.1 Methods * 6.4.1 API to request site-specific exceptions * 6.4.2 Methods * 6.4.1.1 Methods * 6.5 User interface guidelines * 6.4.1.2 Methods * 6.6 Exceptions without a DNT header * 6.4.2 API to cancel a site-specific exception * 6.7 Web-wide exceptions * 6.4.2.1 Methods * 6.5 JavaScript API for web-wide exceptions * 6.5.1 API to request a web-wide exception * 6.5.1.1 Methods * 6.5.2 API to cancel a web-wide exception * 6.5.2.1 Methods * 6.6 User interface guidelines * 6.7 Exceptions without a DNT header * 6.8 Fingerprinting * 6.8 Fingerprinting * A. Acknowledgements * A. Acknowledgements * B. References * B. References * B.1 Normative references * B.1 Normative references * B.2 Informative references * B.2 Informative references 1. Introduction 1. Introduction The World Wide Web (WWW, or Web) consists of millions of sites The World Wide Web (WWW, or Web) consists of millions of sites interconnected through the use of hypertext. Hypertext provides a simple, interconnected through the use of hypertext. Hypertext provides a simple, skipping to change at line 190 skipping to change at line 192 content without such targeted advertising or data collection need a content without such targeted advertising or data collection need a mechanism to indicate those requirements to the user and allow them (or mechanism to indicate those requirements to the user and allow them (or their user agent) to make an individual choice regarding exceptions. their user agent) to make an individual choice regarding exceptions. This specification defines the HTTP request header field DNT for This specification defines the HTTP request header field DNT for expressing a tracking preference on the Web, a well-known location (URI) expressing a tracking preference on the Web, a well-known location (URI) for providing a machine-readable tracking status resource that describes a for providing a machine-readable tracking status resource that describes a service's DNT compliance, the HTTP response header field Tk for resources service's DNT compliance, the HTTP response header field Tk for resources to communicate their compliance or non-compliance with the user's to communicate their compliance or non-compliance with the user's expressed preference, and JavaScript APIs for determining DNT status and expressed preference, and JavaScript APIs for determining DNT status and requesting a site-specific exception. requesting a user-granted exception. A companion document, [TRACKING-COMPLIANCE], more precisely defines the A companion document, [TRACKING-COMPLIANCE], more precisely defines the terminology of tracking preferences, the scope of its applicability, and terminology of tracking preferences, the scope of its applicability, and the requirements on compliant first-party and third-party participants the requirements on compliant first-party and third-party participants when an indication of tracking preference is received. when an indication of tracking preference is received. ISSUE-117: Terms: tracking v. cross-site tracking ISSUE-136: Resolve dependencies of the TPE on the compliance specification. The WG has not come to consensus regarding the definition of tracking and 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 the scope of DNT. As such, a site cannot actually say with any confidence collection or just cross-site data collection/use. This issue will be whether or not it is tracking, let alone describe the finer details in a resolved in the TCS document, though its resolution is a necessary tracking status resource. This issue will be resolved by progress on the prerequisite to understanding and correctly implementing the protocol TCS document, though its resolution is a necessary prerequisite to defined by this document. understanding and correctly implementing the protocol defined by this document. 2. Notational Conventions 2. Notational Conventions 2.1 Requirements 2.1 Requirements The key words must, must not, required, should, should not, recommended, The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described may, and optional in this specification are to be interpreted as described in [RFC2119]. in [RFC2119]. 2.2 Formal Syntax 2.2 Formal Syntax skipping to change at line 225 skipping to change at line 229 This specification uses Augmented Backus-Naur Form [ABNF] to define This specification uses Augmented Backus-Naur Form [ABNF] to define network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs. 2.3 Terminology 2.3 Terminology This specification uses the term user agent to refer to any of the various This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including, but not client programs capable of initiating HTTP requests, including, but not limited to, browsers, spiders (web-based robots), command-line tools, limited to, browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11]. native applications, and mobile apps [HTTP11]. The term permitted use is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference. The term user-granted 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: permitted uses are additional permissions granted by the standard; user-granted exceptions are additional permissions granted by the user. These words are often confused when drafting new text. 3. Determining User Preference 3. Determining User Preference The goal of this protocol is to allow a user to express their personal The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties. agreement with the user to satisfy all parties. Key to that notion of expression is that it must reflect the user's Key to that notion of expression is that it must reflect the user's preference, not the preference of some institutional or network-imposed preference, not the choice of some vendor, institution, or network-imposed mechanism outside the user's control. Although some controlled network mechanism outside the user's control. The basic principle is that a environments, such as public access terminals or managed corporate tracking preference expression is only transmitted when it reflects a intranets, might impose restrictions on the use or configuration of deliberate choice by the user. In the absence of user choice, there is no installed user agents, such that a user might only have access to user tracking preference expressed. agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what sites can or cannot be accessed through that network. The remainder of this specification defines the protocol in terms of A user agent must offer users a minimum of two alternative choices for a whether a tracking preference is enabled or not enabled. We do not specify Do Not Track preference: unset or DNT:1. A user agent may offer a third how that preference is enabled: each implementation is responsible for alternative choice: DNT:0. determining the user experience by which this preference is enabled. If the user's choice is DNT:1 or DNT:0, the tracking preference is enabled; otherwise, the tracking preference is not enabled. A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as SuperFred, but might imply a preference if invoked as SuperDoNotTrack or UltraPrivacyFred. Likewise, a user agent extension or add-on must not alter the tracking preference unless the act of installing and enabling that extension or add-on is an explicit choice by the user for that 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 For example, a user might select a check-box in their user agent's configuration, install a plug-in or extension that is specifically configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., Privacy privacy that then implicitly includes a tracking preference (e.g., Privacy settings: high). Likewise, a user might install or configure a proxy to settings: high). The user-agent might ask the user for their preference add the expression to their own outgoing requests. For each of these during startup, perhaps on first use or after an update adds the tracking cases, we say that a tracking preference is enabled. protection feature. Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests. Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what resources can or cannot be accessed through that network. Implementations of HTTP that are not under control of the user must not generate or modify a tracking preference. 4. Expressing a Tracking Preference 4. Expressing a Tracking Preference 4.1 Expression Format 4.1 Expression Format When a user has enabled a tracking preference, that preference needs to be When a user has enabled a tracking preference, that preference needs to be expressed to all mechanisms that might perform or initiate tracking by expressed to all mechanisms that might perform or initiate tracking by third parties, including sites that the user agent communicates with via third parties, including sites that the user agent communicates with via HTTP, scripts that can extend behavior on pages, and plug-ins or HTTP, scripts that can extend behavior on pages, and plug-ins or extensions that might be installed and activated for various media types. extensions that might be installed and activated for various media types. When enabled, a tracking preference is expressed as either: When enabled, a tracking preference is expressed as either: DNT meaning DNT meaning 1 This user prefers not to be tracked on the target 1 This user prefers not to be tracked on the target site. site. 0 This user prefers to allow tracking on the target 0 This user prefers to allow tracking on the target site. site. If a tracking preference is not enabled, then no preference is expressed A user agent must not send a tracking preference expression if a tracking by this protocol. This means that no expression is sent for each of the preference is not enabled. This means that no expression is sent for each following cases: of the following cases: * the user agent does not implement this protocol; * the user has not yet made a choice for a specific preference; or, * the user has chosen not to transmit a preference. * the user agent does not implement this protocol; or * the user agent does implement the protocol, but the user does not wish to indicate a preference at this time. In the absence of regulatory, legal, or other requirements, servers may In the absence of regulatory, legal, or other requirements, servers may interpret the lack of an expressed tracking preference as they find most interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, the user's privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol. preference is expressed via this protocol. ISSUE-59: Should the first party be informed about whether the user has sent a DNT header to third parties on their site? ISSUE-111: Different DNT value to signify existence of site-specific ISSUE-111: Different DNT value to signify existence of site-specific exception (also linked to 4.1 and 6 below) exception (also linked to 4.1 and 6 below) 4.2 DNT Header Field for HTTP Requests 4.2 DNT Header Field for HTTP Requests The DNT header field is hereby defined as the means for expressing a The DNT header field is hereby defined as the means for expressing a user's tracking preference via HTTP [HTTP11]. user's tracking preference via HTTP [HTTP11]. DNT-field-name = "DNT" ; case-insensitive DNT-field-name = "DNT" ; case-insensitive DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive DNT-field-value = ( "0" / "1" ) *DNT-extension ; case-sensitive DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E ; excludes CTL, SP, DQUOTE, comma, backslash ; excludes CTL, SP, DQUOTE, comma, backslash A user agent must send the DNT header field on all HTTP requests if (and A user agent must send the DNT header field on all HTTP requests if (and only if) a tracking preference is enabled. A user agent must not send the only if) a tracking preference is enabled. A user agent must not send the DNT header field if a tracking preference is not enabled. DNT header field if a tracking preference is not enabled. The DNT field-value sent by a user agent must begin with the numeric The DNT field-value sent by a user agent must begin with the numeric character "1" (%x31) if a tracking preference is enabled, the preference character "1" (%x31) if a tracking preference is enabled, and the is for no tracking, and there is not a site-specific exception for the preference is for no tracking, and there is not a site-specific exception origin server targeted by this request. for the origin server targeted by this request. The DNT field-value sent by a user agent must begin with the numeric The DNT field-value sent by a user agent must begin with the numeric character "0" (%x30) if a tracking preference is enabled and the character "0" (%x30) if a tracking preference is enabled, and the preference is to allow tracking in general or by specific exception for preference is to allow tracking in general or by specific exception for the origin server targeted by this request. the origin server targeted by this request. GET /something/here HTTP/1.1 GET /something/here HTTP/1.1 Host: example.com Host: example.com DNT: 1 DNT: 1 An HTTP intermediary must not add, delete, or modify the DNT header field An HTTP intermediary must not add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not inject the requests. For example, an Internet Service Provider must not inject DNT: 1 on behalf of all of their users who have not selected a choice. DNT: 1 on behalf of all of their users who have not expressed a preference. The remainder of the DNT field-value after the initial character is The remainder of the DNT field-value after the initial character is reserved for future extensions. User agents that do not implement such reserved for future extensions. User agents that do not implement such extensions must not send DNT-extension characters in the DNT field-value. extensions must not send DNT-extension characters in the DNT field-value. Servers that do not implement such extensions should ignore anything Servers that do not implement such extensions should ignore anything beyond the first character. beyond the first character. DNT extensions are to be interpreted as modifiers to the main preference DNT extensions are to be interpreted as modifiers to the main preference expressed by the first digit, such that the main preference will be obeyed expressed by the first digit, such that the main preference will be obeyed if the recipient does not understand the extension. Hence, a if the recipient does not understand the extension. Hence, a DNT-field-value of "1xyz" can be thought of as do not track, but if you DNT-field-value of "1xyz" can be thought of as do not track, but if you understand the refinements defined by x, y, or z, then adjust my understand the refinements defined by x, y, or z, then adjust my preferences according to those refinements. DNT extensions can only be preferences according to those refinements. DNT extensions can only be transmitted when a tracking preference is enabled. transmitted when a tracking preference is enabled. The extension syntax is restricted to visible ASCII characters that can be The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (section 5.1.2 Tracking Status Representation). without further encoding (section 5.3.2 Representation). Since the DNT Since the DNT header field is intended to be sent on every request, when header field is intended to be sent on every request, when enabled, enabled, designers of future extensions ought to use as few extension designers of future extensions ought to use as few extension characters as characters as possible. possible. This document does not have any implied or specified behavior for the user-agent treatment of cookies when DNT is enabled. ISSUE-111: Different DNT value to signify existence of site-specific ISSUE-111: Different DNT value to signify existence of site-specific exceptions exceptions Should the user agent send a different DNT value to a first party site if Should the user agent send a different DNT value to a first party site if there exist site-specific exceptions for that first party? (e.g. DNT:2 there exist site-specific exceptions for that first party? (e.g. DNT:2 implies I have Do Not Track enabled but grant permissions to some third implies I have Do Not Track enabled but grant permissions to some third parties while browsing this domain) [OPEN] parties while browsing this domain) [OPEN] 4.3 JavaScript API to Detect Preference 4.3 JavaScript API to Detect Preference skipping to change at line 399 skipping to change at line 439 binding-specific casting methods on an instance of Navigator. binding-specific casting methods on an instance of Navigator. ISSUE-84: Make DNT status available to JavaScript ISSUE-84: Make DNT status available to JavaScript [OPEN] The API above has been deemed inadequate due to origin restrictions [OPEN] The API above has been deemed inadequate due to origin restrictions on embedded javascript by reference. We are awaiting new text to resolve on embedded javascript by reference. We are awaiting new text to resolve this issue. this issue. ISSUE-116: How can we build a JS DOM property which doesn't allow inline ISSUE-116: How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals? JS to receive mixed signals? ISSUE-125: Way to test if a given user agent supports DNT 4.4 Plug-In APIs 4.4 Plug-In APIs User agents often include user-installable component parts, commonly known User agents often include user-installable component parts, commonly known as plug-ins or browser extensions, that are capable of making their own as plug-ins or browser extensions, that are capable of making their own network requests. From the user's perspective, these components are network requests. From the user's perspective, these components are considered part of the user agent and thus ought to respect the user's considered part of the user agent and thus ought to respect the user's configuration of a tracking preference. However, plug-ins do not normally configuration of a tracking preference. However, plug-ins do not normally have read access to the browser configuration. have read access to the browser configuration. It is unclear whether we need to standardize the plug-in APIs or if we It is unclear whether we need to standardize the plug-in APIs or if we skipping to change at line 428 skipping to change at line 466 expressed here is specific to HTTP communication; however, the semantics expressed here is specific to HTTP communication; however, the semantics are not restricted to use in HTTP; the same semantics may be carried by are not restricted to use in HTTP; the same semantics may be carried by other protocols, either in future revisions of this specification, or in other protocols, either in future revisions of this specification, or in other specifications. other specifications. When it is known that the user's preference is for no tracking, compliant When it is known that the user's preference is for no tracking, compliant services are still required to honor that preference, even if other services are still required to honor that preference, even if other protocols are used. For example, re-directing to another protocol in order protocols are used. For example, re-directing to another protocol in order to avoid receipt of the header is not compliant. to avoid receipt of the header is not compliant. ISSUE-108: Should/could the tracking preference expression be extended to The last paragraph may be more appropriate in the compliance document, as other protocols beyond HTTP? it discusses compliance. [PENDING REVIEW] Text in this section; but the last paragraph may be more appropriate in the compliance document, as it discusses compliance. 5. Communicating a Tracking Status 5. Communicating a Tracking Status The next two sections detail two proposals how to communicate tracking 5.1 Overview status: * Well-known URI to allow user agent to retrieve tracking status for a The primary goals of this protocol-expressing the user's preference and site adhering to that preference-can be accomplished without any response from * HTTP Response header to communicate tracking status for a request the server. However, the protocol also seeks to improve the transparency of tracking behavior by providing a machine-readable means for discovering claims of compliance and determining the current tracking status. This is work in progress. The WG has not yet decided which of these Unfortunately, providing a dynamic indication of tracking compliance on options (or both) to choose. The WG is currently working on a resolution every HTTP response is not feasible, since it would have the effect of but nevertheless appreciates input on this open issue. We are currently disabling caching for the entire Web. Instead, this protocol defines a working on a proposal which combines the Tk response header and Tracking combination of response mechanisms that allow the information to be Status Resource. It would make the TSR compulsory and the Tk header communicated without making every response dynamic. optional. However, it would be required to use the Tk header to notify the user when something in the TSR has changed in real time. 5.1 Tracking Status Resource This section explains how a user agent may discover an origin server's tracking status for a given resource. It defines a required site-wide tracking status resource at a specific well-known location and an optional space of request-specific tracking status resources for sites where the tracking status might vary based on data within the request. It also defines a Tk response header field that may be sent in any HTTP response, must be sent in responses to requests that modify the tracking status for a user agent, and may direct the user to a request-specific tracking status resource applicable to the current request. 5.1.1 Resource Definition 5.2 Tracking Status Value A tracking status value is a short notation for communicating how a designated resource conforms to this protocol. For a site-wide tracking status resource, the designated resource is any resource on the same origin server. For a Tk response header field, the resource that sent the Tk header field in response is the designated resource, and remains the designated resource for any subsequent request-specific tracking status resource referred to by the Tk field's status-id. Each of the response mechanisms use a common format to indicate the tracking status for a designated resource. This tracking status value is a string of characters from a limited set, where the meaning of each allowed character is defined in the following table. status meaning None: The designated resource does not perform N tracking or make use of any data collected from tracking, not even for permitted uses. First party: The designated resource is designed 1 for use within a first-party context and conforms to the requirements on a first party. Third party: The designated resource is designed 3 for use within a first-party context and conforms to the requirements on a third party. Dynamic: The designated resource is designed for use in both first and third party contexts and dynamically adjusts tracking status accordingly. If this value is present in the site-wide tracking status, more information will be provided via the X Tk response header field. If this value is present in the Tk response header field, more information will be provided in the request-specific tracking status resource referred to by the status-id. "X" must not be present in the tracking status value of a request-specific tracking status resource. Service provider: The designated resource is operated by a service provider acting on behalf of S the first party and conforms to the requirements for both a first party and a service provider acting as a first party. Consent: The designated resource believes it has received prior explicit and informed consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this C specification, and that prior consent overrides the tracking preference expressed by this protocol. When prior consent is indicated, the tracking status object should include a control member that references a resource for modifying the consent. ISSUE-137: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) [OPEN] There is significant disagreement over whether a service provider acting on behalf of a first party needs to indicate such in the tracking status. It is particularly nonsensical given that there may be dozens of service providers acting on any request and the service provider definition is already limited to cases where any data collected is siloed and under control of the first party. 5.3 Tracking Status Resource 5.3.1 Definition An origin server must provide a tracking status resource at the well-known An origin server must provide a tracking status resource at the well-known identifier [RFC5785] identifier [RFC5785] /.well-known/dnt /.well-known/dnt (relative to the URI of that origin server) for obtaining information (relative to the URI of that origin server) for obtaining information about the potential tracking behavior of services provided by that origin about the potential tracking behavior of resources provided by that origin server. A tracking status resource may be used for verification of DNT server. A tracking status resource may be used for verification of DNT support, as described in section 5.1.3 Using the Tracking Status. support, as described in section 5.3.4 Using the Tracking Status. A valid retrieval request (e.g., a GET in [HTTP11]) on the well-known URI A valid retrieval request (e.g., a GET in HTTP) on the well-known URI must must result in either a successful response containing a machine-readable result in either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation. A user agent sequence of redirects that leads to such a representation. A user agent may consider failure to provide access to such a representation equivalent may consider failure to provide access to such a representation equivalent to the origin server not implementing this protocol. The representation to the origin server not implementing this protocol. The representation might be cached, as described in section 5.1.4 Tracking Status Caching. may be cached, as described in section 5.3.5 Caching. If an origin server contains multiple services that are controlled by If an origin server has multiple, resource-specific tracking policies, distinct parties or that might have differing behavior or policies such that the tracking status might differ depending on some aspect of the regarding tracking, then it may also provide a space of well-known request (e.g., method, target URI, header fields, data, etc.), the origin resources for obtaining information about the potential tracking behavior server may provide an additional subtree of well-known resources of each specific service. This parallel tree of resources is called the corresponding to each of those distinct tracking statuses. The Tk response tracking status resource space. header field (section 5.4 Tk Header Field for HTTP Responses) can include a status-id to indicate which specific tracking status resource applies to the current request. This subtree of resources is called the tracking status resource space. The tracking status resource space is defined by the following URI The tracking status resource space is defined by the following URI Template [URI-TEMPLATE]: Template [URI-TEMPLATE]: /.well-known/dnt{+pathinfo} /.well-known/dnt{/status-id} where the value of pathinfo is equal to the path component [RFC3986] of a where the value of status-id is a string of URI-safe characters provided given reference to that origin server, excluding those references already by a Tk field-value in response to a prior request. For example, a prior within the above resource space. For example, a reference to response containing http://example.com/over/here?q=hello#top Tk: 1;fRx42 may have a corresponding tracking status resource identified by refers to the specific tracking status resource http://example.com/.well-known/dnt/over/here /.well-known/dnt/fRx42 Resources within the tracking status resource space are represented using Resources within the tracking status resource space are represented using the same format as a site-wide tracking status resource. the same format as a site-wide tracking status resource. All requests for well-known URIs defined here must not be tracked, When sending a request for the tracking status, a user agent should irrespective of the presence, value, or absence of a DNT header, cookies, include any cookie data [COOKIES] (set prior to the request) that would be or any other information in the request. In addition, all responses to sent in a normal request to that origin server, since that data might be requests on a tracking status resource, including redirected requests, needed by the server to determine the current tracking status. For must not include Set-Cookie or Set-Cookie2 header fields [COOKIES] and example, the cookie data might indicate a prior out-of-band decision by must not include content that would have the effect of initiating tracking the user to opt-out or consent to tracking by that origin server. beyond what is already present for the request. A user agent should ignore or treat as an error any Set-Cookie or Set-Cookie2 header field received in such a response. 5.1.2 Tracking Status Representation All requests on the tracking status resource space, including the site-wide tracking status resource, must not be tracked, irrespective of the presence, value, or absence of a DNT header field, cookies, or any other information in the request. In addition, all responses to those requests, including the responses to redirected tracking status requests, must not have Set-Cookie or Set-Cookie2 header fields and must not have content that initiates tracking beyond what was already present in the request. A user agent should ignore, or treat as an error, any Set-Cookie or Set-Cookie2 header field received in such a response. 5.3.2 Representation The representation of a tracking status resource shall be provided in the The representation of a tracking status resource shall be provided in the "application/json" format [RFC4627] and must conform to the ABNF in "application/json" format [RFC4627] and must conform to the ABNF in section 5.1.5 Tracking Status ABNF. The following is an example tracking section 5.3.6 Status-object ABNF. The following is an example tracking status representation that illustrates all of the fields defined by this status representation that illustrates all of the fields defined by this specification, most of which are optional. specification, most of which are optional. { { "path": "/", "tracking": true, "tracking": true, "received": "1", "response": "t1", "response": "t1", "same-site": [ "same-party": [ "example.com", "example.com", "example_vids.net", "example_vids.net", "example_stats.com" "example_stats.com" ], ], "partners": [ "partners": [ "api.example-third-party.com" "api.example.net" ], "audit": [ "http://auditor.example.org/727073" ], ], "policy": "/tracking.html", "policy": "/tracking.html", "edit": "http://example-third-party.com/your/data", "control": "http://example.com/your/data" "options": "http://example-third-party.com/your/consent" } } A tracking status representation consists of a single status-object A tracking status representation consists of a single status-object containing members that describe the tracking status applicable to this containing members that describe the tracking status applicable to this user agent's request. user agent's request. If the status-object has an optional path member, then this object describes the tracking status for the entire space of resources that share the same path prefix as the value of path. The user agent must interpret the path value relative to the originally referenced resource, not the resource where it obtained the tracking status representation. For the site-wide tracking status resource, the presence of a path member with a value of "/" indicates that this status-object applies for the entire origin server of the originally referenced resource. If the originally referenced resource's path component does not share the same prefix as the value of path, or if the path member is absent, then the tracking status for the referenced resource may be obtained via a request on the corresponding tracking status resource space. A status-object must have a member named tracking with a boolean value. A A status-object must have a member named tracking with a boolean value. A value of false indicates that the corresponding resources do not perform value of false indicates that the corresponding resources do not perform tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true tracking as it is defined by [TRACKING-COMPLIANCE]. A value of true indicates that the corresponding resource performs tracking and claims to indicates that the corresponding resource performs tracking and claims to conform to all tracking compliance requirements applicable to this site. conform to all tracking compliance requirements applicable to this site. For example, the following demonstrates a minimal tracking status For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform representation that is applicable to any resource that does not perform tracking. tracking. {"tracking": false} {"tracking": false} The following status-object would indicate that the entire site does not If tracking is true, the status-object must include an additional member perform tracking. named response and may include other members as described below. {"path": "/", "tracking": false} If tracking is true, the status-object must include two additional members, named received and response, and may include other members as described below. The received member must have either a string value equal to the DNT-field-value received in that request or the value null if no DNT-field-value was received. Any invalid characters received in the DNT-field-value must be elided from the string value to ensure that invalid data is not injected into the JSON result. The response member must have a string value that indicates the status of The response member must have a string value that indicates the status of tracking applicable specifically to this user in light of the received tracking applicable specifically to this user in light of the received DNT-field-value. The string value begins with "t" (tracking) or "n" (not DNT-field-value. The string value begins with t (tracking), n (not tracking) and may be followed by alphanumeric characters that indicate tracking), or s (see the more specific tracking status resource), and may reasons for that status, as described in the following table. be followed by alphanumeric characters that indicate qualifiers for that status. The defined qualifier characters and their meanings are described reasons meaning in section 5.3.3 Qualifier Value. 1 Designed for use as a first-party only 3 Designed for use as a third-party a Limited to advertising audits c Prior consent received from this user agent f Limited to fraud prevention g For compliance with regional/geographic constraints q Limited to advertising frequency capping r Limited to referral information An optional member named same-site may be provided with an array value An optional member named same-party may be provided with an array value containing a list of domain names that the origin server claims are the containing a list of domain names that the origin server claims are the same site, to the extent they are referenced on this site, since all data same party, to the extent they are referenced on this site, since all data collected via those references share the same data controller. collected via those references share the same data controller. An optional member named partners may be provided with an array value An optional member named partners may be provided with an array value containing a list of domain names for third-party services that might containing a list of domain names for third-party services that might be track the user as a result of using this site and which do not have the invoked while using this site but do not share the same data controller as same data controller as this site. this site. An optional member named audit may be provided with an array value containing a list of URI references to external audits of the site's tracking policy and tracking behavior in compliance with this protocol. Preferably, the audit references are to resources that describe the auditor and the results of that audit; however, if such a resource is not available, a reference to the auditor is sufficient. An optional member named policy may be provided with a string value An optional member named policy may be provided with a string value containing a URI-reference to a human-readable document that describes the containing a URI-reference to a human-readable document that describes the tracking policy for this site. The content of such a policy document is tracking policy for this site. The content of such a policy document is beyond the scope of this protocol and only supplemental to what is beyond the scope of this protocol and only supplemental to what is described by this machine-readable tracking status representation. described by this machine-readable tracking status representation. An optional member named edit may be provided with a string value An optional member named control may be provided with a string value containing a URI-reference to a resource intended to allow a tracked user containing a URI-reference to a resource for giving the user control over agent to review or delete data collected by this site, if any such data personal data collected by this site. Such control might include the remains associated with this user agent. The design of such a resource and ability to review past data collected, delete some or all of the data, the extent to which it can provide access to that data is beyond the scope provide additional data (if desired), or opt-in, opt-out, or otherwise of this protocol. modify an out-of-band consent status regarding data collection by this site. The design of such a resource, the extent to which it can provide An optional member named options may be provided with a string value access to that data, and how one might implement an out-of-band consent containing a URI-reference to a resource intended to allow a user agent to mechanism is beyond the scope of this protocol. opt-in, opt-out, or otherwise modify their consent status regarding data collection by this site. The design of such a resource and how it might implement an out-of-band consent mechanism is beyond the scope of this protocol. Additional extension members may be provided in the status-object to Additional extension members may be provided in the status-object to support future enhancements to this protocol. A user agent should ignore support future enhancements to this protocol. A user agent should ignore extension members that it does not recognize. extension members that it does not recognize. Note that the tracking status resource space applies equally to both Note that the tracking status resource space applies equally to both first-party and third-party services. An example of a third-party tracking first-party and third-party services. An example of a third-party tracking status is status is { { "tracking": true, "tracking": true, "received": "1", "response": "n", "response": "n", "policy": "/privacy.html", "policy": "/privacy.html", "edit": "/your/data", "control": "/your/data", "options": "/your/consent" } } ISSUE-47: Should the response from the server indicate a policy that ISSUE-47: Should the response from the server indicate a policy that describes the DNT practices of the server? describes the DNT practices of the server? [PENDING REVIEW] The tracking status resource is a machine-readable policy [PENDING REVIEW] The tracking status resource is a machine-readable policy and provides a mechanism for supplying a link to a human-readable policy. and provides a mechanism for supplying a link to a human-readable policy. ISSUE-61: A site could publish a list of the other domains that are ISSUE-61: A site could publish a list of the other domains that are associated with them associated with them [PENDING REVIEW] The same-site and partners members provide a means to [PENDING REVIEW] The same-party and partners members provide a means to list first-party and third-party domains, respectively. list first-party and third-party domains, respectively. ISSUE-124: Alternative DNT implementations that replace HTTP headers with ISSUE-124: Alternative DNT implementations that replace HTTP headers with something else something else [PENDING REVIEW] The tracking status resource minimizes bandwidth usage [PENDING REVIEW] The tracking status resource minimizes bandwidth usage because only a small proportion of user agents are expected to perform because only a small proportion of user agents are expected to perform active verification, status would only be requested once per site per day, active verification, status would only be requested once per site per day, and the response can be extensively cached. and the response can be extensively cached. 5.1.3 Using the Tracking Status 5.3.3 Qualifier Value When present, the tracking status qualifier member's value consists of a string of characters indicating what permitted uses for tracking are being used. Multiple qualifiers can be provided. qualifier meaning Audit: Tracking is limited to that necessary for a an external audit of the service context and the data collected is minimized accordingly. Ad frequency capping: Tracking is limited to c frequency capping and the data collected is minimized accordingly. Fraud prevention: Tracking is limited to that f necessary for preventing or investigating fraudulent behavior and security violations; the data collected is minimized accordingly. Local constraints: Tracking is limited to what l is required by local law, rule, or regulation and the data collected is minimized accordingly. Referrals: Tracking is limited to collecting r referral information and the data collected is minimized accordingly. Qualifiers that indicate limitations on tracking correspond to the specific permitted uses in [TRACKING-COMPLIANCE]. An origin server indicating one or more of those permitted uses also indicates that it conforms to the requirements associated with those permitted uses. Multiple limitation qualifiers mean that multiple permitted uses of tracking might be present and that each such use conforms to the associated requirements. All limitation qualifiers imply some form of tracking might be used and thus must not be provided with a tracking status that begins with N (not tracking). Future extensions to this protocol might define additional characters as qualifiers from the ext-qualifier set (consisting of the remaining unused lowercase letters, dot, dash, and underscore). Recipients should ignore extension qualifiers that they do not understand. ISSUE-136: Resolve dependencies of the TPE on the compliance specification. The list of qualifiers is intended to correspond to constraints and permitted uses identified by [TRACKING-COMPLIANCE], and at some point might perhaps even move to that document in the sections defining the permitted uses. The above list will be updated accordingly. 5.3.4 Using the Tracking Status A key advantage of providing the tracking status at a resource separate A key advantage of providing the tracking status at a resource separate from the site's normal services is that the status can be accessed and from the site's normal services is that the status can be accessed and reviewed prior to making use of those services and prior to making reviewed prior to making use of those services and prior to making requests on third-party resources referenced by those services. In requests on third-party resources referenced by those services. In addition, the presence (or absence) of a site-wide tracking status addition, the presence (or absence) of a site-wide tracking status representation is a means for testing deployment of this standard and representation is a means for testing deployment of this standard and verifying that a site's claims regarding tracking are consistent with the verifying that a site's claims regarding tracking are consistent with the site's observed behavior over time. site's observed behavior over time. skipping to change at line 686 skipping to change at line 813 obtain the tracking status (up to some reasonable maximum of redirects to obtain the tracking status (up to some reasonable maximum of redirects to avoid misconfigured infinite request loops). If the response is avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message successful, obtain the tracking status representation from the message payload, if possible, or consider it an error. payload, if possible, or consider it an error. Once the tracking status representation is obtained, parse the Once the tracking status representation is obtained, parse the representation as JSON to extract the Javascript status-object. If parsing representation as JSON to extract the Javascript status-object. If parsing results in a syntax error, the user agent should consider the site to be results in a syntax error, the user agent should consider the site to be non-conformant with this protocol. non-conformant with this protocol. If the status-object does not have a member named path or if the value of path is not "/" and not a prefix of the path component for the URI being checked, then find the service-specific tracking status resource by taking the template /.well-known/dnt{+pathinfo} and replacing {+pathinfo} with the path component of the URI being checked. Perform a retrieval request on the service-specific tracking status resource and process the result as described above to obtain the specific tracking status. The status-object is supposed to have a member named tracking with a The status-object is supposed to have a member named tracking with a boolean value. If the value is false, then no tracking is performed for boolean value. If the value is false, then no tracking is performed for the URI being checked. If the value is true, then examine the member named the URI being checked. received to verify that the DNT header field sent by the user agent has been correctly received by the server. If the received value is incorrect, there may be an intermediary interfering with transmission of the DNT request header field. If the received value is correct, then examine the member named response Otherwise, examine the member named response to see what the origin server to see what the origin server has claimed regarding the tracking status has claimed regarding the tracking status for this user agent in light of for this user agent in light of the received DNT-field-value. the received DNT-field-value. If the first character of the response value is "n", then the origin If the first character of the response value is "n", then the origin server claims that it will not track the user agent for requests on the server claims that it will not track the user agent for requests on the URI being checked, and for any URIs with a path prefix matching the path URI being checked for at least the next 24 hours or until the member's value, for at least the next 24 hours or until the Cache-Control Cache-Control information indicates that this response expires, as information indicates that this response expires, as described below. described below. If the first character of the response value is "t", then the origin If the first character of the response value is "t", then the origin server claims that it might track the user agent for requests on the URI server claims that it might track the user agent for requests on the URI being checked, and for any URIs with a path prefix matching the path being checked for at least the next 24 hours or until the Cache-Control member's value, for at least the next 24 hours or until the Cache-Control information indicates that this response expires. information indicates that this response expires. The remaining characters of the response value might indicate reasons for If the first character of the response value is "s", then the origin the above choices or limitations that the origin server will place on its server has multiple tracking status representations and the specific one tracking. applicable to each request is indicated by a status-id within the Tk field-value of the corresponding response. The remaining characters of the response value might indicate qualifiers for the above choices or limitations that the origin server will place on its tracking. The others members of the status-object may be used to help the user agent The others members of the status-object may be used to help the user agent differentiate between a site's first-party and third-party services, to differentiate between a site's first-party and third-party services, to provide links to additional human-readable information related to the provide links to additional human-readable information related to the tracking policy, and to provide links for control over past data collected tracking policy, and to provide links for control over past data collected or over some consent mechanism outside the scope of this protocol. or over some consent mechanism outside the scope of this protocol. 5.1.4 Tracking Status Caching 5.3.5 Caching If the tracking status is applicable to all users, regardless of the If the tracking status is applicable to all users, regardless of the received DNT-field-value or other data received via the request, then the received DNT-field-value or other data received via the request, then the response should be marked as cacheable and assigned a time-to-live response should be marked as cacheable and assigned a time-to-live (expiration or max-use) that is sufficient to enable shared caching but (expiration or max-use) that is sufficient to enable shared caching but not greater than the earliest point at which the service's tracking not greater than the earliest point at which the service's tracking behavior might increase. For example, if the tracking status response is behavior might increase. For example, if the tracking status response is set to expire in seven days, then the earliest point in time that the set to expire in seven days, then the earliest point in time that the service's tracking behavior can be increased is seven days after the service's tracking behavior can be increased is seven days after the policy has been updated to reflect the new behavior, since old copies policy has been updated to reflect the new behavior, since old copies skipping to change at line 761 skipping to change at line 880 with one of the directives "no-cache", "no-store", "must-revalidate", or with one of the directives "no-cache", "no-store", "must-revalidate", or "max-age=0". "max-age=0". Regardless of the cache-control settings, it is expected that user agents Regardless of the cache-control settings, it is expected that user agents will check the tracking status of a service only once per session (at will check the tracking status of a service only once per session (at most). A public Internet site that intends to change its tracking status most). A public Internet site that intends to change its tracking status to increase tracking behavior must update the tracking status resource in to increase tracking behavior must update the tracking status resource in accordance with that planned behavior at least twenty-four hours prior to accordance with that planned behavior at least twenty-four hours prior to activating that new behavior on the service. activating that new behavior on the service. 5.1.5 Tracking Status ABNF A user agent that adjusts behavior based on active verification of tracking status, relying on cached tracking status responses to do so, should check responses to its state-changing requests (e.g., POST, PUT, DELETE, etc.) for a Tk header field with the update-needed field-value, as described in section 5.4.3 Indicating an Interactive Status Change. 5.3.6 Status-object ABNF The representation of a site's machine-readable tracking status must The representation of a site's machine-readable tracking status must conform to the following ABNF for status-object, except that the members conform to the following ABNF for status-object, except that the members within each member-list may be provided in any order. within each member-list may be provided in any order. status-object = begin-object member-list end-object status-object = begin-object member-list end-object member-list = [ path ns path-v vs ] member-list = tracking ns tracking-v tracking ns tracking-v [ vs response ns response-v ] [ vs received ns received-v ] [ vs same-party ns same-party-v ] [ vs response ns response-v ] [ vs partners ns partners-v ] [ vs same-site ns same-site-v ] [ vs audit ns audit-v ] [ vs partners ns partners-v ] [ vs policy ns policy-v ] [ vs policy ns policy-v ] [ vs control ns control-v ] [ vs edit ns edit-v ] [ vs options ns options-v ] *( vs extension ) *( vs extension ) path = %x22 "path" %x22 path-v = string ; URI absolute-path tracking = %x22 "tracking" %x22 tracking = %x22 "tracking" %x22 tracking-v = true / false tracking-v = true / false received = %x22 "received" %x22 received-v = null / string response = %x22 "response" %x22 response = %x22 "response" %x22 response-v = %x22 r-codes %x22 response-v = %x22 r-codes %x22 r-codes = ("t" / "n") *reasons r-codes = (%x74 / %x6E / %x73) *qualifier qualifier = "1" ; "1" - first-party / "3" ; "3" - third-party / %x61 ; "a" - audit / %x63 ; "c" - ad frequency capping / %x66 ; "f" - fraud prevention / %x6C ; "l" - local law, rule, or regulation / %x70 ; "p" - prior consent / %x72 ; "r" - referrals / ext-qualifier reasons = "1" ; first-party ext-qualifier = %x2D-2E / "0" / "2" / %x34-39 / %x5F / "3" ; third-party / %x62 / %x64-65 / %x67-6B / %x6D / %x6F / "a" ; advertising audits / %x71 / %x75-7A / "c" ; prior consent / "f" ; fraud prevention / "g" ; geographic/regional compliance / "q" ; frequency capping / "r" ; referrals / ALPHA / DIGIT ; TBD same-site = %x22 "same-site" %x22 same-party = %x22 "same-party" %x22 same-site-v = array-of-strings same-party-v = array-of-strings partners = %x22 "partners" %x22 partners = %x22 "partners" %x22 partners-v = array-of-strings partners-v = array-of-strings policy = %x22 "policy" %x22 audit = %x22 "audit" %x22 audit-v = array-of-strings policy = %x22 "policy" %x22 policy-v = string ; URI-reference policy-v = string ; URI-reference edit = %x22 "edit" %x22 control = %x22 "control" %x22 edit-v = string ; URI-reference control-v = string ; URI-reference options = %x22 "options" %x22 options-v = string ; URI-reference extension = object extension = object array-of-strings = begin-array array-of-strings = begin-array [ string *( vs string ) ] [ string *( vs string ) ] end-array end-array ns = <name-separator (:), as defined in [RFC4627]> ns = <name-separator (:), as defined in [RFC4627]> vs = <value-separator (,), as defined in [RFC4627]> vs = <value-separator (,), as defined in [RFC4627]> begin-array = <begin-array ([), as defined in [RFC4627]> begin-array = <begin-array ([), as defined in [RFC4627]> end-array = <end-array (]), as defined in [RFC4627]> end-array = <end-array (]), as defined in [RFC4627]> begin-object = <begin-object ({), as defined in [RFC4627]> begin-object = <begin-object ({), as defined in [RFC4627]> skipping to change at line 834 skipping to change at line 951 array-of-strings = begin-array array-of-strings = begin-array [ string *( vs string ) ] [ string *( vs string ) ] end-array end-array ns = <name-separator (:), as defined in [RFC4627]> ns = <name-separator (:), as defined in [RFC4627]> vs = <value-separator (,), as defined in [RFC4627]> vs = <value-separator (,), as defined in [RFC4627]> begin-array = <begin-array ([), as defined in [RFC4627]> begin-array = <begin-array ([), as defined in [RFC4627]> end-array = <end-array (]), as defined in [RFC4627]> end-array = <end-array (]), as defined in [RFC4627]> begin-object = <begin-object ({), as defined in [RFC4627]> begin-object = <begin-object ({), as defined in [RFC4627]> end-object = <end-object (}), as defined in [RFC4627]> end-object = <end-object (}), as defined in [RFC4627]> object = <object, as defined in [RFC4627]> object = <object, as defined in [RFC4627]> string = <string, as defined in [RFC4627]> string = <string, as defined in [RFC4627]> true = <true, as defined in [RFC4627]> true = <true, as defined in [RFC4627]> false = <false, as defined in [RFC4627]> false = <false, as defined in [RFC4627]> null = <null, as defined in [RFC4627]> null = <null, as defined in [RFC4627]> 5.4 Tk Header Field for HTTP Responses 5.2 Tk Header Field for HTTP Responses 5.2.1 Motivation This specification defines an HTTP response header, in order to meet the following needs: * User-agents can confirm that the server with which they are 5.4.1 Definition communicating has received their DNT request. * User-agents can determine which class of practices the server intends to follow when processing this particular request. * User-agents can determine if a server believes that the user has out-of-band consented to let them do additional tracking, and may be able to review or modify that consent. * Servers make a clear promise about how they will process data gathered from this particular request. * Servers have a well-known place to point to more information about their tracking/privacy practice. * Servers can provide customized information to clients if desired. An origin server may indicate the tracking status for a particular request As a supplement to the tracking status resource, the Tk response header by including a Tk header field in the corresponding response. If a request field is defined as an optional means for indicating DNT conformance and contains a DNT-field-value starting with "1", an origin server should send as a required means for indicating that a state-changing request has a Tk header field in the corresponding response. resulted in an interactive change to the tracking status for this user agent. If an origin server chooses not to send a Tk header field, then the user Tk-field-name = "Tk" ; case-insensitive agent will not know if the tracking preference has been received or if it Tk-field-value = tracking-design [ ";" status-id ] will be honored. This may have negative consequences for the site, such as tracking-design = tracking-never triggering preventive measures on the user agent or being flagged as / tracking-first non-compliant by tools that look for response header fields. / tracking-third / update-needed tracking-never = "0" tracking-first = "1" tracking-third = "3" update-needed = %x75 ; lowercase "u" ISSUE-107: Exact format of the response header? ISSUE-107: Exact format of the response header? [PENDING REVIEW] See the proposal in this section. [PENDING REVIEW] See the proposal in this section. ISSUE-120: Should the response header be mandatory (must) or recommended 5.4.2 Indicating Tracking Design (should) [PENDING REVIEW] Text in above paragraphs. 5.2.2 Tk ABNF The Tk header field is defined as follows: Tk-Response = "Tk:" [CFWS] Tk-Status [CFWS] [ opt-in-flag ] [CFW S] [ reason-code ] Tk-Status = no-dnt / not-tracking / first-party / service-provider no-dnt = "0" not-tracking = "1" first-party = %x66 ; lowercase f service-provider = %x73 ; lowercase s opt-in-flag = "1" reason-code = ALPHA 5.2.3 Tk Semantics Tk: 0 (no-dnt) indicates that this party does not comply with [TRACKING-COMPLIANCE]. Tk: 1 (not-tracking) indicates that: * this party complies with [TRACKING-COMPLIANCE], and * this party will process this request according to the specification for 3rd parties in [TRACKING-COMPLIANCE]. Tk: f (first-party) indicates that: * this party complies with [TRACKING-COMPLIANCE], * this resource is intended to be served as a first party, and * this party will process this request according to the specifications for 1st parties in [TRACKING-COMPLIANCE]. Tk: s (service-provider) indicates that: * this party complies with [TRACKING-COMPLIANCE], * this resource is intended to be used in the context of third party acting as an outsourced service provider for a first party, and * this party will process this request according to the exemption for a third party acting as an outsourced service provider for a first party, as described in [TRACKING-COMPLIANCE]. The opt-in-flag indicates that the server believes that the user has affirmatively consented to allow this party additional permission to track them. Unless the opt-in-flag is included, the server asserts that will act in responding to this request as if the user has not affirmatively consented to allow this party additional permission to track them. The reason-code can be used when requesting more information (see below). 5.2.4 More Information If a reason code is specified in the response, the well-known resource The Tk field-value begins with a single character tracking-design that defined here must exist; if an opt-in-flag is included, the wel--known indicates how the target resource conforms to [TRACKING-COMPLIANCE]. We resource defined here should exist; otherwise it may exist. refer to this as the tracking design because it reflects only how the resource is designed to work, rather than the current status of tracking for this requesting user agent or received DNT field-value. Separating the design and status allows conformance to this protocol to be indicated without having a negative impact on caching of responses. The user can understand and manage their opt-in by visiting the well-known An origin server may send a Tk header field in a response with a URI tracking-design of "0" to indicate that the resource never performs tracking as it is defined by [TRACKING-COMPLIANCE]. This has the same meaning as {"tracking": "false"} in the tracking status resource. /.well-known/dnt?status={Tk-status}&opt-in={opt-in-flag}&r={reason-code} Tk: 0 relative to the request-target. An origin server may send a Tk header field in a response with a tracking-design of "1" to indicate that the resource does perform tracking (though not necessarily for every request), conforms to [TRACKING-COMPLIANCE], and considers itself to be the first-party for this request. The information at this URI provides additional information about this Tk: 1 party's privacy practices and practices, particularly concerning the opt-in-flag. The above well-known URI has not yet been reconciled with the similar but An origin server may send a Tk header field in a response with a distinct definition for the tracking status resource. We anticipate that tracking-design of "3" to indicate that the resource does perform tracking one or the other will be adopted, or the two proposals will be merged. (though not necessarily for every request), conforms to [TRACKING-COMPLIANCE], and considers itself to be a third-party for this request. 5.2.5 Implementation and Usage Considerations Tk: 3 Implementers should use caution when allowing caching of resources on ISSUE-120: Should the response header be mandatory (must) or recommended which an opt-in flag is included. If caching is not carefully managed, (should) there is a risk of sending a response intended for opted-in users to users [PENDING REVIEW] The site-wide resource is mandatory; the header field is who haven't opted in. optional, except for the single must case below. Implementers should carefully choose the cache properties of the items at 5.4.3 Indicating an Interactive Status Change the well-known URI. The content at these locations must be correct for the entire cache duration, otherwise users who load stale cached copies of these resources may be misled. Any party can use the not-tracking response: this response just indicates We anticipate that interactive mechanisms might be used, beyond the scope a behavior. If a first party complies with the third-party definition, of this specification, that have the effect of asking for and obtaining they are free to send this response. However, the first-party and service prior consent for tracking, or for modifying prior indications of consent. provider responses indicate both a behavior and an intention about that For example, the tracking status resource's status-object defines a party's status. It would be deceptive to send the first-party header on a control member that can refer to such a mechanism. Although such resource which is only ever embedded as a third party. out-of-band mechanisms are not defined by this specification, their presence might influence the tracking status object's response value. The no-dnt response should not be used on requests which are processed in When an origin server provides a mechanism via HTTP for establishing or accordance with [TRACKING-COMPLIANCE]. An entity which implements DNT modifying out-of-band tracking preferences, the origin server must should not use this response. indicate within the mechanism's response when a state-changing request has resulted in a change to the tracking status for that server. This indication of an interactive status change is accomplished by sending a Tk header field in the response with a tracking-design of lowercase "u" (update-needed). When embedding content from other sites, consider how that site expects Tk: u their content to be used. If you embed/link to an object on another site, it's possible that the resource will send a first-party response even though it is now in a third-party context because the designer of that site never intended that object to be embedded. If a resource always sends a third-party response, there is no risk of this inconsistent response. Only the first-party outsourcer of service-provider objects should ever embed them. 5.2.6 Examples 5.4.4 Indicating a Specific Tracking Status Resource Tk: 1 If an origin server has multiple, resource-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server may provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The optional status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request. The site is a third or first party, in compliance with the definitions of For example, a response containing a 3rd party that is not tracking. Tk: 1 1 agreed Tk: 1;fRx42 The site is a third party, that believes it has an explicit opt-in from indicates that the target resource conforms to this protocol as a the user; more information can be found at: first-party and the current tracking status can be obtained by performing a retrieval request on /.well-known/dnt?status=1&opt-in=1&r=agreed /.well-known/dnt/fRx42 5.3 Status Code for Tracking Required 5.5 Status Code for Tracking Required An HTTP error response status code might be useful for indicating that the An HTTP error response status code might be useful for indicating that the site refuses service unless the user either logs into a subscription site refuses service unless the user either logs into a subscription account or agrees to an exception to DNT for this site and its contracted account or agrees to an exception to DNT for this site and its contracted third-party sites. third-party sites. 6. Site-specific Exceptions ISSUE-128: HTTP error status code to signal that tracking is required? ISSUE-118: Should requesting a user-agent-managed site-specific exception be asynchronous? [PENDING REVIEW] As proposed below. ISSUE-115: Should sites be able to manage site-specific tracking 6. User-Granted Exceptions exceptions outside of the user-agent-managed system? ISSUE-111: Different DNT values to signify existence of site-specific ISSUE-111: Different DNT values to signify existence of site-specific exception exceptions 6.1 Overview 6.1 Overview This section is non-normative. This section is non-normative. Exceptions to Do Not Track, including site-specific exceptions, are User-granted exceptions to Do Not Track, including site-specific managed by the user agent. A resource should rely on the DNT header it exceptions, are managed by the user agent. A resource should rely on the receives to determine the user's preference for tracking with respect to DNT header it receives to determine the user's preference for tracking that particular request. An API is provided so that sites may request and with respect to that particular request. An API is provided so that sites check the status of exceptions for tracking. may request and check the status of exceptions for tracking. We anticipate that many user-agents might provide a prompt to users when We anticipate that many user-agents might provide a prompt to users when this API is used, or to store exceptions. Questions of user interface this API is used, or to store exceptions. Questions of user interface specifics - for granting, configuring, storing, syncing and revoking specifics - for granting, configuring, storing, syncing and revoking exceptions - are explicitly left open to implementers. exceptions - are explicitly left open to implementers. 6.2 Motivating principles and use cases 6.2 Motivating principles and use cases This section is non-normative. This section is non-normative. The following principles guide the design of the user-agent-managed The following principles guide the design of user-agent-managed site-specific exceptions proposal. exceptions. * Content providers may wish to prompt visitors to their properties to * Content providers may wish to prompt visitors to their properties to "opt back in" to tracking for behavioral advertising or similar "opt back in" to tracking for behavioral advertising or similar purposes when they arrive with the Do Not Track setting enabled. purposes when they arrive with the Do Not Track setting enabled. * Privacy-conscious users may wish to view or edit all the site-specific * Privacy-conscious users may wish to view or edit all the exceptions exceptions they've granted in a single, consistent user interface, they've granted in a single, consistent user interface, rather than rather than managing preferences in a different way on every content managing preferences in a different way on every content provider or provider or tracker's privacy page. tracker's privacy page. * Granting an exception in one context (while browsing a news site) * Granting an exception in one context (while browsing a news site) should not apply that exception to other contexts (browsing a medical should not apply that exception to other contexts (browsing a medical site) that may not be expected. site) that may not be expected. * Tracking providers should not ever have to second-guess a user's * Tracking providers should not ever have to second-guess a user's expressed Do Not Track preference. expressed Do Not Track preference. * The solution should not require cross-domain communication between a * The solution should not require cross-domain communication between a first party publisher and its third party trackers. first party publisher and its third parties. When asking for a site-specific exception, the top-level domain making the request may be making some implicit or explicit claims as to the actions and behavior of its third parties; for this reason, it might want to establish exceptions for only those for which it is sure that those claims are true. (Consider a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). For this reason, there is support both for explicitly named sites, as well as support for granting an exception to all third-parties on a given site (site-wide exception, using the wild-card "*"). There are some cases in which a user may desire a site to be allowed to track them on any top-level domain. An API is provided so that the site and the user may establish such a web-wide exception. 6.3 Exception model 6.3 Exception model 6.3.1 Site pairs 6.3.1 Introduction This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but should not be read as mandating any specific implementation. This API considers exceptions which are double-keyed to two domains: the This API considers exceptions which are double-keyed to two domains: the site, and the tracker. A user might - for instance - want AnalytiCo to site, and the target. A user might - for instance - want AnalytiCo to track them on Example News, but not on Example Medical. To simplify track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define two terms: language used in this API specification, we define two terms: * This site is the domain name of the top-level document origin of this * Top-Level Domain (TLD) is the domain name of the top-level document DOM: essentially the fully qualified domain name in the address bar. origin of this DOM: essentially the fully qualified domain name in the * A tracker is a domain name which is not operated by the same party address bar. For all these APIs, this must match the script origin. which operates this site, and which may be an origin for embedded * A target site is a domain name which is the target of an HTTP request, resources on this site. and which may be an origin for embedded resources on the indicated top-level domain. For instance, if the document at For instance, if the document at http://web.exnews.com/news/story/2098373.html references the resources http://web.exnews.com/news/story/2098373.html references the resources http://exnews.analytico.net/1x1.gif and http://exnews.analytico.net/1x1.gif and http://widgets.exsocial.org/good-job-button.js, this site is http://widgets.exsocial.org/good-job-button.js, the top-level domain is web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both web.exnews.com; exnews.analytico.net and widgets.exsocial.org are both trackers. targets. ISSUE-112: How are sub-domains handled for site-specific exceptions? ISSUE-112: How are sub-domains handled for site-specific exceptions? Should a request for a tracking exception apply to all subdomains of the Should a request for a tracking exception apply to all subdomains of the first party making the request? Or should a first party explicitly list first party making the request? Or should a first party explicitly list the subdomains that it's asking for? Similarly, should third party the subdomains that it's asking for? Similarly, should third party subdomains be allowed (e.g. *.tracker.com)? subdomains be allowed (e.g. *.tracker.com)? Proposal: Exceptions are requested for fully-qualified domain names. Proposal: Exceptions are requested for fully-qualified domain names. The domains that enter into the behavior of the APIs include: * As described above, the Top-Level Domain (TLD); * The domain of the origin of the script; * Domain names passed to the API; * Domains declared in the well-known resource as 'partners'. Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT header it sends them. During the execution of these APIs, the top-level browsing domain and the domain origin of the script must match, otherwise no action is taken, and an error value returned. The calls causes the following steps to occur: * First, the UA somehow confirms with the user that they agree to the grant of exception; * If they agree, then the UA adds to its local database one or more site-pair duplets [top-level-domain, other-domain]; one or other of these may be a wild-card ("*"); * While the user is browsing a given site [top-level domain], and a DNT header is to be sent to a target domain, if the duplet [top-level domain, target domain] matches any duplet in the database, then a DNT:0 header is sent, otherwise DNT:1 is sent. 6.3.2 Exception use by browsers 6.3.2 Exception use by browsers If a user wishes to be tracked by a tracker on this site, this should If a user wishes to allow tracking by a target on the top-level domain, result in two user-agent behaviors: this should result in two user-agent behaviors: 1. If requests to the tracker for resources that are part of the DOM for 1. If requests to the target for resources that are part of the DOM for pages on this site include a DNT header, that header must be DNT:OFF. pages on top-level domain include a DNT header, that header must be DNT:0. 2. Responses to the JavaScript API indicated should be consistent with 2. Responses to the JavaScript API indicated should be consistent with this user preference (see below). this user preference (see below). What is the effect of re-directs, when the source of the re-direct would get a different DNT header than the target, using these matching rules? It is left up to individual user-agent implementations how to determine It is left up to individual user-agent implementations how to determine and how and whether to store users' tracking preferences. and how and whether to store users' tracking preferences. ISSUE-111: Different DNT values to signify existence of site-specific When an explicit list of domains is provided, their names might mean little to the user. The user might, for example, be told that such-and-such top-level domain is asking for an exception for a specific set of sites, rather than listing them by name. Conversely, if a wild-card is or will be used, the user may be told that the top-level domain is asking for an exception for all third-parties that are, or will be, embedded in it. ISSUE-111: Different DNT values to signify existence of user-granted exception exception Should the user agent send a different DNT value to a first party site if Should the user agent send a different DNT value to a first party site if there exist site-specific exceptions for that first party? (e.g. DNT:2 there exist user-granted exceptions for that first party? (e.g. DNT:2 implies "I have Do Not Track enabled but grant permissions to some third implies "I have Do Not Track enabled but grant permissions to some third parties while browsing this domain") parties while browsing this domain") Proposal: No, this API provides client-side means for sites to request Proposal: No, this API provides client-side means for sites to request that information. Sites may also employ cookies to recall a user's past that information. Sites may also employ cookies to recall a user's past response. response. Finally, a site may add [self, self] to the database as part of its request, and it will then get DNT:0. 6.4 JavaScript API for site-specific exceptions 6.4 JavaScript API for site-specific exceptions 6.4.1 API to request site-specific exceptions [NoInterfaceObject] [NoInterfaceObject] interface NavigatorDoNotTrack { interface NavigatorDoNotTrack { void requestSiteSpecificTrackingException (sequence<DOMString> arrayOfDomai void requestSiteSpecificTrackingException (TrackingResponseCallback callbac nStrings, TrackingResponseCallback callback, optional siteName, optional expla k, optional siteName, optional explanationString, optional detailURI); nationString, optional detailURI); }; }; 6.4.1 Methods 6.4.1.1 Methods requestSiteSpecificTrackingException requestSiteSpecificTrackingException Called by a page to request or confirm a site-specific tracking Called by a page to request or confirm a user-granted tracking exception. exception. Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description arrayOfDomainStrings sequence<DOMString> * * callback TrackingResponseCallback * * callback TrackingResponseCallback * * siteName * * siteName * * explanationString * * explanationString * * detailURI * * detailURI * * Return type: void Return type: void [Callback, NoInterfaceObject] [Callback, NoInterfaceObject] interface TrackingResponseCallback { interface TrackingResponseCallback { void handleEvent (boolean granted); void handleEvent (boolean granted); }; }; 6.4.2 Methods 6.4.1.2 Methods handleEvent handleEvent The callback is called by the user agent to indicate the user's The callback is called by the user agent to indicate the user's response. response. Parameter Type Nullable Optional Description Parameter Type Nullable Optional Description granted boolean * * granted boolean * * Return type: void Return type: void The requestSiteSpecificTrackingException method takes two mandatory The requestSiteSpecificTrackingException method takes the mandatory arguments: argument: * arrayOfDomainStrings, a JavaScript array of strings, and * callback, a method that will be called when the request is complete. * callback, a method that will be called when the request is complete. It also takes three optional arguments: It also takes three optional arguments: * siteName, a string for the name of this site, * siteName, a string for the name of the top-level domain (script origin), * explanationString, a short explanation of the request, and * explanationString, a short explanation of the request, and * detailURI, a location at which further information about this request * detailURI, a location at which further information about this request can be found. can be found. Each string in arrayOfDomainStrings specifies a tracker. The special When called, requestSiteSpecificTrackingException must return immediately, string "*" signifies all trackers. When called, then asynchronously determine whether the user grants the requested requestSiteSpecificTrackingException must return immediately, then exception(s). asynchronously determine whether the user wants the requested exceptions. The execution of this API and the use of the resulting permission (if granted) use two 'implicit' parameters, when the API is called: * the domain of the origin of the script (script-origin); * the 'partners' list at the well-known URL location. The user-agent should use the partners as the list of targets, if it exists, or a list containing the single special string "*", indicating all targets, as the target if it does not; it may use a list of the special string "*" even if the partners list exists. The granted parameter passed to the callback is the user's response; true The granted parameter passed to the callback is the user's response; true indicates the user wants an exception on this site for all of the trackers indicates the user grants an exception on top-level domain for all of the specified in arrayOfDomainStrings. The response false indicates that the targets. The response false indicates that the user does not want an user does not want an exception on this site for at least one of the exception on top-level domain for at least one of the targets. trackers specified in arrayOfDomainStrings. If permission is granted, then the set of duplets (one per target): [top-level-domain, target] is added to the database of remembered grants. A particular response to the API - like a DNT response header - is only A particular response to the API - like a DNT response header - is only valid immediately, and users' preferences may change. valid immediately, and users' preferences may change. A user agent may use an interactive method to ask the user about their A user agent may use an interactive method to ask the user about their preferences, so sites should not assume that the callback function will be preferences, so sites should not assume that the callback function will be called immediately. called immediately. ISSUE-109: siteSpecificTrackingExceptions property has fingerprinting 6.4.2 API to cancel a site-specific exception risks: is it necessary? [PENDING REVIEW] It has been removed from the proposal. 6.5 User interface guidelines [NoInterfaceObject] interface NavigatorDoNotTrack { void removeSiteSpecificTrackingException (); }; 6.4.2.1 Methods removeSiteSpecificTrackingException Ensures that the database of remembered grants no longer contains any duplets [top-level-domain, target] for any target. This method never fails and there is no callback. After the call has been made, it is assured that there are no site-specific exceptions for the given top-level-domain. No parameters. Return type: void 6.5 JavaScript API for web-wide exceptions ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide exception? PROPOSAL: In this section 6.5.1 API to request a web-wide exception [NoInterfaceObject] interface NavigatorDoNotTrack { void requestWebWideTrackingException (TrackingResponseCallback callback, op tional siteName, optional explanationString, optional detailURI); }; 6.5.1.1 Methods requestWebWideTrackingException If permission is granted, then the single duplet [ * , top-level-domain] is added to the database of remembered grants. The parameters are as described above in the request for site-specific exceptions. Parameter Type Nullable Optional Description callback TrackingResponseCallback * * siteName * * explanationString * * detailURI * * Return type: void Users may wish to configure exceptions for a certain trusted tracker across all sites. This API requests the addition of a web-wide grant for a specific site, to the database. 6.5.2 API to cancel a web-wide exception [NoInterfaceObject] interface NavigatorDoNotTrack { void removeWebWideTrackingException (); }; 6.5.2.1 Methods removeWebWideTrackingException Ensures that the database of remembered grants no longer contains [ * , top-level-domain] This method never fails and there is no callback. After the call has been made, the indicated pair is assured not to be in the database. The same matching as is used for determining which header to send is used to detect which entry (if any) to remove from the database. No parameters. Return type: void 6.6 User interface guidelines This section is non-normative. This section is non-normative. User agents are free to implement exception management user interfaces as User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a prompt to the user at the time they see fit. Some agents might provide a prompt to the user at the time of the request. Some agents might allow users to configure this preference of the request. Some agents might allow users to configure this preference in advance. In either case, the user agent responds with the user's in advance. In either case, the user agent responds with the user's preference. preference. A user agent that chooses to implement a prompt to present tracking A user agent that chooses to implement a prompt to present tracking exception requests to the user might provide an interface like the exception requests to the user might provide an interface like the following: following: Example News (web.exnews.com) would like to know Example News (web.exnews.com) would like to know whether you permit tracking by the following parties: whether you permit tracking by a specific set of sites (click * exnews.analytico.net here for their names). * widgets.exsocial.org Example News says: Example News says: "These sites allow Example News to see how we're "These sites allow Example News to see how we're doing, and provide useful features of the Example News doing, and provide useful features of the Example News experience." [More info] experience." [More info] [Allow Tracking] [Deny Tracking Request] [Allow Tracking] [Deny Tracking Request] In this example, the domains listed are those specified in In this example, the domains listed are those specified in arrayOfDomainStrings, the phrase "Example News" is from siteName, and the arrayOfDomainStrings, the phrase "Example News" is from siteName, and the explanationString is displayed for the user with a "More info" link explanationString is displayed for the user with a "More info" link pointing to detailURI. pointing to detailURI. The user agent might then store that decision, and answer future requests The user agent might then store that decision, and answer future requests based on this stored preference. User agents might provide users with based on this stored preference. A user agent might provide the user with granular choice over which tracking origins are granted site-specific an interface to explicitly remove (or add) user-granted exceptions. exceptions and which are not (using checkboxes, for example). User agents might automatically clear site-specific exceptions after a period of time or in response to user activity, like leaving a private browsing mode or using a preference manager to edit their chosen exceptions. If a user agent retains user preferences, it might provide the user with an interface to explicitly add or remove site-specific exceptions. Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification. (or the lack thereof) is out of the scope of this specification. In some user-agent implementations, decisions to grant exceptions may have In some user-agent implementations, decisions to grant exceptions may have been made in the past (and since forgotten) or may have been made by other been made in the past (and since forgotten) or may have been made by other users of the device. Thus, exceptions may not always represent the current users of the device. Thus, exceptions may not always represent the current preferences of the user. Some user agents might choose to provide ambient preferences of the user. Some user agents might choose to provide ambient notice that user-opted tracking is ongoing, or easy access to view and notice that user-opted tracking is ongoing, or easy access to view and control these preferences. Users may desire options to edit exceptions control these preferences. Users may desire options to edit exceptions either at the time of tracking or in a separate user interface. This might either at the time of tracking or in a separate user interface. This might allow the user to edit their preferences for a site they do not trust allow the user to edit their preferences for a site they do not trust without visiting that site. without visiting that site. ISSUE: Should there be a normative requirement for the existence of a ISSUE-83: How do you opt out if already opted in? revocation mechanism? (raised by npdoty) PROPOSAL: In this section 6.6 Exceptions without a DNT header ISSUE-129: Should a blanket exception of the type ["firstparty", "*"] be possible? PROPOSAL: In this section ISSUE-130: Should a global exception for a given third party on all sites be supported? PROPOSAL: In this section ISSUE-140: Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a site? PROPOSAL: In this section; yes, as some sites may have a mix of trusted/needed third parties, and others that either don't need to track, or aren't as trusted, or both. 6.7 Exceptions without a DNT header Sites might wish to request exceptions even when a user arrives without a Sites might wish to request exceptions even when a user arrives without a DNT header. Users might wish to grant affirmative permission to tracking DNT header. Users might wish to grant affirmative permission to tracking on or by certain sites even without expressing general tracking on or by certain sites even without expressing general tracking preferences. preferences. User agents may instantiate User agents may instantiate NavigatorDoNotTrack.requestSiteSpecificTrackingException even when NavigatorDoNotTrack.requestSiteSpecificTrackingException even when navigator.doNotTrack is null. Sites should test for the existence of navigator.doNotTrack is null. Sites should test for the existence of requestSiteSpecificTrackingException before calling the method. If an requestSiteSpecificTrackingException before calling the method. If an skipping to change at line 1266 skipping to change at line 1484 preference, a user agent may send a DNT:0 header even if a tracking preference, a user agent may send a DNT:0 header even if a tracking preference isn't expressed for other requests. Persisted preferences may preference isn't expressed for other requests. Persisted preferences may also affect which header is transmitted if a user later chooses to express also affect which header is transmitted if a user later chooses to express a tracking preference. a tracking preference. Users might not configure their agents to have simple values for DNT, but Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification. (or the lack thereof) is out of the scope of this specification. 6.7 Web-wide exceptions Users may wish to configure exceptions for a certain trusted tracker across several or all sites. User agent configuration of these preferences is outside the scope of this specification. ISSUE-113: Should there be a JavaScript API to prompt for a Web-wide exception? PROPOSAL: User agents can provide configuration options outside the scope of this specification. 6.8 Fingerprinting 6.8 Fingerprinting By storing a client-side configurable state and providing functionality to By storing a client-side configurable state and providing functionality to learn about it later, this API might facilitate user fingerprinting and learn about it later, this API might facilitate user fingerprinting and tracking. User agent developers ought to consider the possibility of tracking. User agent developers ought to consider the possibility of fingerprinting during implementation and might consider rate-limiting fingerprinting during implementation and might consider rate-limiting requests or using other heuristics to mitigate fingerprinting risk. User requests or using other heuristics to mitigate fingerprinting risk. User agents should clear stored site-specific exceptions when the user chooses agents should clear stored user-granted exceptions when the user chooses to clear cookies or other client-side state. to clear cookies or other client-side state. ISSUE-114: Guidance or mitigation of fingerprinting risk for user-agent-managed site-specific tracking exceptions PENDING REVIEW Above text provides guidance for user agent developers. A. Acknowledgements A. Acknowledgements This specification consists of input from many discussions within and This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written around the W3C Tracking Protection Working Group, along with written contributions from Nick Doty (W3C/MIT), Roy T. Fielding (Adobe), Tom contributions from Nick Doty (W3C/MIT), Roy T. Fielding (Adobe), Lowenthal (Mozilla), Aleecia M. McDonald (Mozilla), Matthias Schunter Tom Lowenthal (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (IBM), John Simpson (Consumer Watchdog), David Singer (Apple), Shane Wiley (Mozilla), Matthias Schunter (IBM), John Simpson (Consumer Watchdog), (Yahoo!), and Andy Zeigler (Microsoft). David Singer (Apple), Rigo Wenning (W3C/ERCIM), Shane Wiley (Yahoo!), and Andy Zeigler (Microsoft). The DNT header field is based on the original Do Not Track submission by The DNT header field is based on the original Do Not Track submission by Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js. feedly mini B. References B. References B.1 Normative references B.1 Normative references [ABNF] [ABNF] D. Crocker and P. Overell. Augmented BNF for Syntax D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet RFC 5234. URL: Specifications: ABNF. January 2008. Internet RFC 5234. URL: http://www.ietf.org/rfc/rfc5234.txt http://www.ietf.org/rfc/rfc5234.txt skipping to change at line 1338 skipping to change at line 1544 [RFC4627] [RFC4627] D. Crockford. The application/json Media Type for JavaScript D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) July 2006. Internet RFC 4627. URL: Object Notation (JSON) July 2006. Internet RFC 4627. URL: http://www.ietf.org/rfc/rfc4627.txt http://www.ietf.org/rfc/rfc4627.txt [TRACKING-COMPLIANCE] [TRACKING-COMPLIANCE] Justin Brookman; Sean Harvey; Erica Newland; Heather West. Justin Brookman; Sean Harvey; Erica Newland; Heather West. Tracking Compliance and Scope. 13 March 2012. W3C Working Draft. Tracking Compliance and Scope. 13 March 2012. W3C Working Draft. (Work in progress.) URL: (Work in progress.) URL: http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/ http://www.w3.org/TR/2011/WD-tracking-compliance-20120313/ [WEBIDL] [WEBIDL] Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. (Work in progress.) URL: (Work in progress.) URL: http://www.w3.org/TR/2011/WD-WebIDL-20110927/ http://www.w3.org/TR/2011/WD-WebIDL-20110927/ B.2 Informative references B.2 Informative references [COOKIES] [COOKIES] Adam Barth. HTTP State Management Mechanism. April 2011. Internet Adam Barth. HTTP State Management Mechanism. April 2011. Internet Proposed Standard RFC 6265. URL: Proposed Standard RFC 6265. URL: http://www.rfc-editor.org/rfc/rfc6265.txt http://www.rfc-editor.org/rfc/rfc6265.txt [KnowPrivacy] [KnowPrivacy] Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June 2009. URL: 2009. URL: http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf [RFC3986] T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt [RFC5785] [RFC5785] Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform Resource Identifiers (URIs). April 2010. Internet Proposed Resource Identifiers (URIs). April 2010. Internet Proposed Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt [URI-TEMPLATE] [URI-TEMPLATE] Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David Orchard. URI Template. 26 January 2012. Internet Draft (work in Orchard. URI Template. March 2012. Internet RFC 6570. URL: progress). URL: http://www.rfc-editor.org/rfc/rfc6570.txt http://tools.ietf.org/html/draft-gregorio-uritemplate-08 feedly mini End of changes. 152 change blocks. 505 lines changed or deleted 707 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3