**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 response.
ISSUE: Will all implementers, including browser extensions, be able to determine the corresponding top-level-origin for all outgoing requests?**Proposal** Resolved.
ISSUE: 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.
## Overview 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.
### Motivating principles and use casesThis section is not normative.
* Content providers may wish to prompt visitors to their sites to "opt back in" to tracking for behavioral advertising or similar purposes when they arrive with DNT:ON. * Privacy-conscious users may desire in one place with a consistant inteface for viewing and editing all the site-specific exceptions they've granted, 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 party trackers. ## Exception model ### Site pairs This API considers exceptions which are double-keyed to two domains: the **site**, and the **tracker**. A user might -- for instance -- want AnalytiCo to track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define two terms: - **This site** is the domain name of the top-level document origin of this DOM: essentially the fully qualified domain name in the address bar. - A **tracker** is a domain name which is not operated by the same party which operates **this site**, and which may be an origin for embedded resources on **this site**.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` **this site** is `web.exnews.com` and `exnews.analytico.net` and `widgets.exsocial.org` are both **tracker**s.
### Exception use by browsers If a user wishes to be tracked by a **tracker** on **this site**, this should result in two user-agent behaviors: 1. If requests to the **tracker** for resources that are part of the DOM for pages on **this site** include a DNT header, that header MUST be DNT:OFF. 2. Responses to the JavaScript API indicated should be consistent with this user preference (see below).It is left up to individual user-agent implementations how to determine and how and whether to store users' tracking preferences.
## Technical design: JavaScript API for site-specific exceptionsThis 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. 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 News (`web.exnews.com`) would like to know whether you permit tracking by the following parties: * `exnews.analytico.net` * `widgets.exsocial.org` 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. User agents might provide users with granular choice over which tracking origins are granted site-specific 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 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. ISSUE: Should there be a normative requirement for the existence of a revocation mechanism? (raised by npdoty) ### Notes for sites 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.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.
### 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. ### Web-wide exceptions _This section is non-normative._ Users may wish to configure exceptions for a certain trusted **tracker** across several or all **site**s. 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. ### Fingerprinting By storing a client-side configurable state and providing functionality to learn about it later, this API may facilitate user fingerprinting and tracking. User agent developers should consider the possibility of fingerprinting during implementation and might consider rate limiting requests or using other heuristics to mitigate fingerprinting risk. User agents should consider clearing stored site-specific exceptions when the user chooses to clear cookies or other client-side state. ISSUE-114: Guidance or mitigation of fingerprinting risk for user-agent-managed site-specific tracking exceptions **Proposal**: Above text provides guidance for user agent developers.