W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

plain text of TPE spec as of 14 Sep 2012

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 20 Sep 2012 00:24:09 -0700
Message-Id: <AF4E4713-AA39-419B-9956-B55E7841A37B@gbiv.com>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Below is a plain text version of the generated source of the current
editors' draft for tracking preference expression (DNT), which may be
useful to folks who find it easier to respond in email with context
than to make comments indirectly by section number.

....Roy
    ----------------------------------------------------------------------
   W3C

                      Tracking Preference Expression (DNT)

W3C Editor's Draft 14 September 2012

   This version:
           http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

   Latest published version:
           http://www.w3.org/TR/tracking-dnt/

   Latest editor's draft:
           http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

   Editors:
           Roy T. Fielding, Adobe
           David Singer, Apple

   Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved.
   W3C liability, trademark and document use rules apply.

     ----------------------------------------------------------------------

Abstract

   This specification defines the technical mechanisms for expressing a
   tracking preference via the DNT request header field in HTTP, via an HTML
   DOM property readable by embedded scripts, and via properties accessible
   to various user agent plug-in or extension APIs. It also defines
   mechanisms for sites to signal whether and how they honor this preference,
   both in the form of a machine-readable tracking status resource at a
   well-known location and via a Tk response header field, and a mechanism
   for allowing the user to approve site-specific exceptions to DNT as
   desired.

Status of This Document

   This section describes the status of this document at the time of its
   publication. Other documents may supersede this document. A list of
   current W3C publications and the latest revision of this technical report
   can be found in the W3C technical reports index at http://www.w3.org/TR/.

   This document is an editors' strawman reflecting a snapshot of live
   discussions within the Tracking Protection Working Group. It does not yet
   capture all of our work. For example, we have issues that are [PENDING
   REVIEW] with complete text proposals that have not yet made it into this
   draft. Text in blue boxes presents multiple options the group is
   considering. An issue tracking system is available for recording raised,
   open, pending review, closed, and postponed issues regarding this
   document.

   This document was published by the Tracking Protection Working Group as an
   Editor's Draft. If you wish to make comments regarding this document,
   please send them to public-tracking@w3.org (subscribe, archives). All
   feedback is welcome.

   Publication as an Editor's Draft does not imply endorsement by the W3C
   Membership. This is a draft document and may be updated, replaced or
   obsoleted by other documents at any time. It is inappropriate to cite this
   document as other than work in progress.

   This document was produced by a group operating under the 5 February 2004
   W3C Patent Policy. W3C maintains a public list of any patent disclosures
   made in connection with the deliverables of the group; that page also
   includes instructions for disclosing a patent. An individual who has
   actual knowledge of a patent which the individual believes contains
   Essential Claim(s) must disclose the information in accordance with
   section 6 of the W3C Patent Policy.

Table of Contents

     * 1. Introduction
     * 2. Notational Conventions
          * 2.1 Requirements
          * 2.2 Formal Syntax
          * 2.3 Terminology
     * 3. Determining User Preference
     * 4. Expressing a Tracking Preference
          * 4.1 Expression Format
          * 4.2 DNT Header Field for HTTP Requests
          * 4.3 JavaScript API to Detect Preference
          * 4.4 Plug-In APIs
          * 4.5 Tracking Preference Expressed in Other Protocols
     * 5. Communicating a Tracking Status
          * 5.1 Overview
          * 5.2 Tracking Status Value
          * 5.3 Tracking Status Qualifier Values
          * 5.4 Tk Header Field for HTTP Responses
               * 5.4.1 Definition
               * 5.4.2 Referring to a Request-specific Tracking Status
                 Resource
               * 5.4.3 Indicating an Interactive Status Change
          * 5.5 Tracking Status Resource
               * 5.5.1 Site-wide Tracking Status
               * 5.5.2 Request-specific Tracking Status
               * 5.5.3 Representation
               * 5.5.4 Status Checks are Not Tracked
               * 5.5.5 Caching
          * 5.6 Status Code for Tracking Required
          * 5.7 Using the Tracking Status
               * 5.7.1 Discovering Deployment
               * 5.7.2 Preflight Checks
     * 6. User-Granted Exceptions
          * 6.1 Overview
          * 6.2 Motivating Principles and Use Cases
          * 6.3 Exception model
               * 6.3.1 Introduction
               * 6.3.2 Exception use by browsers
          * 6.4 JavaScript API for Site-specific Exceptions
               * 6.4.1 API to request site-specific exceptions
               * 6.4.2 API to Cancel a Site-specific Exception
          * 6.5 JavaScript API for Web-wide Exceptions
               * 6.5.1 API to Request a Web-wide Exception
               * 6.5.2 API to cancel a web-wide exception
          * 6.6 Querying a host's exception status
          * 6.7 Transfer of an exception to another third party
          * 6.8 User interface guidelines
          * 6.9 Exceptions without a DNT header
          * 6.10 Fingerprinting
     * A. Acknowledgements
     * B. References
          * B.1 Normative references
          * B.2 Informative references

1. Introduction

   The World Wide Web (WWW, or Web) consists of millions of sites
   interconnected through the use of hypertext. Hypertext provides a simple,
   page-oriented view of a wide variety of information that can be traversed
   by selecting links, manipulating controls, and supplying data via forms
   and search dialogs. A Web page is usually composed of many different
   information sources beyond the initial resource request, including
   embedded references to stylesheets, inline images, javascript, and other
   elements that might be automatically requested as part of the rendering or
   behavioral processing defined for that page.

   Each of the hypertext actions and each of the embedded resource references
   might refer to any site on the Web, leading to a seamless interaction with
   the user even though the pages might be composed of information requested
   from many different and possibly independent Web sites. From the user's
   perspective, they are simply visiting and interacting with a single brand
   - the first-party Web property - and all of the technical details and
   protocol mechanisms that are used to compose a page representing that
   brand are hidden behind the scenes.

   It has become common for Web site owners to collect data regarding the
   usage of their sites for a variety of purposes, including what led the
   user to visit their site (referrals), how effective the user experience is
   within the site (web analytics), and the nature of who is using their site
   (audience segmentation). In some cases, the data collected is used to
   dynamically adapt the content (personalization) or the advertising
   presented to the user (targeted advertising). Data collection can occur
   both at the first-party site and via third-party providers through the
   insertion of tracking elements on each page. A survey of these techniques
   and their privacy implications can be found in [KnowPrivacy].

   People have the right to know how data about them will be collected and
   how it will be used. Empowered with that knowledge, individuals can decide
   whether to allow their online activities to be tracked and data about them
   to be collected. Many Internet companies use data gathered about people's
   online activities to personalize content and target advertising based on
   their perceived interests. While some people appreciate this
   personalization of content and ads in certain contexts, others are
   troubled by what they perceive as an invasion of their privacy. For them,
   the benefit of personalization is not worth their concerns about allowing
   entities with whom they have no direct relationship to amass detailed
   profiles about their activities.

   Therefore, users need a mechanism to express their own preference
   regarding tracking that is both simple to configure and efficient when
   implemented. In turn, Web sites that are unwilling or unable to offer
   content without such targeted advertising or data collection need a
   mechanism to indicate those requirements to the user and allow them (or
   their user agent) to make an individual choice regarding exceptions.

   This specification defines the HTTP request header field DNT for
   expressing a tracking preference on the Web, a well-known location (URI)
   for providing a machine-readable tracking status resource that describes a
   service's DNT compliance, the HTTP response header field Tk for resources
   to communicate their compliance or non-compliance with the user's
   expressed preference, and JavaScript APIs for determining DNT status and
   requesting a user-granted exception.

   A companion document, [TRACKING-COMPLIANCE], more precisely defines the
   terminology of tracking preferences, the scope of its applicability, and
   the requirements on compliant first-party and third-party participants
   when an indication of tracking preference is received.

   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 scope of DNT. As such, a site cannot actually say with any confidence
   whether or not it is tracking, let alone describe the finer details in a
   tracking status resource. This issue will be resolved by progress on the
   TCS document, though its resolution is a necessary prerequisite to
   understanding and correctly implementing the protocol defined by this
   document.

2. Notational Conventions

  2.1 Requirements

   The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
   MAY, and OPTIONAL in this specification are to be interpreted as described
   in [RFC2119].

  2.2 Formal Syntax

   This specification uses Augmented Backus-Naur Form [ABNF] to define
   network protocol syntax and WebIDL [WEBIDL] for defining scripting APIs.

  2.3 Terminology

   This specification uses the term user agent to refer to any of the various
   client programs capable of initiating HTTP requests, including, but not
   limited to, browsers, spiders (web-based robots), command-line tools,
   native applications, and mobile apps [HTTP11].

   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 by a given third party, usually in the form of a site-specific
   exception.

   A companion document, [TRACKING-COMPLIANCE], defines many of the terms
   used here, notably 'party', 'first party', and 'third party'.

3. Determining User Preference

   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
   communicate with via HTTP, thereby allowing each service to either adjust
   their behavior to meet the user's expectations or reach a separate
   agreement with the user to satisfy all parties.

   Key to that notion of expression is that it MUST reflect the user's
   preference, not the choice of some vendor, institution, or network-imposed
   mechanism outside the user's control. The basic principle is that a
   tracking preference expression is only transmitted when it reflects a
   deliberate choice by the user. In the absence of user choice, there is no
   tracking preference expressed.

   A user agent MUST offer users a minimum of two alternative choices for a
   Do Not Track preference: unset or DNT:1. A user agent MAY offer a third
   alternative choice: DNT:0.

   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
   configuration, install an extension or add-on that is specifically
   designed to add a tracking preference expression, or make a choice for
   privacy that then implicitly includes a tracking preference (e.g., Privacy
   settings: high). The user-agent might ask the user for their preference
   during startup, perhaps on first use or after an update adds the tracking
   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.1 Expression Format

   When a user has enabled a tracking preference, that preference needs to be
   expressed to all mechanisms that might perform or initiate tracking by
   third parties, including sites that the user agent communicates with via
   HTTP, scripts that can extend behavior on pages, and plug-ins or
   extensions that might be installed and activated for various media types.

   When enabled, a tracking preference is expressed as either:

          DNT                        meaning                         
           1  This user prefers not to be tracked on the target      
              site.                                                  
           0  This user prefers to allow tracking on the target      
              site.                                                  

   A user agent MUST NOT send a tracking preference expression if a tracking
   preference is not enabled. This means that no expression is sent for each
   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.

   In the absence of regulatory, legal, or other requirements, servers MAY
   interpret the lack of an expressed tracking preference as they find most
   appropriate for the given user, particularly when considered in light of
   the user's privacy expectations and cultural circumstances. Likewise,
   servers might make use of other preference information outside the scope
   of this protocol, such as site-specific user preferences or third-party
   registration services, to inform or adjust their behavior when no explicit
   preference is expressed via this protocol.

  4.2 DNT Header Field for HTTP Requests

   The DNT header field is hereby defined as the means for expressing a
   user's tracking preference via HTTP [HTTP11].

 DNT-field-name  = "DNT"                          ; case-insensitive
 DNT-field-value = ( "0" / "1" ) *DNT-extension   ; case-sensitive
 DNT-extension   = %x21 / %x23-2B / %x2D-5B / %x5D-7E
                 ; excludes CTL, SP, DQUOTE, comma, backslash
        

   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
   DNT header field if a tracking preference is not enabled.

   The DNT field-value sent by a user agent MUST begin with the numeric
   character "1" (%x31) if a tracking preference is enabled, and the
   preference is for no tracking, and there is not a site-specific exception
   for the origin server targeted by this request.

   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
   preference is to allow tracking in general or by specific exception for
   the origin server targeted by this request.

   Example 1

 GET /something/here HTTP/1.1
 Host: example.com
 DNT: 1

   An HTTP intermediary MUST NOT add, delete, or modify the DNT header field
   in requests forwarded through that intermediary unless that intermediary
   has been specifically installed or configured to do so by the user making
   the requests. For example, an Internet Service Provider MUST NOT inject
   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
   reserved for future extensions. User agents that do not implement such
   extensions MUST NOT send DNT-extension characters in the DNT field-value.
   Servers that do not implement such extensions SHOULD ignore anything
   beyond the first character.

   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
   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
   understand the refinements defined by x, y, or z, then adjust my
   preferences according to those refinements. DNT extensions can only be
   transmitted when a tracking preference is enabled.

   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
   without further encoding (section 5.5.3 Representation). Since the DNT
   header field is intended to be sent on every request, when enabled,
   designers of future extensions ought to use as few extension characters as
   possible.

   Note

   This document does not have any implied or specified behavior for the
   user-agent treatment of cookies when DNT is enabled.

  4.3 JavaScript API to Detect Preference

   A doNotTrack attribute on the Navigator interface [NAVIGATOR] (e.g., the
   window.navigator object) is hereby defined as the means for expressing the
   user's general tracking preference to scripts running within a top-level
   page. A user agent MUST provide a doNotTrack attribute on the Navigator
   interface for each top-level page.

 partial interface Navigator {
     readonly attribute DOMString doNotTrack;
 };

   doNotTrack of type DOMString, readonly
           When a tracking preference is enabled, the doNotTrack attribute
           for each top-level page MUST have the same string value that would
           be sent in a DNT-field-value (section 4.2 DNT Header Field for
           HTTP Requests) to an origin server that does not have any
           corresponding user-granted exceptions. When a tracking preference
           is not enabled, the doNotTrack attribute for each top-level page
           MUST have a value of null.

   The doNotTrack attribute only provides the user's general tracking
   preference, independent of any user-granted exceptions or out-of-band
   consent. A script wishing to determine the specific tracking preference
   for a given document origin is expected to use the API in section 6.6
   Querying a host's exception status.

   A user agent MUST provide a doNotTrack attribute value that is consistent
   with the user's current tracking preference that would be expressed via
   the DNT header field. However, changes to the user's preference might
   occur between the time when the APIs are checked and an actual request is
   made. A server MUST treat the user's most recently received preference as
   authoritative.

   Issue 84: Make DNT status available to JavaScript

   [PENDING REVIEW] Updated text in this section.

   Issue 116: How can we build a JS DOM property which doesn't allow inline
   JS to receive mixed signals?

   [PENDING REVIEW] Updated text in this section.

  4.4 Plug-In APIs

   User agents often include user-installable component parts, commonly known
   as plug-ins or browser extensions, that are capable of making their own
   network requests. From the user's perspective, these components are
   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
   have read access to the browser configuration.

   Note

   It is unclear whether we need to standardize the plug-in APIs or if we
   should rely on it being defined per user agent based on general advice
   here. No plug-in APIs have been proposed yet.

  4.5 Tracking Preference Expressed in Other Protocols

   A user's tracking preference is intended to apply in general, regardless
   of the protocols being used for Internet communication. The protocol
   expressed here is specific to HTTP communication; however, the semantics
   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 specifications.

   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
   protocols are used. For example, redirecting to another protocol in order
   to avoid receipt of the header is not compliant.

   Note

   The last paragraph may be more appropriate in the compliance document, as
   it discusses compliance.

5. Communicating a Tracking Status

  5.1 Overview

   The primary goals of this protocol-expressing the user's preference and
   adhering to that preference-can be accomplished without any response from
   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.

   Unfortunately, providing a dynamic indication of tracking compliance on
   every HTTP response is not feasible, since it would have the effect of
   disabling caching for the entire Web. Instead, this protocol defines a
   combination of response mechanisms that allow the information to be
   communicated without making every response dynamic.

   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, and
   MAY direct the user to a request-specific tracking status resource
   applicable to the current request.

   Issue 120: Should the response header be mandatory (MUST) or recommended
   (SHOULD)

   [PENDING REVIEW] The site-wide resource is mandatory; the header field is
   optional, except for the single MUST case above.

   Issue 124: Alternative DNT implementations that replace HTTP headers with
   something else

   [PENDING REVIEW] The tracking status resource minimizes bandwidth usage
   because only a small proportion of user agents are expected to perform
   active verification, status would only be requested once per site per day,
   and the response can be extensively cached.

  5.2 Tracking Status Value

   A tracking status value is a short notation for communicating how a
   designated resource conforms to the tracking protection protocol, as
   defined by this document and [TRACKING-COMPLIANCE]. There is no form of
   negative response; i.e., an origin server that does not wish to claim
   conformance to this protocol would not supply a tracking status resource
   and would not send a Tk header field in responses.

   For a site-wide tracking status resource, the designated resource to which
   the tracking status applies is any resource on the same origin server. For
   a Tk response header field, the corresponding request target is the
   designated resource and remains so for any subsequent request-specific
   tracking status resource referred to by that field.

   All of the tracking status mechanisms use a common format for the tracking
   status value: a single character from a limited set. The meaning of each
   allowed character is defined in the following table.

          status                       meaning                        
            N    None: The designated resource does not perform       
                 tracking of any kind, not even for a permitted use,  
                 and does not make use of any data collected from     
                 tracking.                                            

            1    First party: The designated resource is designed for 
                 use within a first-party context and conforms to the 
                 requirements on a first party. If the designated     
                 resource is operated by an outsourced service        
                 provider, the service provider claims that it        
                 conforms to the requirements on a third party acting 
                 as a first party.                                    

            3    Third party: The designated resource is designed for 
                 use within a third-party context and conforms to the 
                 requirements on a third party.                       

            X    Dynamic: The designated resource is designed for use 
                 in both first and third-party contexts and           
                 dynamically adjusts tracking status accordingly. If  
                 X is present in the site-wide tracking status, more  
                 information MUST be provided via the Tk response     
                 header field when accessing a designated resource.   
                 If X is present in the Tk header field, more         
                 information will be provided in a request-specific   
                 tracking status resource referred to by the          
                 status-id. An origin server MUST NOT send X as the   
                 tracking status value in the representation of a     
                 request-specific tracking status resource.           

            C    Consent: The designated resource believes it has     
                 received prior consent for tracking this user, user  
                 agent, or device, perhaps via some mechanism not     
                 defined by this specification, and that prior        
                 consent overrides the tracking preference expressed  
                 by this protocol.                                    

            U    Updated: The request resulted in a potential change  
                 to the tracking status applicable to this user, user 
                 agent, or device. A user agent that relies on a      
                 cached tracking status SHOULD update the cache entry 
                 with the current status by making a new request on   
                 the applicable tracking status resource. An origin   
                 server MUST NOT send U as a tracking status value    
                 anywhere other than a Tk header field that is in     
                 response to a state-changing request.                

   For the site-wide tracking status and Tk header field, the tracking status
   values 1 and 3 indicate how the designated resource is designed to
   conform, not the nature of the request. Hence, if a user agent is making a
   request in what appears to be a third-party context and the tracking
   status value indicates that the designated resource is designed only for
   first-party conformance, then either the context has been misunderstood
   (both are actually the same party) or the resource has been referenced
   incorrectly. For the request-specific tracking status resource, an
   indication of first or third party as the status value describes how the
   resource conformed to that specific request, and thus indicates both the
   nature of the request (as viewed by the origin server) and the applicable
   set of requirements to which the origin server claims to conform.

   The tracking status value is case sensitive, as defined formally by the
   following ABNF.

 tracking-v    = "1"   ; "1" - first-party
               / "3"   ; "3" - third-party
               / %x43  ; "C" - consent
               / %x4E  ; "N" - none
               / %x55  ; "U" - updated
               / %x58  ; "X" - dynamic
        

   Issue 137: Does hybrid tracking status need to distinguish between first
   party (1) and outsourcing service provider acting as a first party (s)

   [PENDING REVIEW] No, in practice there may be dozens of service providers
   on any given request. If the designated resource is operated by a service
   provider acting as a first party, then the responsible first party is
   identified by the policy link or the owner of the origin server domain.
   This satisfies the use case of distinguishing between a service provider
   acting for some other site and the same service provider acting on one of
   its own sites.

  5.3 Tracking Status Qualifier Values

   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.

   Issue

   ISSUE-136: Resolve dependencies of the TPE on the compliance
   specification.
   The list of qualifiers is intended to match one to one to the permitted
   uses identified by [TRACKING-COMPLIANCE], using references to the
   definitions there. The list will then be updated accordingly.

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

   The tracking qualifier value is case sensitive, as defined formally by the
   following ABNF.

         tracking-q    = tracking-q-v*
         tracking-q-v  = %x61   ; "a" - audit
                           / %x63  ; "c" - capping
                           / %x66  ; "f" - fraud
                           / %x6C  ; "l" - local
                           / %x72  ; "r" - referral
                        

  5.4 Tk Header Field for HTTP Responses

    5.4.1 Definition

   The Tk response header field is hereby defined as an OPTIONAL means for
   indicating the tracking status that applied to the corresponding request
   and as a REQUIRED means for indicating that a state-changing request has
   resulted in an interactive change to the tracking status.

 Tk-field-name   =  "Tk"       ; case-insensitive
 Tk-field-value  =  tracking-v [tracking-q] [ ";" status-id ]
          

   The Tk field-value begins with a tracking status value (section 5.2
   Tracking Status Value), optionally followed by one or more tracking
   qualifiers (section 5.3 Tracking Status Qualifier Values), and then
   optionally a semicolon and a status-id that refers to a request-specific
   tracking status resource (section 5.4.2 Referring to a Request-specific
   Tracking Status Resource).

   For example, a Tk header field for a resource that claims not to be
   tracking would look like:

   Example 2

 Tk: N

   whereas a Tk header field for a resource that might perform tracking
   (though not necessarily for every request) and conforms to the third-party
   requirements of [TRACKING-COMPLIANCE], while claiming the audit exception,
   would look like:

   Example 3

 Tk: 3a

   Issue 107: Exact format of the response header?

   [PENDING REVIEW] See the proposal in this section.

    5.4.2 Referring to a Request-specific Tracking Status Resource

   If an origin server has multiple, request-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.

 status-id       =  1*id-char  ; case-sensitive
 id-char         =  ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
          

   For example, a response containing

   Example 4

 Tk: 1;fRx42

   indicates that the target resource claims to conform to the first-party
   requirements of [TRACKING-COMPLIANCE] and that an applicable tracking
   status representation can be obtained by performing a retrieval request on

 /.well-known/dnt/fRx42

   If a Tk field-value has a tracking status value of X (dynamic), then a
   status-id MUST be included in the field-value.

    5.4.3 Indicating an Interactive Status Change

   We anticipate that interactive mechanisms might be used, beyond the scope
   of this specification, that have the effect of asking for and obtaining
   prior consent for tracking, or for modifying prior indications of consent.
   For example, the tracking status resource's status-object defines a
   control member that can refer to such a mechanism. Although such
   out-of-band mechanisms are not defined by this specification, their
   presence might influence the tracking status object's response value.

   When an origin server provides a mechanism via HTTP for establishing or
   modifying out-of-band tracking preferences, the origin server MUST
   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 status value of U (updated).

   Example 5

 Tk: U

  5.5 Tracking Status Resource

    5.5.1 Site-wide Tracking Status

   An origin server MUST provide a site-wide tracking status resource at the
   well-known identifier [RFC5785]

 /.well-known/dnt

   (relative to the URI of that origin server) for obtaining information
   about the potential tracking behavior of resources provided by that origin
   server. A tracking status resource MAY be used for verification of DNT
   support, as described in section 5.7 Using the Tracking Status.

   A valid retrieval request (e.g., a GET in HTTP) on the well-known URI MUST
   result in either a successful response containing a machine-readable
   representation of the site-wide tracking status, as defined below, or a
   sequence of redirects that leads to such a representation. A user agent
   MAY consider failure to provide access to such a representation equivalent
   to the origin server not implementing this protocol. The representation
   MAY be cached, as described in section 5.5.5 Caching.

    5.5.2 Request-specific Tracking Status

   If an origin server has multiple, request-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 Tk response
   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.

   The tracking status resource space is defined by the following URI
   Template [URI-TEMPLATE]:

 /.well-known/dnt{/status-id}

   where the value of status-id is a string of URI-safe characters provided
   by a Tk field-value in response to a prior request. For example, a prior
   response containing

   Example 6

 Tk: 1;ahoy

   refers to the specific tracking status resource

 /.well-known/dnt/ahoy

   Resources within the request-specific tracking status resource space are
   represented using the same format as a site-wide tracking status resource.

    5.5.3 Representation

   The representation of a tracking status resource shall be provided in the
   "application/json" format [RFC4627] and MUST conform to the ABNF for
   status-object (except that the members within each member-list MAY be
   provided in any order).

   The following example tracking status representation illustrates all of
   the fields defined by this specification, most of which are optional.

   Example 7

 {
   "tracking": "1",
   "same-party": [
     "example.com",
     "example_vids.net",
     "example_stats.com"
   ],
   "third-party": [
     "api.example.net"
   ],
   "audit": [
     "http://auditor.example.org/727073"
   ],
   "policy": "/tracking.html",
   "control": "http://example.com/your/data"
 }

   A tracking status representation consists of a single status-object
   containing members that describe the tracking status applicable to the
   designated resource.

 status-object = begin-object member-list end-object

 member-list   = tracking         ns tracking-v [tracking-q]
                 [ vs same-party  ns same-party-v  ]
                 [ vs third-party ns third-party-v ]
                 [ vs audit       ns audit-v       ]
                 [ vs policy      ns policy-v      ]
                 [ vs control     ns control-v     ]
                 *( vs extension )
          

   A status-object MUST have a member named tracking that contains a single
   character tracking status value (section 5.2 Tracking Status Value),
   optionally followed by one or more tracking qualifiers (section 5.3
   Tracking Status Qualifier Values) .

 tracking      = %x22 "tracking" %x22
          

   For example, the following demonstrates a minimal tracking status
   representation that is applicable to any resource that does not perform
   tracking.

   Example 8

 {"tracking": "N"}

   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
   same party, to the extent they are referenced by the designated resource,
   since all data collected via those references share the same data
   controller.

 same-party    = %x22 "same-party" %x22
 same-party-v  = array-of-strings
          

   An OPTIONAL member named third-party MAY be provided with an array value
   containing a list of domain names for third-party services that might be
   invoked while using the designated resource but do not share the same data
   controller as the designated resource.

 third-party   = %x22 "third-party" %x22
 third-party-v = array-of-strings
          

   An OPTIONAL member named audit MAY be provided with an array value
   containing a list of URI references to external audits of the designated
   resource'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.

 audit         = %x22 "audit" %x22
 audit-v       = array-of-strings
          

   An OPTIONAL member named policy MAY be provided with a string value
   containing a URI-reference to a human-readable document that describes the
   tracking policy for the designated resource. The content of such a policy
   document is beyond the scope of this protocol and only supplemental to
   what is described by this machine-readable tracking status representation.

 policy        = %x22 "policy" %x22
 policy-v      = string       ; URI-reference
          

   If the tracking status value is 1 and the designated resource is being
   operated by an outsourced service provider on behalf of a first party, the
   origin server MUST identify the responsible first party via the domain of
   the policy URI, if present, or by the domain owner of the origin server.
   If no policy URI is provided and the origin server domain is owned by the
   service provider, then the service provider is the first party.

   An OPTIONAL member named control MAY be provided with a string value
   containing a URI-reference to a resource for giving the user control over
   personal data collected by the designated resource (and possibly other
   resources); a control member SHOULD be provided if the tracking status
   value indicates prior consent (C). Such a control resource might include
   the ability to review past data collected, delete some or all of the data,
   provide additional data (if desired), or opt-in, opt-out, or otherwise
   modify an out-of-band consent status regarding data collection. The design
   of such a resource, the extent to which it can provide access to that
   data, and how one might implement an out-of-band consent mechanism is
   beyond the scope of this protocol.

 control       = %x22 "control" %x22
 control-v     = string       ; URI-reference
          

   Additional extension members MAY be provided in the status-object to
   support future enhancements to this protocol. A user agent SHOULD ignore
   extension members that it does not recognize.

 extension     = object

 array-of-strings = begin-array
                    [ string *( vs string ) ]
                    end-array

 ns            = <name-separator  (:), as defined in [[!RFC4627]]>
 vs            = <value-separator (,), as defined in [[!RFC4627]]>

 begin-array   = <begin-array     ([), as defined in [[!RFC4627]]>
 end-array     = <end-array       (]), as defined in [[!RFC4627]]>
 begin-object  = <begin-object    ({), as defined in [[!RFC4627]]>
 end-object    = <end-object      (}), as defined in [[!RFC4627]]>
 object        = <object, as defined in [[!RFC4627]]>
 string        = <string, as defined in [[!RFC4627]]>
 true          = <true,   as defined in [[!RFC4627]]>
 false         = <false,  as defined in [[!RFC4627]]>
 null          = <null,   as defined in [[!RFC4627]]>
          

   Note that the tracking status resource space applies equally to both
   first-party and third-party services. An example of a third-party tracking
   status is

   Example 9

 {
   "tracking": "3",
   "policy": "/privacy.html",
   "control": "/your/data",
 }

   Issue 47: Should the response from the server indicate a policy that
   describes the DNT practices of the server?

   [PENDING REVIEW] The tracking status resource is a machine-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
   associated with them

   [PENDING REVIEW] The same-party and third-party members provide a means to
   list first-party and third-party domains, respectively.

    5.5.4 Status Checks are Not Tracked

   When sending a request for the tracking status, a user agent SHOULD
   include any cookie data [COOKIES] (set prior to the request) that would be
   sent in a normal request to that origin server, since that data might be
   needed by the server to determine the current tracking status. For
   example, the cookie data might indicate a prior out-of-band decision by
   the user to opt-out or consent to tracking by that origin server.

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

   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
   response SHOULD be marked as cacheable and assigned a time-to-live
   (expiration or max-use) that is sufficient to enable shared caching but
   not greater than the earliest point at which the service's tracking
   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
   service's tracking behavior can be increased is seven days after the
   policy has been updated to reflect the new behavior, since old copies
   might persist in caches until the expiration is triggered. A service's
   tracking behavior can be reduced at any time, with or without a
   corresponding change to the tracking status resource.

   If the tracking status is only applicable to all users that have the same
   DNT-field-value, then the response MUST either be marked with a Vary
   header field that includes "DNT" in its field-value or marked as not
   reusable by a shared cache without revalidation with a Cache-Control
   header field containing one of the following directives: "private",
   "no-cache", "no-store", or "max-age=0".

   If the tracking status is only applicable to the specific user that
   requested it, then the response MUST include a Cache-Control header field
   containing one of the following directives: "private", "no-cache", or
   "no-store".

   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
   most). A public Internet site that intends to change its tracking status
   to increase tracking behavior MUST update the tracking status resource in
   accordance with that planned behavior at least twenty-four hours prior to
   activating that new behavior on the service.

   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 U tracking status value, as
   described in section 5.4.3 Indicating an Interactive Status Change.

  5.6 Status Code for Tracking Required

   If an origin server receives a request with DNT:1, does not have
   out-of-band consent for tracking this user, and wishes to deny access to
   the requested resource until the user provides some form of user-granted
   exception or consent for tracking, then the origin server SHOULD send an
   HTTP error response with a status code of 409 (Conflict) and a message
   body that describes why the request has been refused and how one might
   supply the required consent or exception to avoid this conflict [HTTP11].

   The 409 response SHOULD include a user authentication mechanism in the
   header fields and/or message body if user login is one of the ways through
   which access is granted.

   Issue 128: HTTP error status code to signal that tracking is required?

   [PENDING REVIEW] As defined by this section.

  5.7 Using the Tracking Status

   Note

   This section is for collecting use cases that describe questions a user
   agent might have about tracking status and how the protocol can be used to
   answer such questions. More cases are needed.

    5.7.1 Discovering Deployment

   The presence of a site-wide tracking status representation is a claim that
   the service conforms to this protocol for a given user agent. Hence,
   deployment of this protocol for a given service can be discovered by
   making a retrieval request on the site-wide tracking resource
   /.well-known/dnt relative to the service URI.

   If the response is an error, then the service does not implement this
   standard. If the response is a redirect, then follow the redirect to
   obtain the tracking status (up to some reasonable maximum of redirects to
   avoid misconfigured infinite request loops). If the response is
   successful, obtain the tracking status representation from the message
   payload, if possible, or consider it an error.

    5.7.2 Preflight Checks

   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
   reviewed prior to making use of those services and prior to making
   requests on third-party resources referenced by those services.

   A user agent MAY check the tracking status for a designated resource by
   first making a retrieval request for the site-wide tracking status
   representation, as described above, and then parsing the representation as
   JSON to extract the Javascript status-object. If retrieval is unsuccessful
   or parsing results in a syntax error, the user agent SHOULD consider the
   site to be non-conformant with this protocol.

   The status-object is supposed to have a member named tracking containing
   the tracking status value. The meaning of each tracking status value is
   defined in section 5.2 Tracking Status Value.

   If the tracking status value is N, then the origin server claims that no
   tracking is performed for the designated resource for at least the next 24
   hours or until the Cache-Control information indicates that this response
   expires.

   If the tracking status value is not N, then the origin server claims that
   it might track the user agent for requests on the URI being checked for at
   least the next 24 hours or until the Cache-Control information indicates
   that this response expires.

6. User-Granted Exceptions

  6.1 Overview

   This section is non-normative.

   User-granted exceptions to Do Not Track, including site-specific
   exceptions, are managed by the user agent. A resource should rely on the
   DNT header it receives to determine the user's preference for tracking
   with respect to that particular request. An API is provided so that sites
   may request and check the status of exceptions for tracking.

   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
   specifics - for granting, configuring, storing, syncing and revoking
   exceptions - are explicitly left open to implementers.

   Issue 144: What constraints on user agents should be imposed for
   user/granted exceptions

   [OPEN] but mostly addressed in the proposal here.

  6.2 Motivating Principles and Use Cases

   This section is non-normative.

   The following principles guide the design of user-agent-managed
   exceptions.

     * Content providers may wish to prompt visitors to their properties to
       opt back in to tracking for behavioral advertising or similar purposes
       when they arrive with the Do Not Track setting enabled.
     * Privacy-conscious users may wish to view or edit all the exceptions
       they've granted in a single, consistent user interface, rather than
       managing preferences in a different way on every content provider or
       tracker's privacy page.
     * Granting an exception in one context (while browsing a news site)
       should not apply that exception to other contexts (browsing a medical
       site) that may not be expected.
     * Tracking providers should not ever have to second-guess a user's
       expressed Do Not Track preference.
     * The solution should not require cross-domain communication between a
       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 conceptual 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.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
   site, and the target. A user might - for instance - want AnalytiCo to be
   allowed to track them on Example News, but not on Example Medical. To
   simplify language used in this API specification, we define three terms:

     * Top-Level Domain (TLD) is the domain name of the top-level document
       origin of this DOM: essentially the fully qualified domain name in the
       address bar.
     * A target site is a domain name which is the target of an HTTP request,
       and which may be an origin for embedded resources on the indicated
       top-level domain.
     * The document origin of a script is the domain of origin of the
       document that caused that script to be loaded (not necessarily the
       same as the origin of the script itself).

   For instance, if the document at
   http://web.exnews.com/news/story/2098373.html references the resources
   http://exnews.analytico.net/1x1.gif and
   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
   targets.

   Issue 112: How are sub-domains handled for site-specific exceptions?

   [PENDING REVIEW] 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 the subdomains that it's asking for? Similarly, should
   third-party subdomains be allowed (e.g. *.tracker.com)?
   Proposal: Exceptions are requested for fully-qualified domain names.

   The domains that enter into the behavior of the APIs include:

     * As described above, the document origin active at the time of the
       call, and;
     * Domain names passed to the API.

   Domains that enter into the decision over what DNT header to be sent in a
   given HTTP request include:

     * The top-level domain of the current context;
     * The target of the HTTP request.
   Note

   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.

   The calls cause the following steps to occur:

     * First, the UA somehow confirms with the user that they agree to the
       grant of exception, if not already granted;
     * If they agree, then the UA adds to its local database one or more
       site-pair duplets [document-origin, target]; 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.
   Note

   Note that a site may record no that it has previously asked for, and been
   denied, an exception, if it wishes to avoid repeatedly asking the user for
   an exception.

    6.3.2 Exception use by browsers

   If a user agrees to allow tracking by a target on the top-level domain,
   this should result in two user-agent behaviors:

    1. If requests to the target for resources that are part of the DOM for
       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
       this user preference (see below).
   Issue 158: What is the effect of re-directs for content on the operation
   of exceptions?

   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?
   Proposal: The re-direct is not relevant; each site gets the DNT header
   controlled by the list of grants.

   Issue 159: How do we allow sites that mash-in add-supported content to
   maintain their own trusted third parties?

   This model does not support mashed-up content which is in turn supported
   by ads; it's not clear how to distinguish between embedded content which
   is embedding ads (and hence the top-level domain stays the same) and
   embedded content that should start a new context.
   Proposal: For this version of the specification, we don't address this
   corner case.

   User-agents MUST handle each API request as a 'unit', granting and
   maintaining it in its entirety, or not at all. That means that a
   user-agent MUST NOT indicate to a site that a request for targets {a, b,
   c} has been granted, and later remove only one or two of {a, b, c} from
   its logical database of remembered grants. This assures sites that the set
   of sites they need for operational integrity is treated as a unit. Each
   separate call to an API is a separate unit.

   When a user-agent receives an API request for an exception that already
   exists (i.e. the grant is recorded in its database), it SHOULD bypass
   asking the user to confirm, and simply re-confirm the grant to the caller.

   Note

   It is left up to individual user-agent implementations how to determine
   and how and whether to store users' tracking preferences.

   When an explicit list of domains is provided through the API, 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; or the user-agent may
   decide to ask the user for a site-wide exception, effectively ignoring the
   list of domain names, if supplied.

   Conversely, if a wild-card is 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

   [POSTPONED] Should the user agent send a different DNT value to a first
   party site if 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 parties while browsing this domain")
   Proposal: A previous proposal was that it can add itself to the list (i.e.
   an exception for [site, site]) and then it will get DNT:0, but DNT:0 to a
   first party means something different (that it can pass data to third
   parties, and tracking is permitted). It would be better to have an
   indication in the DNT header that one or more site-specific exceptions
   exist for the given target (i.e. that there is at least one duplet in the
   database with target as its first host name), for example "DNT:1E" where E
   means you are a first party with one or more active exceptions.

  6.4 JavaScript API for Site-specific Exceptions

    6.4.1 API to request site-specific exceptions

 [NoInterfaceObject]
 interface NavigatorDoNotTrack {
     void requestSiteSpecificTrackingException (TrackingResponseCallback callback, optional sequence<DOMString> arrayOfDomainStrings, optional optional siteName, optional optional explanationString, optional optional detailURI);
 };

   requestSiteSpecificTrackingException
           Called by a page to request or confirm a user-granted tracking
           exception.

          Parameter                 Type           Nullable Optional Description 
     callback             TrackingResponseCallback *        *        
     arrayOfDomainStrings sequence<DOMString>      *        *        
     siteName             optional                 *        *        
     explanationString    optional                 *        *        
     detailURI            optional                 *        *        

           Return type: void

 [Callback, NoInterfaceObject]
 interface TrackingResponseCallback {
     void handleEvent (integer granted);
 };

   handleEvent
           The callback is called by the user agent to indicate the user's
           response.

           Parameter  Type   Nullable Optional Description 
           granted   integer *        *        

           Return type: void

   The requestSiteSpecificTrackingException method takes one mandatory
   argument:

     * callback, a method that will be called when the request is complete.

   It also takes four optional arguments:

     * arrayOfDomainStrings, a JavaScript array of strings,
     * siteName, a user-readable string for the name of the top-level domain,
     * explanationString, a short explanation of the request, and
     * detailURI, a location at which further information about this request
       can be found.

   If the request does not include the arrayOfDomainStrings, then this
   request is for a site-wide exception. Otherwise each string in
   arrayOfDomainStrings specifies a target. When called,
   requestSiteSpecificTrackingException MUST return immediately, then
   asynchronously determine whether the user grants the requested
   exception(s).

   If the list arrayOfDomainStrings is supplied, the user-agent MAY choose to
   ask the user to grant a site-wide exception. If it does so, and the user
   agrees, it MUST indicate this in the response callback.

   The execution of this API and the use of the resulting permission (if
   granted) use the 'implicit' parameter, when the API is called, the
   document origin. This forms the first part of the duplet in the logical
   model, and hence in operation will be compared with the top-level domain.

   The granted parameter passed to the callback is the user's response; The
   response

     * 0 indicates that user does not grant the exception on top-level domain
       for the indicated targets.
     * 1 indicates that the request was for specific targets and the the user
       grants an exception on top-level domain for those specific targets.
     * 2 indicates the user grants a site-wide exception on top-level domain
       for all targets; the request may have been for specific targets or for
       a site-wide exception.

   If permission is granted for an explicit list, then the set of duplets
   (one per target):

 [document-origin, target]

   is added to the database of remembered grants.

   If permission is granted for a site-wide exception, then the duplets:

 [document-origin, * ]

   is added to the database of remembered grants.

   A particular response to the API - like a DNT response header - is only
   valid immediately, and users' preferences may change.

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

    6.4.2 API to Cancel a Site-specific Exception

 [NoInterfaceObject]
 interface NavigatorDoNotTrack {
     boolean removeSiteSpecificTrackingException ();
 };

   removeSiteSpecificTrackingException
           Ensures that the database of remembered grants no longer contains
           any duplets for which the first part is the current document
           origin; i.e., no duplets [document-origin, target] for any target.
           There is no callback. After the call has been made, it is assured
           that there are no site-specific or site-wide exceptions for the
           given top-level-domain.
           No parameters.
           Return type: boolean

   This returns a boolean indicating, when true, that the call has succeeded,
   and that the database of grants no longer contains, or very soon will no
   longer contain, the indicated grant(s); when false, some kind of
   processing error occurred.

  6.5 JavaScript API for Web-wide Exceptions

    6.5.1 API to Request a Web-wide Exception

 [NoInterfaceObject]
 interface NavigatorDoNotTrack {
     void requestWebWideTrackingException (TrackingResponseCallback callback, optional  siteName, optional optional explanationString, optional optional detailURI);
 };

   requestWebWideTrackingException
           If permission is granted, then the single duplet [ * ,
           document-origin] 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 optional                 *        *        
        detailURI         optional                 *        *        

           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 {
     boolean removeWebWideTrackingException ();
 };

   removeWebWideTrackingException
           Ensures that the database of remembered grants no longer contains
           the duplet [ * , document-origin]. 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: boolean

   This returns a boolean indicating, when true, that the call has succeeded,
   and that the database of grants no longer contains, or very soon will no
   longer contain, the indicated grant; when false, some kind of processing
   error occurred.

  6.6 Querying a host's exception status

   Issue 160: Do we need an exception-query API?

   It might be useful, and 'complete the model', if we had a JS API that told
   a host what its current exception status is in a given context.
   Proposal: Specifically, an API QueryExceptionStatus() which examines the
   document origin of the script, the current top-level domain and returns an
   empty string if no DNT header would be sent to that document origin, or
   the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.

 [NoInterfaceObject]
 interface NavigatorDoNotTrack {
     DOMString requestDNTStatus ();
 };

   requestDNTStatus
           Returns the same string value that would be sent in a
           DNT-field-value (section 4.2 DNT Header Field for HTTP Requests)
           to a target that is the document-origin of the request, in the
           context of the current top-level domain. If no DNT header would be
           sent (e.g. because a tracking preference is not enabled) the
           return value is null.
           No parameters.
           Return type: DOMString

  6.7 Transfer of an exception to another third party

   A site may request an exception for one or more third party services used
   in conjunction with its own offer. Those third party services may wish to
   use other third parties to complete the request in a chain of
   interactions. The first party will not necessarily know in advance whether
   a known third party will use some other third parties.

   If a user-agent sends a tracking exception to a given combination of
   origin server and a named third party, the user agent will send DNT:0 to
   that named third party. By receiving the DNT:0 header, the named third
   party acquires the permission to track the user agent and collect the data
   and process it in any way allowed by the legal system it is operating in.

   Furthermore, the named third party receiving the DNT:0 header acquires at
   least the right to collect data and process it for the given interaction
   and any secondary use unless it receives a DNT:1 header from that
   particular identified user agent.

   The named third party is also allowed to transmit the collected data for
   uses related to this interaction to its own sub-services and
   sub-sub-services (transitive permission). The tracking permission request
   triggered by the origin server is thus granted to the named third party
   and its sub-services. This is even true for sub-services that would
   normally receive a DNT:1 web-wide preference from the user-agent if the
   user agent interacted with this service directly.

   For advertisement networks this typically would mean that the collection
   and auction system chain can use the data for that interaction and combine
   it with existing profiles and data. The sub-services to the named third
   party do not acquire an independent right to process the data for
   independent secondary uses unless they, themselves, receive a DNT:0 header
   from the user agent (as a result of their own request or the request of a
   first-party). In our example of advertisement networks that means the
   sub-services can use existing profiles in combination with the data
   received, but they can not store the received information into a profile
   until they have received a DNT:0 of their own.

   A named third party acquiring an exception with this mechanism MUST make
   sure that sub-services it uses acknowledge this constraint by requiring
   the use of the appropriate tracking status value and qualifier, which is
   "XX" (such as "tl"), from its sub-sub-services.

   The permission acquired by the DNT mechanism does not override retention
   limitations found in the legal system the content provider or the named
   third party are operating in.

   Issue

   When the status values and qualifiers are fixed, the penultimate paragraph
   will probably need adjusting to match. The use of "tl" (which meant
   "tracking but only in accordance with local laws" when this text was
   written) doesn't seem right, as the text talks, essentially, of the
   sub-sub-service acting on behalf of the site that received the DNT:0
   header, which might suggest something more like "CS" (service provision to
   a third-party that received consent).

  6.8 User interface guidelines

   This section is non-normative.

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

   In general, it is expected that the site will explain, in its online
   content, the need for an exception, and the consequences of granting or
   denying an exception, to the user, and guide. The call to the API and the
   resulting request for user confirmation should not be a 'surprise' to the
   user, or require much explanation on the part of the user-agent.

   A user agent that chooses to implement a prompt to present tracking
   exception requests to the user might provide an interface like the
   following:

   Example 10

 Example News (web.exnews.com) would like to confirm
 that you permit tracking by a specific set of sites (click
 here for their names).

 Example News says:
   These sites allow Example News to see how we're
   doing, and provide useful features of the Example News
   experience.     [More info]

 [Allow Tracking]  [Deny Tracking Request]

   In this example, the domains listed are those specified in
   arrayOfDomainStrings, the phrase Example News is from siteName, and the
   explanationString is displayed for the user with a More info link pointing
   to detailURI.

   The user agent might then store that decision, and answer future requests
   based on this stored preference. A user agent might provide the user with
   an interface to explicitly remove (or add) user-granted exceptions.

   Users might not configure their agents to have simple values for DNT, but
   use different browsing modes or other contextual information to decide on
   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.

   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
   users of the device. Thus, exceptions may not always represent the current
   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
   control these preferences. Users may desire options to edit exceptions
   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
   without visiting that site.

   Issue 140: Do we need site-specific exceptions, i.e., concrete list of
   permitted third parties for a site?

   [PENDING REVIEW]: 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. But all sites are (a) told what they got
   granted (list, or *) and (b) are assured that requests will be treated
   'atomically'.

  6.9 Exceptions without a DNT header

   Sites might wish to request exceptions even when a user arrives without a
   DNT header. Users might wish to grant affirmative permission to tracking
   on or by certain sites even without expressing general tracking
   preferences.

   User agents MAY instantiate
   NavigatorDoNotTrack.requestSiteSpecificTrackingException even when
   navigator.doNotTrack is null. Sites SHOULD test for the existence of
   requestSiteSpecificTrackingException before calling the method. If an
   exception is granted in this context and the user-agent stores that
   preference, a user agent may send a DNT:0 header even if a tracking
   preference isn't expressed for other requests. Persisted preferences MAY
   also affect which header is transmitted if a user later chooses to express
   a tracking preference.

   Note

   Users might not configure their agents to have simple values for DNT, but
   use different browsing modes or other contextual information to decide on
   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.

  6.10 Fingerprinting

   By storing a client-side configurable state and providing functionality to
   learn about it later, this API might facilitate user fingerprinting and
   tracking. User agent developers ought to consider the possibility of
   fingerprinting during implementation and might consider rate-limiting
   requests or using other heuristics to mitigate fingerprinting risk. User
   agents SHOULD clear stored user-granted exceptions when the user chooses
   to clear cookies or other client-side state.

A. Acknowledgements

   This specification consists of input from many discussions within and
   around the W3C Tracking Protection Working Group, along with written
   contributions from Nick Doty (W3C/MIT), Rob van Eijk (Invited Expert),
   Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Jonathan Mayer
   (Stanford), Aleecia M. McDonald (Mozilla), Matthias Schunter (IBM),
   John Simpson (Consumer Watchdog), 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
   Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm
   (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web
   Tracking Protection submission by Andy Zeigler, Adrian Bateman, and
   Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.

B. References

  B.1 Normative references

   [ABNF]
           D. Crocker and P. Overell. Augmented BNF for Syntax
           Specifications: ABNF. January 2008. Internet RFC 5234. URL:
           http://www.ietf.org/rfc/rfc5234.txt

   [HTTP11]
           R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June
           1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt

   [NAVIGATOR]
           Ian Hickson, David Hyatt. Navigator interface in HTML5. 15 April
           2011. Editors' draft. (Work in progress.) URL:
           http://dev.w3.org/html5/spec/timers.html#navigator

   [RFC2119]
           S. Bradner. Key words for use in RFCs to Indicate Requirement
           Levels. March 1997. Internet RFC 2119. URL:
           http://www.ietf.org/rfc/rfc2119.txt

   [RFC4627]
           D. Crockford. The application/json Media Type for JavaScript
           Object Notation (JSON) July 2006. Internet RFC 4627. URL:
           http://www.ietf.org/rfc/rfc4627.txt

   [TRACKING-COMPLIANCE]
           Justin Brookman; Sean Harvey; Erica Newland; Heather West.
           Tracking Compliance and Scope. 13 March 2012. W3C Working Draft.
           (Work in progress.) URL:
           http://www.w3.org/TR/2012/WD-tracking-compliance-20120313/

   [WEBIDL]
           Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft.
           (Work in progress.) URL:
           http://www.w3.org/TR/2011/WD-WebIDL-20110927/

  B.2 Informative references

   [COOKIES]
           Adam Barth. HTTP State Management Mechanism. April 2011. Internet
           Proposed Standard RFC 6265. URL:
           http://www.rfc-editor.org/rfc/rfc6265.txt

   [KnowPrivacy]
           Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June
           2009. URL:
           http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf

   [RFC5785]
           Mark Nottingham; Eran Hammer-Lahav. Defining Well-Known Uniform
           Resource Identifiers (URIs). April 2010. Internet Proposed
           Standard RFC 5785. URL: http://www.rfc-editor.org/rfc/rfc5785.txt

   [URI-TEMPLATE]
           Joe Gregorio; Roy T. Fielding; Marc Hadley; Mark Nottingham; David
           Orchard. URI Template. March 2012. Internet RFC 6570. URL:
           http://www.rfc-editor.org/rfc/rfc6570.txt
Received on Thursday, 20 September 2012 07:24:37 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:34 UTC