CVS WWW/2011/tracking-protection/drafts

Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv17573

Modified Files:
	tracking-dnt.html 
Log Message:
updated/inserted/removed issues to maintain sync with the issue database



--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2013/01/30 21:10:26	1.181
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html	2013/02/12 15:16:40	1.182
@@ -421,10 +421,6 @@
 
       <section id='js-dom'>
         <h3>JavaScript Property to Detect Preference</h3>
-                <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, a doNotTrack property which examines the <b>document origin</b> of the window, the current <b>top-level origin</b> and returns null 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 property enables a site executing code in its own origin
               to determine what DNT header would be sent to it in the current
@@ -1029,10 +1025,6 @@
 <dfn>first-party</dfn>    = %x22 "first-party" %x22
 <dfn>first-party-v</dfn>  = array-of-strings
           </pre>
-          <p class="issue" data-number="190" title="Sites with multiple first parties ">
-            <b>[PENDING REVIEW]</b> The <code><a>first-party</a></code>
-            member resolves this issue.
-          </p>
           <p>
             An OPTIONAL member named <code><a>same-party</a></code> MAY be
             provided with an array value containing a list of domain names
@@ -1150,6 +1142,17 @@
   "control": "/your/data",
 }
 </pre>
+		  <p class="issue" data-number="164" title="To what extent should the same-party attribute of tracking status resource be required?">
+		  3 Alternatives - text is needed:<br/>
+		  (A) Current draft: Resource is optional<br/>
+		  (B) Alternative proposal 1: If multiple domains on a page belong to the 
+		  same party, then this fact SHOULD be declared using the 
+		  same-party attribute<br/>
+		  (C) Alternative proposal 2: State that user agents MAY assume that 
+		  additional elements that are hosted under a different URL and occur 
+		  on a page and declare "intended for 1st party use" are malicious unless 
+		  this URL is listed in the "same-party" attribute
+		 </p>
         </section>
 
         <section id='status-checks-not-tracked'>
@@ -1336,7 +1339,7 @@
         </p>
 
         <p class="issue" data-number="144" title="What constraints on user agents should be imposed for user/granted exceptions">
-          <b>[OPEN]</b> but mostly addressed in the proposal here.
+          <b>[PENDING REVIEW]</b> but mostly addressed in the proposal here.
         </p>
       </section>
 
@@ -1467,7 +1470,7 @@
              <strong>targets</strong>.
           </p>
           <p class="issue" data-number="112" title="How are sub-domains handled for site-specific exceptions?">
-            <b>[PENDING REVIEW]</b> Should a request for a tracking exception
+            <b>[OPEN]</b> Should a request for a tracking exception
             apply to all subdomains of the first party making the request? Or
             should a first party explicitly list the subdomains that it's
             asking for? Similarly, should third-party subdomains be allowed
@@ -1589,6 +1592,28 @@
             "DNT:1E" where E means you are a first party with one or more 
             active exceptions.
           </p>
+          <p class="issue" data-number="151" title="User Agent Requirement: Be able to handle an exception request">
+            <b>[OPEN]</b> There is software that in just a few lines of code 
+            just spawn DNT;1 or DNT;0 headers regardless of user's will. A 
+            requirement on the user agent that they can handle the full 
+            exception mechanism will allow to discard compliance statements by 
+            those agents. It will 
+            also allow also the site to test for conformance by requiring an 
+            exception. In case the UA does not react on an exception request, 
+            the server could ignore DNT signals from that UA. It would allow 
+            thus testing from the horizon of the site without wild guessing;<br/>
+            However, there is no practical difference between a UA that hard-wires
+            'no' to all exception requests, and a UA that does not implement the 
+            calls.
+           </p>
+           <p class="issue" data-number="187" title="What is the right approach to exception handling?">
+            <b>[PENDING REVIEW]</b><br/>OLD: Site asks user agent for exception; user 
+            agent asks user and responds (UA is responsible to ensure that 
+            exceptions reflect user preferences)<br/>
+			NEW: Site asks user for their preference and stores this in user 
+			agent. User agent may double-check that this indeed matches preference 
+			but is not obliged to do so.
+           </p>
         </section>
       </section>
 
@@ -1977,13 +2002,6 @@
           trust without visiting that site.
         </p>
 
-        <p class="issue" data-number="140" title="Do we need site-specific exceptions, i.e., concrete list of permitted third parties for a site?">
-          <b>[PENDING REVIEW]</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. But all sites
-          are (a) told what they got granted (list, or *) and (b) are assured
-          that requests will be treated 'atomically'.
-        </p>
       </section>
 
       <section id="exceptions-no-js" class="informative">

Received on Tuesday, 12 February 2013 15:16:42 UTC