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

WWW/2011/tracking-protection/drafts tracking-dnt.html,1.171,1.172

From: David Singer via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 26 Oct 2012 21:04:52 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1TRr5I-0008Fc-Ug@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv31648

Modified Files:
	tracking-dnt.html 
Log Message:
actions 282 and 290 
note that multiple DNT headers are now allowed (per HTTP 1.1)
and change top-level domain (wrong term) to top-level origin



Index: tracking-dnt.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
retrieving revision 1.171
retrieving revision 1.172
diff -u -d -r1.171 -r1.172
--- tracking-dnt.html	17 Oct 2012 08:39:51 -0000	1.171
+++ tracking-dnt.html	26 Oct 2012 21:04:50 -0000	1.172
@@ -411,6 +411,12 @@
         <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>
+        <p class="note">The HTTP specification [[!HTTP11]] permits multiple headers 
+        with the same field-name only under restricted circumstances which do 
+        not apply here; hence, at most one DNT header may be present in a valid 
+        HTTP request.
+        </p>
+
       </section>
 
       <section id='js-dom'>
@@ -1322,7 +1328,7 @@
             between a first-party publisher and its third parties.</li>
         </ul>
         <p>
-          When asking for a site-specific exception, the top-level domain
+          When asking for a site-specific exception, the top-level origin
           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
@@ -1335,7 +1341,7 @@
         </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
+          to track them on any top-level origin. An API is provided so that
           the site and the user may establish such a web-wide exception.
         </p>
       </section>
@@ -1359,13 +1365,13 @@
             specification, we define three terms:
           </p>
           <ul>
-            <li><strong>Top-Level Domain (TLD)</strong> is the domain name
+            <li><strong>top-level origin</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>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>
+              origin</strong>.</li>
             <li>The <strong>document origin</strong> of a script is the domain
               of origin of the document that caused that script to be loaded
               (not necessarily the same as the origin of the script
@@ -1377,7 +1383,7 @@
              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 origin</strong> is <code>web.exnews.com</code>;
              <code>exnews.analytico.net</code> and
              <code>widgets.exsocial.org</code> are both
              <strong>targets</strong>.
@@ -1404,7 +1410,7 @@
             sent in a given HTTP request include:
           </p>
           <ul>
-            <li>The <strong>top-level domain</strong> of the current context;</li>
+            <li>The <strong>top-level origin</strong> of the current context;</li>
             <li>The <strong>target</strong> of the HTTP request.</li>
           </ul>
           <p class="note">
@@ -1423,9 +1429,9 @@
             <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),
+            <li>While the user is browsing a given site (top-level origin),
               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
+              [top-level origin, target domain] matches any duplet in the
               database, then a DNT:0 header is sent, otherwise DNT:1 is
               sent.</li>
           </ul>
@@ -1440,12 +1446,12 @@
           <h3>Exception use by browsers</h3>
           <p>
             If a user agrees to allow tracking by a <strong>target</strong> on
-            the <strong>top-level domain</strong>, this should result in two
+            the <strong>top-level origin</strong>, this should result in two
             user-agent behaviors:
           </p>
           <ol>
             <li>If requests to the <strong>target</strong> for resources that
-              are part of the DOM for pages on <strong>top-level domain</strong>
+              are part of the DOM for pages on <strong>top-level origin</strong>
               include a DNT header, that header MUST be DNT:0.</li>
             <li>Responses to the JavaScript API indicated should be consistent
               with this user preference (see below).
@@ -1455,7 +1461,7 @@
             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
+            origin 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.
@@ -1485,7 +1491,7 @@
             <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
+              example, be told that such-and-such top-level origin 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
@@ -1493,7 +1499,7 @@
             </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
+              the top-level origin is asking for an exception for all
               third-parties that are, or will be, embedded in it.
             </p>
           </div>
@@ -1559,7 +1565,7 @@
             <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>
+              name of the top-level origin,</li>
             <li><code>explanationString</code>, a short explanation of the
             request, and</li>
             <li><code>detailURI</code>, a location at which further
@@ -1586,7 +1592,7 @@
             (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>.
+            compared with the <strong>top-level origin</strong>.
           </p>
           <p>
             The <code>granted</code> parameter passed to the callback is the
@@ -1594,14 +1600,14 @@
           </p>
           <ul>
             <li><code>0</code> indicates that user does not grant the
-              exception on <strong>top-level domain</strong> for the indicated
+              exception on <strong>top-level origin</strong> for the indicated
               <strong>target</strong>s.</li>
             <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>top-level origin</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
+              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>
@@ -1645,7 +1651,7 @@
               target]</code> 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.
+              top-level origin.
             </dd>
           </dl>
           <p>This returns a boolean indicating, when true, that the call has 
@@ -1712,7 +1718,7 @@
         <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 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.
+            <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>
           <dl class="idl" title='[NoInterfaceObject] interface NavigatorDoNotTrack'>
             <dt>DOMString requestDNTStatus( )</dt>
@@ -1721,7 +1727,7 @@
             <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 domain</strong>. If no DNT
+              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>
Received on Friday, 26 October 2012 21:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 21:04:54 GMT