REVISED Actions 176 (and dup. 183), also merged Shane's text and added Remove APIs

In response to 
<https://www.w3.org/2011/tracking-protection/track/actions/176>
and
<https://www.w3.org/2011/tracking-protection/track/actions/183>

which seem to be the same, so we closed 183.

I think that this discussion and approach addresses the concerns and ideas expressed by Nick, Matthias, and Ian, at least; they may, of course, disagree.

I have merged the result of Shane's email and discussion, and also the removal API.  I suppose a well-designed site that has pages to interact with users in the process of requesting exceptions may also have a section where the users can indicate "I changed my mind", or there may be sites that decide they no longer wish or need the exception extended to some specific 3rd parties. However, I would expect users would want to interact with their user-agent to be sure that they have removed exceptions that they no longer wish to grant; and that the number of sites wanting to do the clean-up will be small.  However, the API is harmless and makes the suite complete and symmetric.

* * * * * * *

Discussion

There are 4 possible sources of domain names that come into these APIs:
1) The domain of the current top-level browsing context;
2) The domain of the source of the script,
3) Parameter(s) passed directly to the API
4) Domains declared in the well-known resource as 'partners'.

Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT signal it sends them.

We are looking for ways to ask the user to confirm 
* site-wide: they are granting a site-wide exception for third-parties on a specific site, and
* web-wide: they are granting a web-side general tracking exception for a specific site.

My previous message suggested that we could differentiate requests by noticing a match (or mismatch) of top-level domain and script-source, but this does not work for the use-case where a web-side exception is established while the site is first-party (but then applies when it is third-party): think of my previous example TrackMyReading.com, who want to track your visits web-wide through their 'like' button. You would probably set this up this on their site, but it would take effect elsewhere, where the button is embedded.

We therefore need two APIs: the site-wide and web-wide cases.

The introduction to these needs to explain that the call of the API should be the last step in establishing the exception; there is no presumption that the UA will do anything more than verify with the user that they agree. Explanation, understanding, and consent, etc. should have all have been established prior to the API call, though suitable web pages etc.

The calls causes the following steps to occur:
A) First, the UA somehow confirms with the user that they agree to the grant of exception;
B) If they agree, then the UA adds to its local database one or more site-pair duplets (top-level-domain, other-domain); one or other of these may be a wild-card ("*")
C) 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.

When asking for a site-wide exception, the top-level domain making the request may be making some 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. (Think of a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). 

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

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. The API might fetch the list of sites currently declared in the well-known URI as 'partners' as an example of the third-parties involved, but it should be noted that the partners list, and the set of embedded domains, might change after the API process is complete, and that the wild-card in the database applies dynamically to all sites that might be embedded, not just to the current 'partners' list.

There is a question whether either API should be callable when the script source is not the current top-level domain (cross-site issues). I cannot think why, myself, so I prohibit this case. Maybe here is some sensible way to establish with the user a web-wide exception while not the visited site, but I am not sure. My sense is that we should have good reason to relax this; the only one I can think immediately of is that this rule disables the use of script libraries loaded from other sites.

APIs

During the execution of these APIs, the top-level browsing domain and the domain origin of the script MUST match, otherwise no action is taken except an error value returned.

Establishing Site-Wide exceptions:

requestSiteSpecificTrackingException( <DOMstrings>, <callback>, [<sitename>], [< explanationString>], [<detailURI>] )

The execution of this API and the use of the resulting permission (if granted) use the 'implicit' parameter, when the API is called, of the domain of the origin of the script (script-origin). If permission is granted, then the set of duplets (one per DOMstring)

  [script-origin, DOMstring]

is added to the database of remembered grants.  


Establishing a web-wide exception:

6.7 Web-wide exceptions
 
Users may wish to configure exceptions for a certain trusted tracker across several or all sites.
 
User agents may instantiate NavigatorDoNotTrack.requestWebWideTrackingException. Sites should test for the existence of requestWebWideTrackingException 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.
 
A web-wide exception request can be initiated even when navigator.doNotTrack is null.
 
[NoInterfaceObject]
interface NavigatorDoNotTrack {
    void requestWebWideTrackingException (TrackingResponseCallback callback, optional siteNameString, optional  explanationString, optional  detailURI);
};
 
   - Note – all like named fields carry the same definitions as set forth in requestSiteSpecificTrackingException.
  

If permission is granted, then the single duplet

  [*, script-origin] 

is added to the database of remembered grants.  

Multiple calls can be facilitated through nested iFrames for each domain, similar to the NAI opt-out page individual domain call routines to set opt-out cookies for each domain. 




Removing exceptions

The two APIs
removeSiteSpecificTrackingException( <DOMstrings> )
removeWebWideTrackingException ( )

ensure that the database of remembered grants no longer contain
  [script-origin, DOMstring]  (for each DOMstring)
or
  [*, script-origin] 

respectively.  These methods never 'fail' and there is no callback. After the call has been made, the indicated pairs are assured not to be in the database.  The same matching as is used for determining which header to send is used to detect which entries (if any) to remove from the database.

Note that establishing (site, *) and then requesting removal of (site, otherSite) simply leaves (site, *) in the database; the removal request has no effect and does NOT establish "grant to exception to everyone except otherSite".





David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 22 May 2012 08:34:20 UTC