- From: David Singer via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 30 Jul 2012 23:42:28 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv31044
Modified Files:
tracking-dnt.html
Log Message:
Revised site-specific exception API again, to allow specific lists, allow
UAs to generalize such lists to site-wide, remove the same-origin constraint
and hence allow use of libraries, and require UAs to treat each call as
'atomic', thereby assuring sites of some consistency in what is granted.
Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -d -r1.127 -r1.128
--- tracking-dnt.html 18 Jul 2012 11:05:07 -0000 1.127
+++ tracking-dnt.html 30 Jul 2012 23:42:26 -0000 1.128
@@ -1288,7 +1288,8 @@
<section id='exceptions' class="option">
<h2>User-Granted Exceptions</h2>
- <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT values to signify existence of site-specific exceptions</p>
+ <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>: Different DNT values to signify existence of site-specific
+ exceptions.</p>
<section id="exceptions-overview" class="informative">
<h2>Overview</h2>
@@ -1346,7 +1347,7 @@
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 wild-card "*").</p>
+ site (site-wide exception, using the conceptual wild-card "*").</p>
<p>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
@@ -1365,15 +1366,14 @@
<p>This API considers exceptions which are double-keyed to two
domains: the <strong>site</strong>, and the
<strong>target</strong>. A user might — for instance —
- want AnalytiCo to track them on Example News, but not on Example
+ 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 two terms:</p>
<ul>
<li><strong>Top-Level Domain (TLD)</strong> is the domain name
of the top-level document origin of this DOM: essentially the fully qualified
- domain name in the address bar. For all these APIs, this MUST match the
- script origin.</li>
+ domain name in the address bar.</li>
<li>A <strong>target</strong> site is a domain name which is the target
of an HTTP request, and which may be an origin for embedded resources
on <strong>the indicated top-level domain</strong>.</li>
@@ -1402,10 +1402,9 @@
domain names.</p>
<p>The domains that enter into the behavior of the APIs include:</p>
<ul>
- <li>As described above, the <strong>Top-Level Domain (TLD)</strong>;</li>
- <li>The domain of the origin of the script;</li>
- <li>Domain names passed to the API;</li>
- <li>Domains declared in the well-known resource as 'partners'.</li>
+ <li>As described above, the <strong>Top-Level Domain (TLD)</strong> active
+ at the time of the call, and;</li>
+ <li>Domain names passed to the API.</li>
</ul>
<p class="note">Note that these strict, machine-discoverable, concepts
may not match the definitions of first and third party; in particular,
@@ -1413,11 +1412,7 @@
to first party by virtue of user interaction; the UA will not change
the DNT header it sends them.</p>
- <p>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, and an error value returned.</p>
-
- <p>The calls causes the following steps to occur:
+ <p>The calls cause the following steps to occur:
<ul>
<li>First, the UA somehow confirms with the user that they agree to
the grant of exception;</li>
@@ -1451,21 +1446,29 @@
</p>
<p class="issue">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?</p>
+ matching rules?<br><b>Proposal</b>: The re-direct is not relevant; each
+ site gets the DNT header controlled by the list of grants.</p>
<div class="note">
<p >
It is left up to individual user-agent implementations how to
determine and how and whether to store users' tracking
preferences.
</p>
- <p >When an explicit list of domains is provided, their names might mean
- little to the user. The user
+ <p >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.</p>
- <p >Conversely, if a wild-card is or will be used, the user may be told
+ 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.</p>
+ <p >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.</p>
+ <p>User-agents MUST handle each 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.</p>
</div>
<p class="issue"><a
@@ -1493,8 +1496,10 @@
NavigatorDoNotTrack'>
<dt>
void
- requestSiteSpecificTrackingException(in TrackingResponseCallback callback,
- optional siteName, optional explanationString, optional detailURI)
+ requestSiteSpecificTrackingException(
+ in TrackingResponseCallback callback,
+ optional sequence<DOMString> arrayOfDomainStrings,
+ optional siteName, optional explanationString, optional detailURI)
</dt>
<dd>
Called by a page to request or confirm a user-granted tracking
@@ -1504,7 +1509,7 @@
<dl class="idl" title='[Callback, NoInterfaceObject] interface
TrackingResponseCallback'>
<dt>
- void handleEvent(in boolean granted)
+ void handleEvent(in integer granted)
</dt>
<dd>
The callback is called by the user agent to indicate the user's
@@ -1514,7 +1519,7 @@
<p>
The <code>requestSiteSpecificTrackingException</code> method takes
- the mandatory argument:
+ one mandatory argument:
</p>
<ul>
@@ -1524,12 +1529,15 @@
</li>
</ul>
<p>
- It also takes three optional arguments:
+ It also takes four optional arguments:
</p>
<ul>
<li>
- <code>siteName</code>, a string for the name of the top-level domain
- (script origin),
+ <code>arrayOfDomainStrings</code>, a JavaScript array of strings,
+ </li>
+ <li>
+ <code>siteName</code>, a user-readable string for the
+ name of the top-level domain,
</li>
<li>
<code>explanationString</code>, a short explanation of the
@@ -1541,39 +1549,48 @@
</li>
</ul>
- <p>When called,
+ <p>If the request does not include the <code>arrayOfDomainStrings</code>,
+ then this request is for a site-wide exception. Otherwise
+ each string in <code>arrayOfDomainStrings</code> specifies a
+ <strong>target</strong>. When called,
<code>requestSiteSpecificTrackingException</code> MUST return
immediately, then asynchronously determine whether the user grants
the requested exception(s).
</p>
+ <p>If the list <code>arrayOfDomainStrings</code> 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.</p>
<p>The execution of this API and the use of the resulting permission
- (if granted) use two 'implicit' parameters, when the API is called:
- <ul>
- <li>the domain of the origin of the script (script-origin);</li>
- <li>the 'partners' list at the well-known URL location.</li>
- </ul>
- The user-agent SHOULD use the partners as the list of
- <strong>target</strong>s,
- if it exists, or a list containing the single special string “*”,
- indicating all targets,
- as the <strong>target</strong> if it does not; it MAY use a list of the
- special
- string “*” even if the partners list exists.</p>
+ (if granted) use the 'implicit' parameter, when the API is called,
+ the domain of the top-level site.</p>
<p>The <code>granted</code> parameter passed to the callback is the
- user’s response; <code>true</code> indicates the user grants an
- exception on <strong>top-level domain</strong> for all of the
- <strong>target</strong>s. The response <code>false</code>
- indicates that the user does not want an exception on
- <strong>top-level domain</strong> for at least one of
- the <strong>target</strong>s.
+ user’s response; The response
+ <ul>
+ <li><code>0</code>
+ indicates that user does not grant the exception on
+ <strong>top-level domain</strong> for
+ the indicated <strong>target</strong>s.</li>
+ <li><code>1</code> indicates the user grants an
+ exception on <strong>top-level domain</strong> for the specific
+ <strong>target</strong>s.</li>
+ <li><code>2</code> indicates the user grants a site-wide
+ exception on <strong>top-level domain</strong> for all
+ <strong>target</strong>s.</li>
+ </ul>
</p>
- <p>If permission is granted, then the set of duplets (one per target):</p>
+ <p>If permission is granted for an explicit list,
+ then the set of duplets (one per target):</p>
<code>[top-level-domain, target]</code>
<p>is added to the database of remembered grants.</p>
+ <p>If permission is granted for a site-wide exception,
+ then the duplets:</p>
+ <code>[top-level-domain, * ]</code>
+ <p>is added to the database of remembered grants.</p>
<p>
A particular response to the API — like a DNT response
@@ -1596,13 +1613,14 @@
</dt>
<dd>
<p>Ensures that the database of remembered grants no longer contains any
- duplets </p>
+ duplets for which the first part is the current top-level domain,
+ i.e. no duplets </p>
<code>[top-level-domain, target]</code>
<p>for any target. This method never fails and there
is no callback. After the call has been made, it is assured that there
- are no site-specific exceptions for the given top-level-domain.</p>
-
+ are no site-specific or site-wide exceptions for the given
+ top-level-domain.</p>
</dd>
</dl>
@@ -1746,7 +1764,9 @@
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/140">ISSUE-140</a>: Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a site?<br>
<b>PROPOSAL</b>: 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.
+ 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'.
</p>
</section>
Received on Monday, 30 July 2012 23:42:30 UTC