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

WWW/2011/tracking-protection/drafts tracking-compliance.html,1.72,1.73

From: Justin Brookman via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 27 Sep 2012 22:10:39 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1THMI3-0001Hb-4R@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv4872

Modified Files:
	tracking-compliance.html 
Log Message:
finished Wainberg's edits, clarified editors' notes

Index: tracking-compliance.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -d -r1.72 -r1.73
--- tracking-compliance.html	24 Sep 2012 03:11:49 -0000	1.72
+++ tracking-compliance.html	27 Sep 2012 22:10:37 -0000	1.73
@@ -376,11 +376,11 @@
    silo the data so that it cannot be accessed by other parties, and
    have no control over the use or sharing of that data except as directed by that party.
   	</section>
-  	<section class="option" id="def-service-providers-opt-3"><h3>Option 3: Service Provider/Outsourcer Definition</h3>
-<p class="note">Service Providers acting on the behalf of a First Party and with no independent rights to
+  	<section class="option" id="def-service-providers-opt-3"><h4>Option 3: Service Provider/Outsourcer Definition</h4>
+Service Providers acting on the behalf of a First Party and with no independent rights to
 use the First Party’s data outside of the context of that First Party and Permitted Uses are also
 considered to be acting as the First Party.
-.</p></section>
+</section>
 	</section>
 	
 	<section id="first-third-parties">
@@ -553,7 +553,7 @@
 clear branding and a link to their respective privacy policy (co-branded experience).
 </p>
 </section>
- <p class="issue" data-number="26" title="Providing data to 3rd-party widgets -- does that imply consent?"></p>
+<!-- <p class="issue" data-number="26" title="Providing data to 3rd-party widgets -- does that imply consent?"></p> -->
  
  </section>
 
@@ -597,7 +597,8 @@
 	
 	<section id="def-tracking">
 	<h3>Tracking</h3>
-	<p class="note">We have not had time to substantially edit the definitions of collection and tracking. These continue to be actively debated issues, as the resolution of the use of unique identifiers is likely to end up in these definitions.</p>
+	<p class="note">The term "tracking" is not used in the document.  This section is likely to be deleted, and the issues will be addressed in the definitions of 
+	"collection" and "unlinkable" above.</p>
 <!--
 		<p class="note"> We are still working through how, or if, to define tracking. Some suggest the phrase "cross-site tracking" only. We will need to ensure both final recommendations use the same terms in the same way, but may not explicitly define tracking.</p>
 -->
@@ -650,11 +651,17 @@
 
 <section id="first-party-compliance">
 <h3>First Party Compliance</h3>
-<p class="note">This language is still in flux, and may not yet allow third parties to do anything on a publisher site. <!-- (Justin to suggest edits) --></p>
+<p class="note">This language is not consensus and must change. The parties are generally agreed that this language should only prohibit first parties
+from enabling third parties to circumvent "Do Not Track" by providing them with correlatable cross-site data in a different context. There is
+an open debate about the extent to which this should prohibit "data append" practices, where first parties query data brokers about their users
+(and thus trasmit information to the brokers) order to augment their own records on users. <!-- (Justin to suggest edits) --></p>
 
 <p>If a First Party receives a network transaction to which a DNT:1 header is attached, First Parties may engage in their normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience. </p>
 
 <p>The First Party must not pass information about this transaction to non-service provider third parties who could not collect the data themselves under this Recommendation.  </p>
+
+<p class="issue" data-number="229" title="Draft crisp definition [of data append]"></p>
+
 </section>
 
 <section id="user-agent-compliance">
@@ -670,12 +677,16 @@
 
 <section id="third-party-compliance">
 <h3>Third Party Compliance</h3>
-<p class="note">We will be using this language as one of three or more options to evaluate for third party compliance.
-This section addresses the crux of what DNT is intended to accomplish, and as such, all of this section remains
-hotly debated.</p>
+<p class="note">This section addresses the crux of what DNT is intended to accomplish, and as such, all of this section remains
+hotly debated.  The specific language is likely to change.  See also alternative text proposed by Nick Doty:
+http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0141.html</p>
 
-<p>If the operator of a third-party domain receives a communication to which a DNT:1 header is attached:</p>
-<ol start="1"><li>that operator must not collect, share, or use information related to that communication outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;</li><li>that operator must not use information about previous communications in which the operator was a third party, outside of the explicitly expressed permitted uses as defined within this standard;</li><li>that operator may delete information about previous communications in which the operator was a third party, outside of the explicitly expressed permitted uses as defined within this standard.</li></ol>
+<p>If a third party receives a communication to which a DNT:1 header is attached:</p>
+<ol start="1"><li>that third party MUST NOT collect, share, or use information related to that communication outside of the permitted uses
+as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;</li>
+<li>that third party MUST NOT use information about previous communications in which it was a third party, outside of the permitted uses as
+defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;</li>
+<li>that third party MAY delete information about previous communications in which it was a third party.</li></ol>
 
 <!-- All these issues are listed as closed, so commenting them out for now
 <p class="issue" data-number="71" title="Does DNT also affect past collection or use of past collection of info?"></p>
@@ -691,7 +702,7 @@
 <p class="note">The term "Permitted Operational Uses" is used to indicate a restricted set of conditions under which tracking is allowed in spite of the user's DNT preference. The term user-granted exception is used when the user has permitted tracking, usually in the form of a site-specific exception, for a given third-party. In general: permitted uses are additional permissions granted by the standard; user-granted exceptions are additional permissions granted by the user. The words "exception" and "exemption" have occasionally been used interchangably and inconsistently by the editors; we are now trying to be consistent in using the terms <strong>"permitted (operational) use"</strong> and <strong>"user-granted exceptions"</strong>.</p>
 -->
 
-<p>If the operator of a third-party domain receives a communication to which a DNT:1 header is attached, that operator MAY nevertheless collect, use, and retain information related to that communication for these permitted uses:
+<p>If a third-party  receives a communication to which a DNT:1 header is attached, that third party MAY nevertheless collect, use, and retain information related to that communication for these permitted uses:
 <ul>
 <li>Short term collection and use, where information is not transmitted to a third party or used to profile or personalize a user's experience;</li>
 <li>Contextual content or ad delivery;</li>
@@ -751,7 +762,7 @@
 
 <section id="financial-logging">
 <h5>Financial Logging and Auditing</h5>
-<p class="note">for financial logging/ auditing, look to 3rd parties as 3rd parties</p>
+<!--<p class="note">for financial logging/ auditing, look to 3rd parties as 3rd parties</p> -->
 <p>Regardless of DNT signal, information may be collected, retained and used for financial fulfillment purposes such as billing and audit compliance.  This includes counting and verifying:<ul><li>ad impressions to unique visitors</li><li>clicks by unique visitors</li><li>subsequent action or conversion by unique visitors</li><li>quality measures such as ad position on sites and the sites on which the ads were served</li></ul></p>
 <p class="note">One potential compromise on the unique identifier issue for logging would be grandfather in existing contracts that require unique, cookie-based counting. New contracts would not be able to require that ad networks use cookies (or other unique identifiers) to uniquely count users who have DNT:1 enabled.</p>
 
@@ -764,7 +775,11 @@
 <h5>Security and Fraud Prevention</h5>
 <p>Regardless of DNT signal, information may be collected, retained and used for detecting security risks and fraudulent activity, defending from attacks and fraud, and maintaining integrity of the service.  This includes data reasonably necessary for enabling authentication/verification, detecting hostile transactions and attacks, providing fraud prevention, and maintaining system integrity. In this example specifically, this information may be used to alter the user's experience in order to reasonably keep a service secure or prevent fraud.</p>
 
-<p class="note">In Seattle, we discussed a compromise"graduated response" approach that allows third parties to retain data for a short period if no problems are apparent, and to use/retain longer only if there is reason to believe there is a problem.</p>
+<p class="note">The more likely options at this point may be represented in Nick Doty's proposed:<br><br>
+To the extent reasonably necessary for protection of computers and networks and to detect ad or other fraud, third parties may engage in tracking.
+Use of graduated response is preferred.<br><br>
+or David Wainburg's proposed<br><br>
+Parties may collect and use data in any way to the extent reasonably necessary for the detection and prevention of malicious or illegitimate activity.</p>
 
 <section class="informative" id="security-example"><h6>Examples</h6>
 <p class="note">Add examples with and without outsourced parties (J- not sure what this means)</p></section>
@@ -794,6 +809,8 @@
 
 <section class="option" id="pu-aggregate-opt-3"><h6>Option 3: No Aggregate Reporting</h6><p>There is no permitted use for aggregate reporting outside of the grace period described earlier.</p></section></section>
 
+<p class="issue" data-number="25" title="Possible exception for research purposes"></p>
+
 <!--
 <p class="note">Add examples once we pick an option.</p>
 -->
Received on Thursday, 27 September 2012 22:10:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 September 2012 22:10:40 GMT