W3C home > Mailing lists > Public > public-tracking-commit@w3.org > August 2012

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.142,1.143

From: Roy Fielding via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 07 Aug 2012 07:11:54 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1SydxK-0001cd-Gl@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv6134

Modified Files:
	tracking-dnt.html 
Log Message:
(editorial) remove TABs and trailing whitespace

Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -d -r1.142 -r1.143
--- tracking-dnt.html	7 Aug 2012 07:06:51 -0000	1.142
+++ tracking-dnt.html	7 Aug 2012 07:11:52 -0000	1.143
@@ -147,7 +147,7 @@
         third-party participants when an indication of tracking preference
         is received.
       </p>
-	    <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/136">ISSUE-136</a>: Resolve dependencies of the TPE on the compliance specification.<br />
+      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/136">ISSUE-136</a>: Resolve dependencies of the TPE on the compliance specification.<br />
         The WG has not come to consensus regarding the definition of tracking
         and the scope of DNT.  As such, a site cannot actually say with any
         confidence whether or not it is tracking, let alone describe the finer
@@ -155,7 +155,7 @@
         progress on the TCS document, though its resolution is a
         necessary prerequisite to understanding and correctly implementing
         the protocol defined by this document.
-      </p> 
+      </p>
     </section>
 
     <section id='notational'>
@@ -192,17 +192,17 @@
           command-line tools, native applications, and mobile apps [[!HTTP11]].
         </p>
          <p class="note">
-		  The term <dfn>permitted use</dfn> is used to indicate a restricted set of
-		  conditions under which tracking is allowed in spite of the user's DNT
-		  preference.
-		  The term <dfn>user-granted exception</dfn> is used when the user has 
-		  permitted tracking,
-		  usually in the form of a site-specific exception, for a given third-party.
-		  In general:
-		  permitted uses are additional permissions granted by the standard;
-		  user-granted exceptions are additional permissions granted by the user.
-		  These words are often confused when drafting new text.
-		</p>
+      The term <dfn>permitted use</dfn> is used to indicate a restricted set of
+      conditions under which tracking is allowed in spite of the user's DNT
+      preference.
+      The term <dfn>user-granted exception</dfn> is used when the user has
+      permitted tracking,
+      usually in the form of a site-specific exception, for a given third-party.
+      In general:
+      permitted uses are additional permissions granted by the standard;
+      user-granted exceptions are additional permissions granted by the user.
+      These words are often confused when drafting new text.
+    </p>
       </section>
     </section>
 
@@ -257,8 +257,8 @@
         configuration, install an extension or add-on that is specifically
         designed to add a tracking preference expression,
         or make a choice for privacy that then implicitly includes a
-        tracking preference (e.g., <q>Privacy settings: high</q>).  The user-agent 
-        might ask the user for their preference during startup, perhaps on 
+        tracking preference (e.g., <q>Privacy settings: high</q>).  The user-agent
+        might ask the user for their preference during startup, perhaps on
         first use or after an update adds the tracking protection feature. Likewise,
         a user might install or configure a proxy to add the expression
         to their own outgoing requests.
@@ -282,7 +282,7 @@
 
     <section id='expressing'>
       <h2>Expressing a Tracking Preference</h2>
-	<section id='expression-format'>
+  <section id='expression-format'>
         <h3>Expression Format</h3>
       <p>
         When a user has <a>enabled</a> a tracking preference, that
@@ -328,8 +328,8 @@
         adjust their behavior when no explicit preference is expressed via
         this protocol.
       </p>
-	  </section>
-	  
+    </section>
+
       <section id='dnt-header-field'>
         <h3>DNT Header Field for HTTP Requests</h3>
 
@@ -405,22 +405,22 @@
           when enabled, designers of future extensions ought to use as few
           extension characters as possible.
         </p>
-        <p class="note">This document does not have any implied or specified 
+        <p class="note">This document does not have any implied or specified
           behavior for the user-agent treatment of cookies when DNT is enabled.
         </p>
       </section>
 
       <section id='js-dom'>
         <h3>JavaScript API to Detect Preference</h3>
-	   <section id='js-interface'>
+     <section id='js-interface'>
         <h4>Interface</h4>
         <p>
           The <a>NavigatorDoNotTrack</a> interface provides a means for
           the user's tracking preference to be expressed to
           web applications running within a page rendered by the user agent.
         </p>
-		</section>
-		
+    </section>
+
         <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
           <dt>readonly attribute DOMString doNotTrack</dt>
           <dd>
@@ -487,10 +487,10 @@
           protocol in order to avoid receipt of the header is not compliant.
         </p>
         <div class='note'>
-        	<p>The last paragraph
-          	may be more appropriate in the compliance document, as it discusses
-          	compliance.
-        	</p>
+          <p>The last paragraph
+            may be more appropriate in the compliance document, as it discusses
+            compliance.
+          </p>
         </div>
       </section>
     </section>
@@ -508,7 +508,7 @@
           improve the transparency of tracking behavior by providing a
           machine-readable means for discovering claims of compliance and
           determining the current tracking status.
-        </p> 
+        </p>
         <p>
           Unfortunately, providing a dynamic indication of tracking compliance
           on every HTTP response is not feasible, since it would have the
@@ -516,7 +516,7 @@
           protocol defines a combination of response mechanisms that allow
           the information to be communicated without making every response
           dynamic.
-        </p> 
+        </p>
         <p>
           This section explains how a user agent MAY discover an origin
           server's tracking status for a given resource.
@@ -659,14 +659,14 @@
               / %x58  ; "X" - dynamic
         </pre>
 
-  	    <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/137">ISSUE-137</a>: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)<br />
-  	      <b>[OPEN]</b> There is significant disagreement over whether a
-  	      service provider acting on behalf of a first party needs to
-  	      indicate such in the tracking status. It is particularly nonsensical
-  	      given that there may be dozens of service providers acting on any
-  	      request and the service provider definition is already limited to
-  	      cases where any data collected is siloed and under control of
-  	      the first party.
+        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/137">ISSUE-137</a>: Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)<br />
+          <b>[OPEN]</b> There is significant disagreement over whether a
+          service provider acting on behalf of a first party needs to
+          indicate such in the tracking status. It is particularly nonsensical
+          given that there may be dozens of service providers acting on any
+          request and the service provider definition is already limited to
+          cases where any data collected is siloed and under control of
+          the first party.
         </p>
       </section>
 
@@ -675,7 +675,7 @@
 
         <section id='Tk-header-defn'>
           <h4>Definition</h4>
-          
+
           <p>
             The <dfn>Tk</dfn> response header field is hereby defined as an
             OPTIONAL means for indicating the tracking status that applied
@@ -711,7 +711,7 @@
             <b>[PENDING REVIEW]</b> See the proposal in this section.
           </p>
         </section>
-        
+
         <section id='referring-status-id'>
           <h4>Referring to a Request-specific Tracking Status Resource</h4>
           <p>
@@ -771,13 +771,13 @@
           </p>
           <pre class="example">Tk: U</pre>
         </section>
-        
+
       </section>
-		
+
       <section id='status-resource'>
         <h3>Tracking Status Resource</h3>
 
-    	  <section id='site-wide-status-resource'>
+        <section id='site-wide-status-resource'>
           <h4>Site-wide Tracking Status</h4>
           <p>
             An origin server MUST provide a <dfn>site-wide tracking status
@@ -804,7 +804,7 @@
           </p>
         </section>
 
-      	<section id='request-specific-status-resource'>
+        <section id='request-specific-status-resource'>
           <h4>Request-specific Tracking Status</h4>
           <p>
             If an origin server has multiple, request-specific tracking
@@ -1016,7 +1016,7 @@
           </p>
         </section>
 
-      	<section id='status-checks-not-tracked'>
+        <section id='status-checks-not-tracked'>
           <h4>Status Checks are Not Tracked</h4>
           <p>
             When sending a request for the tracking status, a user agent
@@ -1234,29 +1234,29 @@
           <li>The solution should not require cross-domain communication
             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 
+        <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 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 
+
+        <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>Introduction</h3>
           <p>This section describes the effect of the APIs in terms of a logical
-          processing model; this model describes the behavior, but should not 
+          processing model; this model describes the behavior, but should not
           be read as mandating any specific implementation.</p>
           <p>This API considers exceptions which are double-keyed to two
           domains: the <strong>site</strong>, and the
@@ -1264,11 +1264,11 @@
           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 three terms:</p>
-          
-          <ul> 
-            <li><strong>Top-Level Domain (TLD)</strong> is the domain name 
+
+          <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.</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>
@@ -1276,19 +1276,19 @@
             origin of the document that caused that script to be loaded (not
             necessarily the same as the origin of the script itself).</li>
           </ul>
-          
+
            <p class="example">
              For instance, if the document at
              <code>http://web.exnews.com/news/story/2098373.html</code>
              references the resources
              <code>http://exnews.analytico.net/1x1.gif</code> and
              <code>http://widgets.exsocial.org/good-job-button.js</code>,
-             <strong>the top-level domain</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>targets</strong>.
            </p>
-           
+
            <p class="issue"><a
            href="http://www.w3.org/2011/tracking-protection/track/issues/112">ISSUE-112</a>:
            How are sub-domains handled for site-specific exceptions?<br />
@@ -1299,35 +1299,35 @@
            <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>document origin</strong> active
-			at the time of the call, and;</li> 
-			<li>Domain names passed to the API.</li>
-		  </ul>
-		   <p>Domains that enter into the decision over what DNT header 
-		   to be sent in a given HTTP request include:
-		   <ul>
-		     <li>The <strong>top-level domain</strong> of the current context;</li>
-		     <li>The <strong>target</strong> of the HTTP request.</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 
+      <ul>
+      <li>As described above, the <strong>document origin</strong> active
+      at the time of the call, and;</li>
+      <li>Domain names passed to the API.</li>
+      </ul>
+       <p>Domains that enter into the decision over what DNT header
+       to be sent in a given HTTP request include:
+       <ul>
+         <li>The <strong>top-level domain</strong> of the current context;</li>
+         <li>The <strong>target</strong> of the HTTP request.</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>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>
-			<li>If they agree, then the UA adds to its local database one or 
-			more site-pair duplets [document-origin, target]; 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>
+      <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 [document-origin, target]; 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>
@@ -1350,12 +1350,12 @@
           </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?<br><b>Proposal</b>: The re-direct is not relevant; each 
+           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>
-           <p class="issue">This model does not support mashed-up content 
-           which is in turn supported by ads; it's not clear how to distinguish 
-           between embedded content which is embedding ads (and hence the top-level 
-           domain stays the same) and embedded content that should start 
+           <p class="issue">This model does not support mashed-up content
+           which is in turn supported by ads; it's not clear how to distinguish
+           between embedded content which is embedding ads (and hence the top-level
+           domain stays the same) and embedded content that should start
            a new context.<br><b>Proposal</b>: For this version of the specification,
            we don't address this corner case.</p>
           <div class="note">
@@ -1364,25 +1364,25 @@
             determine and how and whether to store users' tracking
             preferences.
           </p>
-          <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 
+          <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; 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 API 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. This assures sites that the set of sites they need for
-		  operational integrity is treated as a unit. Each separate call to an API
-		  is a separate unit.</p>
-		  </div>
+      <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 API 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. This assures sites that the set of sites they need for
+      operational integrity is treated as a unit. Each separate call to an API
+      is a separate unit.</p>
+      </div>
 
           <p class="issue"><a
           href="http://www.w3.org/2011/tracking-protection/track/issues/111">ISSUE-111</a>:
@@ -1396,212 +1396,212 @@
           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
         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(
-				  in TrackingResponseCallback callback,
-				  optional sequence&lt;DOMString&gt; arrayOfDomainStrings, 
-				  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 integer 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
-			  one mandatory argument:
-			</p>
-	
-			<ul>
-			  <li>
-				<code>callback</code>, a method that will be called when the
-				request is complete.
-			  </li>
-			</ul>
-			<p>
-			  It also takes four optional arguments:
-			</p>
-			<ul>
-			  <li>
-				<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
-				request, and
-			  </li>
-			  <li>
-				<code>detailURI</code>, a location at which further information
-				about this request can be found.
-			  </li>
-			</ul>
-	
-			<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 the 'implicit' parameter, when the API is called, 
-			the <strong>document origin</strong>. This forms the first part of the
-			duplet in the logical model, and hence in operation will be compared
-			with the <strong>top-level domain</strong>.</p>
-			
-			<p>The <code>granted</code> parameter passed to the callback is the
-			  user&#8217;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 for an explicit list,
-			 then the set of duplets (one per target):</p>
-				<code>[document-origin, 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>[document-origin, * ]</code>
-			<p>is added to the database of remembered grants.</p>  
+        <section id="exceptions-javascript-api-rqst">
+      <h3>API to request site-specific exceptions</h3>
 
-			<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>
+      <dl class="idl" title='[NoInterfaceObject] interface
+      NavigatorDoNotTrack'>
+        <dt>
+        void
+        requestSiteSpecificTrackingException(
+          in TrackingResponseCallback callback,
+          optional sequence&lt;DOMString&gt; arrayOfDomainStrings,
+          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 integer 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
+        one mandatory argument:
+      </p>
+
+      <ul>
+        <li>
+        <code>callback</code>, a method that will be called when the
+        request is complete.
+        </li>
+      </ul>
+      <p>
+        It also takes four optional arguments:
+      </p>
+      <ul>
+        <li>
+        <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
+        request, and
+        </li>
+        <li>
+        <code>detailURI</code>, a location at which further information
+        about this request can be found.
+        </li>
+      </ul>
+
+      <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 the 'implicit' parameter, when the API is called,
+      the <strong>document origin</strong>. This forms the first part of the
+      duplet in the logical model, and hence in operation will be compared
+      with the <strong>top-level domain</strong>.</p>
+
+      <p>The <code>granted</code> parameter passed to the callback is the
+        user&#8217;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 for an explicit list,
+       then the set of duplets (one per target):</p>
+        <code>[document-origin, 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>[document-origin, * ]</code>
+      <p>is added to the database of remembered grants.</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>
         </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( )
-			  </dt>
-			  <dd>
-				<p>Ensures that the database of remembered grants no longer contains any
-				duplets for which the first part is the current document origin,
-				i.e. no duplets </p>
-				<code>[document-origin, target]</code>
-				
-				<p>for any target.  There 
-				is no callback. After the call has been made, it is assured that there
-				are no site-specific or site-wide exceptions for the given
-				 top-level-domain.</p>
-			  </dd>
-			</dl>
-			
+        <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( )
+        </dt>
+        <dd>
+        <p>Ensures that the database of remembered grants no longer contains any
+        duplets for which the first part is the current document origin,
+        i.e. no duplets </p>
+        <code>[document-origin, target]</code>
+
+        <p>for any target.  There
+        is no callback. After the call has been made, it is assured that there
+        are no site-specific or site-wide exceptions for the given
+         top-level-domain.</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>
 
-        <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>[ * , document-origin]</code>
-				
-				<p>is added to the database of remembered grants.</p>
+        <section id="exceptions-javascript-api-ww-rqst">
+      <h3>API to request a web-wide exception</h3>
 
-				<p>The parameters are as described 
-				<a href="#javascript_api_to_prompt_for_exceptions">above</a> in the
-				request for site-specific exceptions.</p>
+      <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>[ * , document-origin]</code>
 
-			  </dd>
-			</dl>
+        <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>
 
-			<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 the duplet</p>
-				<code>[ * , document-origin]</code>
-				
-				<p>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>
+        <section id="exceptions-javascript-api-ww-cancel">
+      <h3>API to cancel a web-wide exception</h3>
 
-			  </dd>
-			</dl>
+      <dl class="idl" title='[NoInterfaceObject] interface
+      NavigatorDoNotTrack'>
+        <dt>
+        void
+        removeWebWideTrackingException( )
+        </dt>
+        <dd>
+        <p>Ensures that the database of remembered grants no longer
+        contains the duplet</p>
+        <code>[ * , document-origin]</code>
+
+        <p>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">
         <h2>User interface guidelines</h2>
-        
+
         <p>
           User agents are free to implement exception management user
           interfaces as they see fit. Some agents might provide a prompt to
@@ -1618,14 +1618,14 @@
 
         <pre class="example">
           Example News (<code>web.exnews.com</code>) would like to know
-          whether you permit tracking by a specific set of sites (click 
+          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
             doing, and provide useful features of the Example News
             experience.&#8221;     [More info]
-          
+
           [Allow Tracking]  [Deny Tracking Request]
         </pre>
 
@@ -1639,7 +1639,7 @@
 
         <p>
           The user agent might then store that decision, and answer future
-          requests based on this stored preference. A user agent might provide the user 
+          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>
@@ -1651,7 +1651,7 @@
           employs to determine DNT values (or the lack thereof) is out of the
           scope of this specification.
         </p>
-        
+
         <p>
           In some user-agent implementations, decisions to grant exceptions
           may have been made in the past (and since forgotten) or may have
Received on Tuesday, 7 August 2012 07:11:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 August 2012 07:11:57 GMT