W3C home > Mailing lists > Public > public-tracking-commit@w3.org > January 2013

CVS WWW/2011/tracking-protection/drafts

From: CVS User dsinger2 <cvsmail@w3.org>
Date: Wed, 16 Jan 2013 00:28:17 +0000
Message-Id: <E1TvGrZ-0000Bp-HL@gil.w3.org>
To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv643

Modified Files:
	tracking-dnt.html 
Log Message:
Edits for actions 
345 - add section for sites that do not normally have a visual/JS presence (from
Nick's text)
348 - ensure that the API allows the UA to pend the store while getting user
approval
349 - add 'confirm' APIs for both site and web-wide exceptions
351 - remove the 'what is the user's general preference' check, and move the
';what header would I receive' call to that section in the document (still needs
Nick to base this call on the right JS object)
353 - duplicate of 349



--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2012/12/07 00:26:44	1.174
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2013/01/16 00:28:17	1.175
@@ -421,55 +421,25 @@
 
       <section id='js-dom'>
         <h3>JavaScript API to Detect Preference</h3>
-        <p class="issue">This call is a candidate for deletion, relying only on the
-        origin-specific call below (Nick Doty's suggestion).
-        </p>
-
-        <p>
-          A <a>doNotTrack</a> attribute on the <code>Navigator</code>
-          interface [[!NAVIGATOR]] (e.g., the <code>window.navigator</code>
-          object) is hereby defined as the means for expressing the user's
-          general tracking preference to scripts running within a top-level
-          page. A user agent MUST provide a <code>doNotTrack</code> attribute
-          on the <code>Navigator</code> interface for each top-level page.
-        </p>
-        <dl class="idl" title='partial interface Navigator {
-                                 readonly attribute DOMString doNotTrack;
-                               };'>
-          <dt>readonly attribute DOMString doNotTrack</dt>
-          <dd>
-            When a tracking preference is <a>enabled</a>, the
-            <code>doNotTrack</code> attribute for each top-level page MUST
-            have the same string value that would be sent in a
+                <p class="issue" data-number="160" title="Do we need an exception-query API?"><b>[PENDING REVIEW]</b>
+            It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context. See proposal here.<br />
+            <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level origin</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
+          </p>
+          <p>This call enables a site to determine what DNT header would be sent to it
+          in the current context, taking into account the user's general preference 
+          (if any) and any exceptions.</p>
+          <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
+            <dt>DOMString requestDNTStatus( )</dt>
+            <dd>
+              Returns the same string value that would be sent in a
             <a>DNT-field-value</a> (<a href="#dnt-header-field"
-            class="sectionRef"></a>) to an origin server that does not have
-            any corresponding user-granted exceptions.
-            When a tracking preference is <a>not enabled</a>, the
-            <code>doNotTrack</code> attribute for each top-level page MUST
-            have a value of <code>null</code>.
-          </dd>
-        </dl>
-        <p>
-          The <code>doNotTrack</code> attribute only provides the user's
-          general tracking preference, independent of any user-granted
-          exceptions or out-of-band consent.  A script wishing to determine
-          the specific tracking preference for a given document origin is
-          expected to use the API in <a href="#exceptions-enquiry"
-          class="sectionRef"></a>.
-        </p>
-        <p>
-          A user agent MUST provide a <code>doNotTrack</code> attribute
-          value that is consistent with the user's current tracking
-          preference that would be expressed via the DNT header field.
-          However, changes to the user's preference might occur between
-          the time when the APIs are checked and an actual request is made.
-          A server MUST treat the user's most recently received preference as
-          authoritative.
-        </p>
-        <p class="issue" data-number="116" title="How can we build a JS DOM property which doesn't allow inline JS to receive mixed signals?">
-          <strong>[PENDING REVIEW]</strong>
-          Updated text in this section.
-        </p>
+            class="sectionRef"></a>) to a <strong>target</strong> that is the
+              document-origin of the request, in the
+              context of the current <strong>top-level origin</strong>. If no DNT
+              header would be sent (e.g. because a tracking preference is 
+              <a>not enabled</a>) the return value is <code>null</code>.
+            </dd>
+          </dl>
       </section>
 
       <section id='plug-ins'>
@@ -1501,7 +1471,7 @@
 		  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 stored, and later remove only one or
+		  targets {a, b, c} exists in the database, 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
@@ -1552,7 +1522,7 @@
         <h2>JavaScript API for Site-specific Exceptions</h2>
         
         <section id="exceptions-javascript-api-rqst">
-          <h3>API to request site-specific exceptions</h3>
+          <h3>API to Request a Site-specific Exception</h3>
 
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
             <dt>integer storeSiteSpecificTrackingException (
@@ -1609,11 +1579,12 @@
           <ul>
             <li><code>0</code> indicates a syntax or other operational error.</li>
             <li><code>1</code> indicates that the request was for specific 
-            <strong>target</strong>s and the the user-agent has stored an exception on
+            <strong>target</strong>s and the the user-agent has stored or will store 
+            an exception on
               <strong>top-level origin</strong> for those specific
               <strong>target</strong>s.</li>
-            <li><code>2</code> indicates the user-agent has stored a site-wide exception
-              on <strong>top-level origin</strong> for all
+            <li><code>2</code> indicates the user-agent has stored or will store
+            a site-wide exception on <strong>top-level origin</strong> for all
               <strong>target</strong>s; the request may have been for
               specific <strong>target</strong>s or for a site-wide exception.</li>
           </ul>
@@ -1627,7 +1598,7 @@
           </p>
           <p>
             If permission is stored for a site-wide exception, then the
-            duplets:
+            duplet:
           </p>
           <pre>[document-origin, * ]</pre>
           <p>
@@ -1641,8 +1612,10 @@
           <p class="note">
             The prior version of this call was asynchronous with a call-back; the change
             to require the site to determine the user's wishes, rather than the UA,
-            enabled this to become synchronous.  This is simpler, unless the UA
-            wishes to ask the user and not store until the user agrees.
+            enabled this to become synchronous.  This is simpler; the user-agent may 
+            still ask for the user's approval. Sites wishing to know whether an 
+            exception stands, or the DNT header that they would receive,
+            should call the appropriate enquiry API.
           </p>
         </section>
 
@@ -1667,6 +1640,70 @@
           some kind of processing error occurred.
           </p>
         </section>
+        
+        <section id="exceptions-javascript-api-confirm">
+          <h3>API to Confirm a Site-specific Exception</h3>
+
+          <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
+            <dt>boolean confirmSiteSpecificTrackingException (
+                  optional sequence&lt;DOMString&gt; arrayOfDomainStrings)
+            </dt>
+            <dd>
+              Called by a page to confirm a site-specific tracking
+              exception.
+            </dd>
+          </dl>
+
+          <p>
+            The <code>confirmSiteSpecificTrackingException</code> method takes
+            one optional argument:
+          </p>
+          <ul>
+            <li><code>arrayOfDomainStrings</code>, a JavaScript array of
+              strings,</li>
+          </ul>
+          <p>
+            If the call does not include the
+            <code>arrayOfDomainStrings</code>, then this call is top confirm a
+            site-wide exception. Otherwise each string in
+            <code>arrayOfDomainStrings</code> specifies a
+            <strong>target</strong>.
+          </p>
+          <p>
+            If the list <code>arrayOfDomainStrings</code> is supplied, and the
+            user-agent stores only site-wide exceptions, then the user-agent
+            MUST match by confirming a site-wide exception.
+          </p>
+          <p>
+            The execution of this API uses 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.
+          </p>
+          <p>
+            If the user-agent stores explicit lists, and the call includes one, the
+            database is checked for the existence of all the duplets (one per target):
+          </p>
+          <pre>[document-origin, target]</pre>
+
+          <p>
+            If the user-agent stores only site-wide exceptions or the call did
+            not include an explicit list, the database is checked for the 
+            single duplet:
+          </p>
+          <pre>[document-origin, * ]</pre>
+
+          <p>
+            The returned boolean has the following possible values:
+          </p>
+          <ul>
+            <li><code>true</code> all the duplets exist in the database;</li>
+            <li><code>false</code> one or more of the duplets does not
+              exist in the database.</li>
+          </ul>
+        </section>
+
+
       </section>
 
       <section id="exceptions-ww-javascript-api">
@@ -1699,16 +1736,16 @@
           </p>
           <ul>
             <li><code>0</code> indicates a syntax or other operational error.</li>
-            <li><code>1</code> indicates that the request was stored.</li>
+            <li><code>1</code> indicates that the request was or will be stored.</li>
           </ul>
 		  <p class="note">
 		  	As above, this call used to be asynchronous, and the change to the UI
-		  	enabled it to be sycnhronous.
+		  	enabled it to be synchronous.
 		  </p>
         </section>
 
         <section id="exceptions-javascript-api-ww-cancel">
-          <h3>API to cancel a web-wide exception</h3>
+          <h3>API to Cancel a Web-wide Exception</h3>
 
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
             <dt>boolean removeWebWideTrackingException( )</dt>
@@ -1728,29 +1765,31 @@
           </p>
 
         </section>
-      </section>
 
-      <section id="exceptions-enquiry" >
-        <h2>Querying a host's exception status</h2>
-                <p class="issue" data-number="160" title="Do we need an exception-query API?"><b>[PENDING REVIEW]</b>
-            It might be useful, and 'complete the model', if we had a JS API that told a host what its current exception status is in a given context. See proposal here.<br />
-            <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level origin</b> and returns an empty string if no DNT header would be sent to that document origin, or the exact DNT header (DNT:1 or DNT:0) that would be sent otherwise.
-          </p>
+        <section id="exceptions-javascript-api-ww-confirm">
+          <h3>API to Confirm a Web-wide Exception</h3>
+
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
-            <dt>DOMString requestDNTStatus( )</dt>
-            <dd>
-              Returns the same string value that would be sent in a
-            <a>DNT-field-value</a> (<a href="#dnt-header-field"
-            class="sectionRef"></a>) to a <strong>target</strong> that is the
-              document-origin of the request, in the
-              context of the current <strong>top-level origin</strong>. If no DNT
-              header would be sent (e.g. because a tracking preference is 
-              <a>not enabled</a>) the return value is <code>null</code>.
-            </dd>
+            <dt>boolean confirmWebWideTrackingException ()
+            </dt>
           </dl>
+          <p>
+            This API confirms the existence of a
+            web-wide grant for a specific site, in the database.
+          </p>
+          <p>
+            The returned boolean indicates whether the duplet
+            <code>[ * , document-origin]</code> exists in the database.
+          </p>
+          <ul>
+            <li><code>true</code> indicates that the web-wide exception exists;</li>
+            <li><code>false</code> indicates that the web-wide exception 
+              does not exist.</li>
+          </ul>
+        </section>
 
       </section>
-      
+
 	  <section id="transitive-exceptions">
 	    <h2>Transfer of an exception to another third party</h2>
 	    <p>A site may request an exception for one or more third party services used in 
@@ -1830,10 +1869,11 @@
         <p>
           User agents are free to implement exception management user
           interfaces as they see fit. Some agents might provide a notification to
-          the user at the time of the request. Some agents might provide a
+          the user at the time of the request, or even not complete the storing of
+          the exception until the user approves. Some agents might provide a
           user-interface to see and edit the database of recorded exception grants.
           The API parameters siteName, explanationString, and detailURI are
-          provided so that the user-agent may use them in this UI.
+          provided so that the user-agent may use them in their user interface.
         </p>
         <p>
           A user agent that chooses to highlight when tracking exceptions have been 
@@ -1872,6 +1912,35 @@
         </p>
       </section>
 
+      <section id="exceptions-no-js" class="informative">
+        <h2>Exceptions without interactive JavaScript</h2>
+			<p>Some third party servers that comply with this standard may wish to 
+			receive user-granted exceptions but when they are invoked as third 
+			parties (using, for example, images, or "tracking pixels") do not 
+			have an interactive JavaScript presence on the page. They cannot 
+			request an exception under these circumstances, both because a 
+			script is needed, and because they are required to explain to the 
+			user the need for and consequences of granting an exception, and 
+			get the user's consent. In general this process of informing, 
+			getting consent, and calling the API is not expected to be in 
+			the page where such trackers are invoked.</p>
+			
+			<p>To obtain an exception, a document (page, frame, etc.) that 
+			loads the Javascript is needed. The user may visit the site 
+			that desires an exception directly, the first party site could 
+			load a frame of the site desiring the exception, or that frame 
+			might be part of some other page containing a number of frames, 
+			which allows aggregation of requests for exceptions.</p>
+			
+			<p>In all these ways, the site is contributing to informing the 
+			user and getting their consent, and is also able to call the 
+			Javascript API when it is granted.</p>
+			
+			<p class="note">Depending on the resolution of options for the 
+			User-Granted Exceptions section, this language might need to be 
+			updated to correspond.</p>
+      </section>
+
       <section id="exceptions-when-not-enabled">
         <h3>Exceptions without a DNT header</h3>
 
Received on Wednesday, 16 January 2013 00:28:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 January 2013 00:28:18 GMT