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

WWW/2011/tracking-protection/drafts combo-draft.html,1.1,1.2

From: Nick Doty via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 21 Jun 2012 16:38:00 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1ShkOO-00027j-Hg@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv8114

Modified Files:
	combo-draft.html 
Log Message:
updates from WG discussion

Index: combo-draft.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/combo-draft.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- combo-draft.html	19 Jun 2012 09:31:10 -0000	1.1
+++ combo-draft.html	21 Jun 2012 16:37:58 -0000	1.2
@@ -13,6 +13,8 @@
 	specStatus: "unofficial"
 	}
 	</script>
+		<link rel="stylesheet" href="additional.css" type="text/css"
+  media="screen" title="custom formatting for TPWG editors" charset="utf-8">
     </head>
 <body>
 
@@ -120,17 +122,26 @@
 
 	<section>
 		<h2>User Permission and Consent</h2>
-	  <p class="note"> We have discussed this at length in action-152, action-157, and action-159. This section attempts to merge several texts together.</p>
-	<p>
-	  Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so.</p>
-	  
-	  <p>A party may engage in practices otherwise prohibited by this standard if a user grants permission. When seeking an exemption, sites SHOULD communicate those requests clearly, accurately, and in line with consumer protection laws in the jurisdictions in which they operate. Permission may be attained through either (A) the browser API defined in the companion [[!TRACKING-DNT]] document or (B) an "out-of-band" consent attained through a different technology. An "out-of-band" choice mechanism has the same effect under this standard as the browser exception API. 
-
-	<p>A party may receive multiple conflicting signals from users. Specific permission overrides a general permission. If a party has received prior consent for tracking a given user, user agent, or device, that consent overrides the general preference indicated by the DNT header field. If a party chooses to track based on that prior consent, the corresponding tracking status MUST indicate that tracking is occurring based on consent and SHOULD supply a link to a means for the user to remove or modify that consent, as described in [[!TRACKING-DNT]].
-	For example, if you have two conflicting signals from a user with a global DNT:1 yet also have the user's consent specific to you (via browser API or out-of-band consent) then the user's consent is the correct signal to follow. 
-	</p>
+	  <p class="note"> We have discussed this at length in action-152, action-157, and action-159. This section attempts to merge several texts together.</p>	  
+	  <p>
+	    A party MAY engage in information practices otherwise prohibited by this recommendation if it has received explicit, informed consent from the user to do so, a <q>user-granted exception</q>. When seeking a user-granted exception, sites SHOULD communicate those requests clearly, accurately, and in line with applicable law. Permission may be attained through either (A) receiving a DNT:0 signal, (B) the browser API defined in the companion [[!TRACKING-DNT]] document or (C) consent attained "out-of-band". An "out-of-band" consent mechanism has the same effect under this standard as the browser exception API.
+	  </p>
+    <p class="note">
+      Still to be addressed, DNT permission if consent from before (via Terms of Service or other) applies. ISSUE?
+    </p>
+    <div class="option">
+      Possible texts to introduce the following paragraph:
+      <ul>      
+      <li>a party may receive multiple conflicting signals from users.</li> 
+  	  <li>out-of-band consent overrides an expressed dnt signal.</li>
+  	  <li>a party may engage [per above].</li>
+      </ul>    
+</div>
+  	<p>
+  	  If a party has received prior consent for tracking a given user, user agent, or device, that consent overrides the general preference indicated by the DNT header. If a party chooses to track based on that prior consent, the party MUST indicate that status, as described in [[!TRACKING-DNT]]. For example, if you have two conflicting signals from a user with a global DNT:1 yet also have the user's consent specific to you (via browser API or out-of-band consent) then the user's consent is the correct signal to follow.
+  	</p>
 
-	<p>An "out-of-band" choice mechanism MUST additionally satisfy the following condition: An ordinary user would know that the choice overrides his or her general Tracking Preference.</p>
+	<p>An "out-of-band" choice mechanism MUST additionally satisfy the following condition: A reasonable user would know that the choice overrides his or her general Tracking Preference.</p>
 		
 		<section class="informative">
 			<h3>Non-normative</h3>
@@ -211,10 +222,6 @@
   		</section> <!-- closes non-norm for aggregate data <h2> -->
   	</section> <!-- closes unidentifiable data <h2> -->
 
-
-
-
-
   <section id="discoverability">
 	<h2>Discoverability</h2>
 	<p class="note">While there is disagreement over whether discoverability is sufficient, we do seem to be converging on what discoverability is. Should we decide discoverability is not helpful, or insufficient, we can easily remove this section.</p>
@@ -264,7 +271,13 @@
 	</p>
 	
 	<p>
-	  A <a>first party</a> MUST NOT share information with a <a>third party</a> that the <a>third party</a> is prohibited from collecting itself. A <a>first party</a> MUST NOT <a>share</a> (send or receive) identifiable information about a user to any party it does not have an outsource relationship with. 
+	  A <a>first party</a> MUST NOT share information with a <a>third party</a> that the <a>third party</a> is prohibited from collecting itself. A <a>first party</a> MUST NOT <a>share</a> (send or collect) identifiable information about a user to any party it does not have an outsource relationship with. [reference to "outsource" definition]
+	  
+	  <p class="note">
+	  strawman: A first party MUST NOT share identifiable information about a user with any party with which it does not have an outsource relationship.<br/>
+	  core purpose: to prevent a first party as a loophole?<br/>
+	                other?<br/>
+	  </p>
 	</p> <!-- add links here for identifiable and outsource-->
 
 	<p class="note">While confining data just to the first party reflects discussions of the TPWG to date, newer members have concerns about these provisions.</p>
Received on Thursday, 21 June 2012 16:38:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:48:55 UTC