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

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.153,1.154

From: David Singer via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 22 Aug 2012 21:47:10 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1T4Ila-000787-61@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv26367

Modified Files:
	tracking-dnt.html 
Log Message:
all tidy-ups, after David W's message
added text that says that many terms are defined in the compliance document
(notably part, 1st party etc.);
improved the documentation of the exception request call;
made it clearer in the informative user guidelines that the API call
and resilting UI is the end of a process of user-interaction that is done by the 
site;
added the actual call to requestDNTStatus and defined its return result



Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.153
retrieving revision 1.154
diff -u -d -r1.153 -r1.154
--- tracking-dnt.html	14 Aug 2012 08:54:25 -0000	1.153
+++ tracking-dnt.html	22 Aug 2012 21:47:07 -0000	1.154
@@ -199,6 +199,10 @@
           permitted tracking by a given third party, usually in the form of a
           site-specific exception.
         </p>
+        <p>
+		  A companion document, [[!TRACKING-COMPLIANCE]], defines many of the
+		  terms used here, notably 'party', 'first party', and 'third party'.
+      </p>
       </section>
     </section>
 
@@ -1535,12 +1539,14 @@
             <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
+            <li><code>1</code> indicates that the request was for specific 
+            <strong>target</strong>s and the the user grants an exception on
+              <strong>top-level domain</strong> for those 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>
+              <strong>target</strong>s; the request may have been for
+              specific <strong>target</strong>s or for a site-wide exception.</li>
           </ul>
           <p>
             If permission is granted for an explicit list, then the set of
@@ -1651,6 +1657,17 @@
             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.<br />
             <b>Proposal</b>: Specifically, an API QueryExceptionStatus() which examines the <b>document origin</b> of the script, the current <b>top-level domain</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>
+          <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
+            <dt>DOMString requestDNTStatus( )</dt>
+            <dd>
+              Returns the string of the value of the DNT header that would be
+              sent in an HTTP request to the <strong>target</strong> that is the
+              document-origin of the request, in the
+              context of the current <strong>top-level domain</strong>. The return
+              value is an empty string if no DNT header would be sent (for example, 
+              if DNT is not configured).
+            </dd>
+          </dl>
 
       </section>
 
@@ -1665,13 +1682,20 @@
           agent responds with the user's preference.
         </p>
         <p>
+          In general, it is expected that the site will explain, in its online
+          content, the need for an
+          exception, and the consequences of granting or denying an exception, to
+          the user, and guide. The call to the API and the resulting request for
+          user confirmation should not be a 'surprise' to the user, or require
+          much explanation on the part of the user-agent.
+        <p>
           A user agent that chooses to implement a prompt to present tracking
           exception requests to the user might provide an interface like the
           following:
         </p>
         <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
+          Example News (<code>web.exnews.com</code>) would like to confirm
+          that you permit tracking by a specific set of sites (click
           here for their names).
 
           Example News says:
Received on Wednesday, 22 August 2012 21:47:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 August 2012 21:47:12 GMT