ACTION-31: Write up a proposal for a user-agent-managed site-specific exception from Shane Wiley on 2011-12-19 (public-tracking@w3.org from December 2011)

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Sun, 18 Dec 2011 22:45:45 -0800
To: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D06499378@SP2-EX07VS02.ds.corp.yahoo.com>

(Thank you to Nick Doty for leading the drafting of this language and to the rest of the team to helping mature the debate to this point. There are still open areas for discussion but hopefully this advances the conversation meaningfully.)

# USER-AGENT-MANAGED SITE-SPECIFIC EXCEPTIONS

## Overview

In this proposal, exceptions to Do Not Track, including site-specific exceptions and web-wide exceptions, are managed by the user agent. A resource should only depend on the DNT header it receives to determine the user's preference for tracking with respect to that request. An API is provided so that sites may prompt the user (via the user agent) to request a site-specific (or possibly Web-wide) exception for tracking, and check the current state of exceptions for that site.

Questions of user interface specifics -- for granting, configuring, storing, syncing and revoking exceptions -- are left open to implementers.

Open issues are listed inline below, including: are multiple DNT states necessary? Should there be a JavaScript-accessible list of exceptions? Should exceptions automatically include all sub-domains? What are the impacts on fingerprinting and how can they be mitigated?

## Motivating principles and use cases

Content providers may wish to prompt visitors to their properties who have enabled their DNT signal to grant an exception to allow tracking for behavioral advertising or similar purposes.

Privacy-conscious users may wish to view or clear all the site-specific exceptions they've granted simultaneously, 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.

## Technical design

### JavaScript API to prompt for exceptions

<code>
// TODO: this needs to be converted to complete and proper WebIDL
interface NavigatorDoNotTrack {
boolean requestSiteSpecificTrackingException(in arrayOfDomainStrings);
// returns true if the user granted all of the exceptions, false if any exceptions were not granted

readonly string[] siteSpecificTrackingExceptions;
// a list of domains granted tracking exceptions for this site
}
</code>

<code>requestSiteSpecificTrackingException</code> takes one argument, <code>arrayOfDomainStrings</code> a JavaScript array of strings. Each string specifies a document origin of a tracking element used by the site invoking this function. The special string "*" signifies all document origins.

User agents MUST provide a user interface prompting the user to choose whether to provide site-specific exceptions to Do Not Track for the requested origins, or, if pre-configured to accept or reject these permissions, respond with the user's previously configured preference. The user interface SHOULD include the domains included in <code>arrayOfDomainStrings</code> and MAY include additional metadata about those domains (included EV certificate information, historical data, human-readable descriptions of the tracker and its purpose, links to privacy policies, etc.). The user agent SHOULD express to the user that the exception will cover tracking done by each tracker while the user is browsing the current first party (as defined by the Compliance document).

<code>siteSpecificTrackingExceptions</code> is a read-only list of strings, each specifying a domain granted a site-specific tracking exception (by previous calls to <code>requestSiteSpecificTrackingException</code> or through browser configuration). A first party may query this property to determine whether to request additional exceptions; a third party may query this property to determine whether Do Not Track applies to its domain. ISSUE: This list property enables even easier fingerprinting by any first or third party JavaScript. Could first parties instead rely on calling requestSiteSpecificTrackingException and receiving a "true" response if exceptions have already been granted?

#### Example
(_This section is non-normative._)

> The New York Times (http://nytimes.com) requests that you allow tracking by the following parties:
>> * analytics.nytimes.com<http://analytics.nytimes.com>
>> * adserver.example.com<http://adserver.example.com>

> If you agree, you opt in to tracking by these parties while browsing nytimes.com<http://nytimes.com>.
[[Allow]] [[Deny]]

----

The user agent MAY provide users with granular choice over which tracking origins are granted site-specific exceptions and which are not (using checkboxes, for example). The user agent MUST store granted site-specific exceptions in the form of a pair (document origin of the top-level document, site-specific-exception document-origin). If the user has agreed to grant all of the requested site-specific exceptions, then the user agent MUST return <code>true</code> to the <code>requestSiteSpecificTrackingException</code> call, otherwise it must return <code>false</code>.

User agents MAY automatically clear site-specific exceptions after a period of time or in response to user activity. User agents MUST provide the user with an interface to explicitly revoke site-specific exceptions.

### Behavior for future requests with site-specific exceptions

ISSUE: 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 implies "I have Do Not Track enabled but grant permissions to some third parties while browsing this domain")

When Do Not Track is enabled and an HTTP request is about to be made, the user agent MUST first check the list of valid site-specific exceptions if one exists. Let top-level-origin be the document origin of the top-level document (e.g. the domain of the Web page explicitly requested by the user in the URL bar) and other-origin be the document origin of other resources on the page that are fetched in the course of loading and displaying the requested page. Let top-level-parents be all domains that include top-level-origin as a sub-domain. If the pair (top-level-origin, "*") or any of (top-level-parents, "*") is present in the site-specific exceptions list, the user agent MUST send DNT:0. For each other-origin and each top-level-parent, if the pair (top-level-origin, other-origin) or (top-level-parent, other-origin) is present in the site-specific exceptions list, the user agent MUST send DNT:0, otherwise, it MUST send DNT:1.

ISSUE: Will all implementers, including browser extensions, be able to determine the corresponding top-level-origin for all outgoing requests?

ISSUE: Should a request for a tracking exception apply to all sub-domains of the first party making the request? Or should a first party explicitly list the sub-domains that it's asking for? Similarly, should third party sub-domains be allowed (e.g. *.tracker.com)?

Discussion: Listing parent domains is more interesting than listing sub-domains and in the NYTimes example, "blogs.nytimes.com" is in fact a parent domain of www.nytimes.com. So it might be more interesting to ask the user directly if he want to grant exceptions for the domain www.nytimes.com or for "*.nytimes.com". The user agent could show to the user the list of parent domains that have been granted an exception when requesting exceptions for a new domain.

### Web-wide exceptions

Users may also 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: Is a JavaScript prompt for cross-Web tracking useful or necessary? If so, it might look something like this
<code>boolean requestTrackingException(string trackingDomain);</code>

User agents should take care in communicating the breadth of a Web-wide exception to the user's Do Not Track preference.

### User interface guidelines
_This section is non-normative._

Implementers should keep in mind that decisions may have been made in the past (and since forgotten) or by other users of the device and thus exceptions may not always represent the current preferences of the user. Where possible, a user agent should provide ambient notice to the user that tracking is ongoing that the user has opted into. Users should be given options to revoke tracking site-specific exceptions both at the time of tracking and in a separate user interface which does not require the user to visit a site she may not trust in order to revoke permissions to that tracking site.

### Fingerprinting concerns

By storing a client-side configurable state and providing functionality to query it later, this functionality may enable user fingerprinting and user tracking.

ISSUE: guidance on how to minimize fingerprinting risk is needed here.

### More Examples

No Site-Specific-Exception

- User arrives at PublisherXYZ

- Publisher received DNT=1 and calls requestSpecificTrackingExceptions

- The user is prompted to grant site-specific-exceptions but only grant some of them,

- The requestSpecificTrackingExceptions function returns false and siteSpecificTrackingException is called to send the list of rejected domains.

- If some key domains are not granted an exception, the publisher may insist and call again requestSpecificTrackingExceptions with a reduced list of domains.

- The publisher receives the list of exception

- 3rd parties that have not been granted an exception receive DNT=1

Site-Specific-Exception Exists