WWW/2011/tracking-protection/drafts tracking-dnt.html,1.117,1.118

Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv548

Modified Files:
	tracking-dnt.html 
Log Message:
In accordance with the agreed email,
I added the text for 
(a) cancelling site-specific exceptions and 
(b) adding and cancelling web-wide exceptions.

Added description text to all the exception APIs.



Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.117
retrieving revision 1.118
diff -u -d -r1.117 -r1.118
--- tracking-dnt.html	21 May 2012 23:33:04 -0000	1.117
+++ tracking-dnt.html	29 May 2012 23:14:12 -0000	1.118
@@ -1268,30 +1268,44 @@
             user&#8217;s expressed Do Not Track preference.</li>
 
           <li>The solution should not require cross-domain communication
-            between a first party publisher and its third party trackers.</li>
+            between a first party publisher and its third parties.</li>
         </ul>
+        <p>When asking for a site-specific exception, the top-level domain making the 
+        request may be making some implicit or explicit 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. (Consider a site that has some trusted advertisers 
+        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>
+        
+        <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 
+        the user may establish such a web-wide exception.</p>
+
       </section>
 
       <section>
         <h2>Exception model</h2>
         
         <section>
-          <h3>Site pairs</h3>
+          <h3>Introduction</h3>
           <p>This API considers exceptions which are double-keyed to two
           domains: the <strong>site</strong>, and the
-          <strong>tracker</strong>. A user might &#8212; for instance &#8212;
+          <strong>target</strong>. A user might &#8212; for instance &#8212;
           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:</p>
           
           <ul> 
-            <li><strong>This site</strong> is the domain name of the top-level
-            document origin of this DOM: essentially the fully qualified
-            domain name in the address bar.</li> 
-            <li>A <strong>tracker</strong> is a domain name which is not
-            operated by the same party which operates <strong>this
-            site</strong>, and which may be an origin for embedded resources
-            on <strong>this site</strong>.</li>
+            <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> 
+            <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>
           </ul>
           
            <p class="example">
@@ -1300,10 +1314,10 @@
              references the resources
              <code>http://exnews.analytico.net/1x1.gif</code> and
              <code>http://widgets.exsocial.org/good-job-button.js</code>,
-             <strong>this site</strong> is <code>web.exnews.com</code>; 
+             <strong>the top-level domain</strong> is <code>web.exnews.com</code>; 
              <code>exnews.analytico.net</code> and
              <code>widgets.exsocial.org</code> are both
-             <strong>trackers</strong>.
+             <strong>targets</strong>.
            </p>
            
            <p class="issue"><a
@@ -1315,17 +1329,47 @@
            should third party subdomains be allowed (e.g. *.tracker.com)?
            <br><b>Proposal</b>: Exceptions are requested for fully-qualified
            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> 
+		  </ul>
+           <p class="note">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 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:
+           <ul>
+			<li>First, the UA somehow confirms with the user that they agree to 
+			the grant of exception;</li>
+			<li>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 ("*");</li>
+			<li>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.</li>
+		   </ul>
+
         </section>
         <section>
           <h3>Exception use by browsers</h3>
           <p>
-            If a user wishes to be tracked by a <strong>tracker</strong> on
-            <strong>this site</strong>, this should result in two user-agent
+            If a user wishes to be tracked by a <strong>target</strong> on the
+            <strong>top-level domain</strong>, this should result in two user-agent
             behaviors:
             <ol>
               <li>
-                If requests to the <strong>tracker</strong> for resources that
-                are part of the DOM for pages on <strong>this site</strong>
+                If requests to the <strong>target</strong> for resources that
+                are part of the DOM for pages on <strong>top-level domain</strong>
                 include a DNT header, that header MUST be DNT:0.
               </li>
               <li>
@@ -1334,11 +1378,31 @@
               </li>
             </ol>
           </p>
-          <p class="note">
+          <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>
+          <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 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.</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. 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.</p>
+		  </div>
+
           <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 user-granted
@@ -1348,101 +1412,202 @@
           grant permissions to some third parties while browsing this
           domain")<br><b>Proposal</b>: 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.
+          to recall a user's past response. Finally, a site may add [self, self]
+          to the database as part of its request, and it will then get DNT:0.
           </p>
           
         </section>
       </section>
       <section id="exceptions-javascript-api">
         <h2 id="javascript_api_to_prompt_for_exceptions">JavaScript API for
-        user-granted exceptions</h3>        
-        <dl class="idl" title='[NoInterfaceObject] interface
-        NavigatorDoNotTrack'>
-          <dt>
-            void
-            requestSiteSpecificTrackingException(sequence&lt;DOMString&gt;
-            arrayOfDomainStrings, in TrackingResponseCallback callback,
-            optional siteName, optional explanationString, optional detailURI)
-          </dt>
-          <dd>
-            Called by a page to request or confirm a user-granted tracking
-            exception.
-          </dd>
-        </dl>
-        <dl class="idl" title='[Callback, NoInterfaceObject] interface
-        TrackingResponseCallback'>
-          <dt>
-            void handleEvent(in boolean granted)
-          </dt>
-          <dd>
-            The callback is called by the user agent to indicate the user's
-            response.
-          </dd>
-        </dl>
-        
-        <p>
-          The <code>requestSiteSpecificTrackingException</code> method takes
-          two mandatory arguments:
-        </p>
+        site-specific exceptions</h2>
+        <section id="exceptions-javascript-api-rqst"> 
+			<h3>API to request site-specific exceptions</h3>
+		   
+			<dl class="idl" title='[NoInterfaceObject] interface
+			NavigatorDoNotTrack'>
+			  <dt>
+				void
+				requestSiteSpecificTrackingException(sequence&lt;DOMString&gt;
+				arrayOfDomainStrings, in TrackingResponseCallback callback,
+				optional siteName, optional explanationString, optional detailURI)
+			  </dt>
+			  <dd>
+				Called by a page to request or confirm a user-granted tracking
+				exception.
+			  </dd>
+			</dl>
+			<dl class="idl" title='[Callback, NoInterfaceObject] interface
+			TrackingResponseCallback'>
+			  <dt>
+				void handleEvent(in boolean granted)
+			  </dt>
+			  <dd>
+				The callback is called by the user agent to indicate the user's
+				response.
+			  </dd>
+			</dl>
+			
+			<p>
+			  The <code>requestSiteSpecificTrackingException</code> method takes
+			  two mandatory arguments:
+			</p>
+	
+			<ul>
+			  <li>
+				<code>arrayOfDomainStrings</code>, a JavaScript array of strings,
+				and
+			  </li>
+			  <li>
+				<code>callback</code>, a method that will be called when the
+				request is complete.
+			  </li>
+			</ul>
+			<p>
+			  It also takes three optional arguments:
+			</p>
+			<ul>
+			  <li>
+				<code>siteName</code>, a string for the name of the top-level domain
+				(script origin),
+			  </li>
+			  <li>
+				<code>explanationString</code>, a short explanation of the
+				request, and
+			  </li>
+			  <li>
+				<code>detailURI</code>, a location at which further information
+				about this request can be found.
+			  </li>
+			</ul>
+	
+			<p>
+			  Each string in <code>arrayOfDomainStrings</code> specifies a
+			  <strong>target</strong>. The special string &#8220;*&#8221;
+			  signifies all <strong>targets</strong>. When called,
+			  <code>requestSiteSpecificTrackingException</code> MUST return
+			  immediately, then asynchronously determine whether the user grants
+			  the requested exceptions.
+			</p>
+	
+			<p>
+			  The <code>granted</code> parameter passed to the callback is the
+			  user&#8217;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 specified in
+			  <code>arrayOfDomainStrings</code>. 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
+			  specified in <code>arrayOfDomainStrings</code>.
+			</p>
+			
+			<p>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):</p>
+				<code>[top-level-domain, DOMstring]</code>
+			<p>is added to the database of remembered grants.</p>  
 
-        <ul>
-          <li>
-            <code>arrayOfDomainStrings</code>, a JavaScript array of strings,
-            and
-          </li>
-          <li>
-            <code>callback</code>, a method that will be called when the
-            request is complete.
-          </li>
-        </ul>
-        <p>
-          It also takes three optional arguments:
-        </p>
-        <ul>
-          <li>
-            <code>siteName</code>, a string for the name of this site,
-          </li>
-          <li>
-            <code>explanationString</code>, a short explanation of the
-            request, and
-          </li>
-          <li>
-            <code>detailURI</code>, a location at which further information
-            about this request can be found.
-          </li>
-        </ul>
+			<p>
+			  A particular response to the API &mdash; like a DNT response
+			  header &mdash; is only valid immediately, and users' preferences
+			  may change.
+			</p>
+			<p>
+			  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.
+			</p>
+        </section>
+        <section id="exceptions-javascript-api-cancel"> 
+			<h3>API to cancel a site-specific exception</h3>
+			<dl class="idl" title='[NoInterfaceObject] interface
+			NavigatorDoNotTrack'>
+			  <dt>
+				void
+				removeSiteSpecificTrackingException(sequence&lt;DOMString&gt;
+				arrayOfDomainStrings )
+			  </dt>
+			  <dd>
+				<p>Ensures that the database of remembered grants no longer contains</p>
+				<code>[top-level-domain, DOMstring]</code>
+				
+				<p>for all DOMstrings.  This method never fails 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.</p>
 
-        <p>
-          Each string in <code>arrayOfDomainStrings</code> specifies a
-          <strong>tracker</strong>. The special string &#8220;*&#8221;
-          signifies all <strong>trackers</strong>. When called,
-          <code>requestSiteSpecificTrackingException</code> MUST return
-          immediately, then asynchronously determine whether the user grants
-          the requested exceptions.
-        </p>
+				<p class="note">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 
+				<strong>not</strong> establish "grant an exception to 
+				everyone except otherSite".</p>
 
-        <p>
-          The <code>granted</code> parameter passed to the callback is the
-          user&#8217;s response; <code>true</code> indicates the user grants an
-          exception on <strong>this site</strong> for all of the
-          <strong>tracker</strong>s specified in
-          <code>arrayOfDomainStrings</code>. The response <code>false</code>
-          indicates that the user does not want an exception on <strong>this
-          site</strong> for at least one of the <strong>tracker</strong>s
-          specified in <code>arrayOfDomainStrings</code>.
-        </p>
-        
-        <p>
-          A particular response to the API &mdash; like a DNT response
-          header &mdash; is only valid immediately, and users' preferences
-          may change.
-        </p>
-        <p>
-          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.
-        </p>
-         
+			  </dd>
+			</dl>
+			
+        </section>
+      </section>
+      <section id="exceptions-ww-javascript-api">
+        <h2 id="javascript_api_to_prompt_for_ww_exceptions">JavaScript API for
+        web-wide exceptions</h2>
+		  <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/113">ISSUE-113</a>: Should there be a JavaScript API to prompt for a Web-wide exception? <br>
+            <b>PROPOSAL</b>: In this section
+          </p>
+
+        <section id="exceptions-javascript-api-ww-rqst"> 
+			<h3>API to request a web-wide exception</h3>
+			
+			<dl class="idl" title='[NoInterfaceObject] interface
+			NavigatorDoNotTrack'>
+			  <dt>
+				void
+				requestWebWideTrackingException(in TrackingResponseCallback callback,
+				optional siteName, optional explanationString, optional detailURI)
+			  </dt>
+			  <dd>
+				<p>If permission is granted, then the single duplet</p>
+				<code>[ * , top-level-domain]</code>
+				
+				<p>is added to the database of remembered grants.</p>
+
+				<p>The parameters are as described 
+				<a href="#javascript_api_to_prompt_for_exceptions">above</a> in the
+				request for site-specific exceptions.</p>
+
+			  </dd>
+			</dl>
+
+			<p>Users may wish to configure exceptions for a certain trusted 
+			tracker across all sites. This API requests the addition of a web-wide 
+			grant for a specific site, to the database.</p>
+			
+        </section>
+        <section id="exceptions-javascript-api-ww-cancel"> 
+			<h3>API to cancel a web-wide exception</h3>
+			
+			<dl class="idl" title='[NoInterfaceObject] interface
+			NavigatorDoNotTrack'>
+			  <dt>
+				void
+				removeWebWideTrackingException( )
+			  </dt>
+			  <dd>
+				<p>Ensures that the database of remembered grants no longer contains</p>
+				<code>[ * , top-level-domain]</code>
+				
+				<p>This method never fails and there 
+				is no callback. After the call has been made, the indicated 
+				pair is assured not to be in the database. The same matching 
+				as is used for determining which header to send is used to 
+				detect which entry (if any) to remove from the database.</p>
+
+			  </dd>
+			</dl>
+
+        </section>
       </section>
       
       <section class="informative">
@@ -1464,9 +1629,8 @@
 
         <pre class="example">
           Example News (<code>web.exnews.com</code>) would like to know
-          whether you permit tracking by the following parties:
-            * <code>exnews.analytico.net</code></li>
-            * <code>widgets.exsocial.org</code></li>
+          whether you permit tracking by a specific set of sites (click 
+          here for their names).
           
           Example News says:
             &#8220;These sites allow Example News to see how we&#8217;re
@@ -1486,15 +1650,9 @@
 
         <p>
           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
-          exceptions and which are not (using checkboxes, for
-          example). User agents might automatically clear user-granted
-          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 user-granted exceptions.
+          requests based on this stored preference. A user agent might provide the user 
+          with an interface to
+          explicitly remove (or add) user-granted exceptions.
         </p>
 
         <p>
@@ -1518,17 +1676,20 @@
           trust without visiting that site.
         </p>
 
-          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/83">ISSUE-83</a>: How do you opt out if already opted in?
+          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/83">ISSUE-83</a>: How do you opt out if already opted in?<br>
+            <b>PROPOSAL</b>: In this section
           </p>
-          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/129">ISSUE-129</a>: Should a blanket exception of the type ("*" at "firstparty") be possible?
+          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/129">ISSUE-129</a>: Should a blanket exception of the type ["firstparty", "*"] be possible?<br>
+            <b>PROPOSAL</b>: In this section
           </p>
-          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/130">ISSUE-130</a>: Should a global exception for a given third party on all sites be supported?
+          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/130">ISSUE-130</a>: Should a global exception for a given third party on all sites be supported? <br>
+            <b>PROPOSAL</b>: In this section
           </p>
-          <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 thirdparties for a site?
+          <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.
           </p>
-		  <p class="issue">We either need to prohibit or document what happens when the 
-		  	source of the script is not <b>this site</b> (same-origin).
-		  </p>
       </section>
 
         <section id="exceptions-when-not-enabled">
@@ -1562,21 +1723,6 @@
           </p>
         </section>
 
-        <section id="web-wide-exceptions">
-          <h3>Web-wide exceptions</h3>
-
-          <p>
-            Users may wish to configure exceptions for a certain trusted
-            <strong>tracker</strong> across several or all
-            <strong>sites</strong>. User agent configuration of these
-            preferences is outside the scope of this specification.
-          </p>
-          <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/113">ISSUE-113</a>: Should there be a JavaScript API to prompt for a Web-wide exception? <br>
-            <b>PROPOSAL</b>: User agents can provide configuration options
-            outside the scope of this specification.
-          </p>
-        </section>
-
       <section id="exceptions-fingerprinting">
         <h3 id="fingerprinting_concerns">Fingerprinting</h3>
 

Received on Tuesday, 29 May 2012 23:14:18 UTC