Actions 176 (and dup. 183), updated

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.

* * * * * * *

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

(script-origin, DOMstring) (once per DOMstring)

is added to the database of remembered grants.  


Establishing a web-wide exception:

 requestWebWideTrackingException(<callback>, [<sitename>], [< explanationString>], [<detailURI>] )

If permission is granted, then the single duplet

(*, script-origin) 

is added to the database of remembered grants.  


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 18 May 2012 07:28:20 UTC