WWW/2011/tracking-protection/drafts EditorsStrawmanComp.html,1.2,1.3

Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv29041

Modified Files:
	EditorsStrawmanComp.html 
Log Message:
Restructured 4.4

Index: EditorsStrawmanComp.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/EditorsStrawmanComp.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- EditorsStrawmanComp.html	2 Jul 2012 19:38:49 -0000	1.2
+++ EditorsStrawmanComp.html	3 Jul 2012 22:08:33 -0000	1.3
@@ -354,25 +354,36 @@
 made on the fly, and the information was only held ephemerally.</p></section></section>
 
 <section id="permitted-uses">
-<h3>Permitted uses for Third Parties and Service Providers</h3>
-<p class="note">{NOTE:Editor's note: This section is non-consensus text based on discussions in Seattle. Some text from existing pre-Seattle draft has also been used.</p>
-<p class="note">{NOTE:Seattle consensus: the following text is non-consensus text based on in depth discussion in Seattle. This reflects what chairs and editors believe substantive consensus was around overarching principles for permitted uses.</p>
+<h3>Permitted Operational Uses for Third Parties and Service Providers</h3>
+<p class="note">This section has been formatted, but I still need to rework all the language.<br><br> The scope of these exceptions and group consent for them is necessarily dependent upon the related question of how much information may be collected and retained for these uses (and whether they can be tied to unique identifiers).</p>
 
-<p>This section outlines potential permitted uses based on necessary operational/business use. </p>
 <p class="c0 c11"></p>
-<p class="note">{NOTE: The term permitted use 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. These words are often confused when drafting new text.</p>
+<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 inconsitently 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 class="informative">{NON-NORM:Non-normative explanatory text:  In order to avoid DNT significantly impacting the availability of free content on the Internet a balance is necessary to allow for minimal data use to continue standard site operations &ndash; including those that monetize site activities.</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 the permitted uses enumerated below:</p>
 
-<p>For each of the Permitted Uses outlined, the following requirements apply:</p>
-<ol start="1"><li>Each party engaging in Permitted Uses and claiming W3C DNT compliance, MUST provide public transparency of their data retention period</li></ol><ol start="1"><li class="c23 c0 c28">Party MAY enumerate each individually if they vary across Permitted Uses</li></ol><ol start="2"><li>Reasonable technical and organizational safeguards must be in place to prevent further processing. </li></ol><ol start="1"><li class="c23 c0 c28">[Note: While physical separation of data maintained for permitted uses is not  required, best practices should be in place to ensure technical controls ensure access limitations and information security.]</li></ol><ol start="3"><li>Outside of Security, data retained for Permitted Uses must not be used to alter a specific user's online experience based on multi-site activity. Customization outside of multi-site activity profiles is acceptable, but should be considered in light of DNT:1 signals.</li></ol><ol start="1"><li>Entities should ensure that data access and use isauditable. </li></ol><ol start="1"><li class="c23 c0 c28">[Editor's note: Whether or not the type of audit is mandated is still in discussion; an optional field exists in the TPE spec for auditors and self-regulatory commitments.]</li></ol><ol start="2"><li>Entities should publish their retention periods and specific permitted uses for which data is maintained. If necessary, the entity should explain why they retain data for permitted uses from DNT:1 transactions. Entities should maintain information for permitted uses only as long as necessary for that use; entities must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use be retained.</li></ol><ol start="1"><li class="c23 c0 c28">[Editor's note: May be worthwhile to put some examples in around when it is or isn't a good idea to explain use, ie, Commonly Accepted Practices vs. security data to address unique businesses]</li></ol><ol start="3"><li>Entities must not use data retained for permitted uses in fornon-permitted uses. Once the period of time for which you have declared data retention for a given use, the data must not be used for that permitted use. After there are no remaining permitted uses for given data, the data must be rendered out of scope of this draft.</li></ol><ol start="1"><li class="c23 c0 c28">[Note: Examples of rendering data out of scope are making it unidentifiable, not linked to identifiers, or deleted. Creating an aggregate report from the data prior to rendering the data out of scope is acceptable.]</li></ol><ol start="4"><li>In most cases, the user experience should not be altered using data maintained for permitted uses. </li></ol><ol start="1"><li class="c23 c0 c28">[Note: Telling a user that you have detected behavior that has triggered a security process is acceptable, as is non-covered data like city level geolocation.]</li><li class="c23 c0 c28">[Editor's note: Frequency capping and other content delivery may alter user experience as well, but are largely not based on individalized delivery.]</li></ol><p class="note">{NOTE:  While definitely a Permitted Use, compliance with local laws and public purposes, such as copyright protection and delivery of emergency services, is not listed separately. It is unclear whether this should be specified in the draft.</p>
-<h4>Security</h4>
-<p class="note">{NOTE:Editor's note: Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.</p>
-<p>Data MAY be collected, maintained and used for the express purpose of 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.</p>
-<p class="note">{NOTE: While it is hard to determine in advance what data will be needed for security and fraud protection, it is worth careful consideration how to best collect only useful information for these purposes.</p>
+<section id=enumerated-uses>
+<h4>Enumerated Uses</h4>
+
+<section id=contextual>
+<h5>Contextual Content or Ad Delivery</h5>
+
+<p class="note">To be added later</p></section>
+
+<section id="frequency-capping">
+<h5>Frequency Capping</h5>
+
+<p class="note">Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.</p>
+
+<p>Server-side frequency capping is allowed if the tracking identifier is only retained in a form that is unique to each super-campaign (e.g., one-way hashed with a campaign id) and does not include retention of the user's activity trail (page URIs on which the ads were delivered) aside from what is allowed for other permitted uses.</p>
+<p class="note">{NOTE:Editor's note: It's unclear whether this should be a highly specific permitted use, or more general guidelines around content delivery.</p>
+<p class="note">{NOTE: Data should not include a full URL trail for this permitted use, but rather simple campaign tracking.</p>
+
+<p class="informative">{NON-NORM:Non-normative explanatory text:  Restricting the number of times a user agent displays ads prevents a user from having to see repetitive ads, prevents publishers from displaying repetitive ads, and prevents advertisers from harming the reputation of their clients.  Examples of important data uses include, but are not limited to reach and frequency metrics, ad performance, logging the number and type of advertisements served on a particular Web site(s), and reporting.</p></section>
+
+<section id=financial-logging">
+<h5>Financial Logging and Auditing</h5>
 
-<p class="informative">{NON-NORM:Non-normative explanatory text: Restricting security and fraud detection and defense efforts could harm users.  We do not want to mistakenly turn Do Not Track into a signal for user vulnerability.</p>
-<h4>Financial Purposes</h4>
 <p class="note">{NOTE:Editor's note: Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.</p>
 
 <p>Data MAY be collected and used for the limited purpose of financial fulfillment such as billing and audit compliance.  This purpose is strictly necessary for the continued operation of most websites and requires uniqueness to prove user interactions (ad impression and ad click) were indeed achieved as billed for.</p>
@@ -380,32 +391,45 @@
 
 <p class="informative">{NON-NORM:Non-normative explanatory text: Typically all relevant advertising order criteria is necessary for retention of ad interactions.   </p>
 <p>Examples of data uses include, but are not limited to:</p>
-<ol start="1"><li>Ad Impression verification (CPM)</li><li>Ad Click verification (CPC)</li><li>Site Conversion associated with Ad Impression or Ad Click (CPA)</li><li class="c0 c1">Quality Measures such as ad position (location on page, above/below fold) and site the ad was served on (high quality vs. low quality content association)</li></ol><p></p>
-<h4>Frequency Capping</h4>
+<ol start="1"><li>Ad Impression verification (CPM)</li><li>Ad Click verification (CPC)</li><li>Site Conversion associated with Ad Impression or Ad Click (CPA)</li><li class="c0 c1">Quality Measures such as ad position (location on page, above/below fold) and site the ad was served on (high quality vs. low quality content association)</li></ol><p></p></section>
+
+<section id=security">
+<h5>Security and Fraud Prevention</h5>
+
 <p class="note">{NOTE:Editor's note: Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.</p>
-<p>Server-side frequency capping is allowed if the tracking identifier is only retained in a form that is unique to each super-campaign (e.g., one-way hashed with a campaign id) and does not include retention of the user's activity trail (page URIs on which the ads were delivered) aside from what is allowed for other permitted uses.</p>
-<p class="note">{NOTE:Editor's note: It's unclear whether this should be a highly specific permitted use, or more general guidelines around content delivery.</p>
-<p class="note">{NOTE: Data should not include a full URL trail for this permitted use, but rather simple campaign tracking.</p>
+<p>Data MAY be collected, maintained and used for the express purpose of 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.</p>
+<p class="note">{NOTE: While it is hard to determine in advance what data will be needed for security and fraud protection, it is worth careful consideration how to best collect only useful information for these purposes.</p>
+
+<p class="informative">{NON-NORM:Non-normative explanatory text: Restricting security and fraud detection and defense efforts could harm users.  We do not want to mistakenly turn Do Not Track into a signal for user vulnerability.</p></section>
+
+<section id=debugging>
+<h5>Debugging</h5>
 
-<p class="informative">{NON-NORM:Non-normative explanatory text:  Restricting the number of times a user agent displays ads prevents a user from having to see repetitive ads, prevents publishers from displaying repetitive ads, and prevents advertisers from harming the reputation of their clients.  Examples of important data uses include, but are not limited to reach and frequency metrics, ad performance, logging the number and type of advertisements served on a particular Web site(s), and reporting.</p>
-<h4>Product Debugging</h4>
 <p class="note">{NOTE:Editor's note: This is non-consensus text from Seattle meeting.</p>
 <p>Data MAY be collected and used for the limited purpose of identifying and repairing site errors to intended functionality (&ldquo;Debugging&rdquo;).  </p>
 <p class="note">{NOTE: While it is hard to determine in advance what data will be needed for product debugging, it is worth careful consideration how to best collect only useful information for these purposes. One approach may be a &lsquo;graduated response' strategy to retain data for a short period if no problems are apparent.</p>
 
-<p class="informative">{NON-NORM:Non-normative explanatory text: Detailed information is often necessary to replicate a specific user's experience to understand why their particular set of variables is resulting in a failure of expected functionality or presentation.  These variables could include items such as cookie IDs, page URLs, device or UA details, content specifics, and activity/event specifics to narrow in on the cause of the discrepancy.</p>
-<h4 class="c0 c18">Aggregate Reporting</h4>
+<p class="informative">{NON-NORM:Non-normative explanatory text: Detailed information is often necessary to replicate a specific user's experience to understand why their particular set of variables is resulting in a failure of expected functionality or presentation.  These variables could include items such as cookie IDs, page URLs, device or UA details, content specifics, and activity/event specifics to narrow in on the cause of the discrepancy.</p></section>
+
+<section id=aggregate-reporting>
+<h5>Aggregate Reporting</h5>
+
 <p class="note">{NOTE:Editor's note: Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.</p>
 
 <p>Data MAY be collected and used for the express and limited purpose of aggregate reporting.  Aggregate reporting end-points should meet the objectives of &ldquo;unlinkability&rdquo; (see below) and therefore are outside of the scope of the DNT standard.  There is a time interval necessary to retain event level records to aggregate across the necessary time spans accurately (daily, weekly, monthly, quarterly, etc.).  </p>
 
 <p class="note">{NOTE:Editor's note: It is unclear whether this paragraph needs to be here, especially given that there is debate over the period in which a party may use protocol information for any purpose.</p>
 <p>During the period in which a third party may use protocol information for any purpose, it may aggregate protocol information and un-linkable data into an un-linkable dataset. Such a dataset may be retained indefinitely and used for any purpose.</p>
-<p class="informative">{NON-NORM:Non-normative explanatory text: While detailed event level data is not present at the outcome of aggregated reporting it is a necessary ingredient to arrive there. Aggregate reporting may be used for many purposes, including but not limited to product improvement, analytics, visitor counts, market research.</p>
+<p class="informative">{NON-NORM:Non-normative explanatory text: While detailed event level data is not present at the outcome of aggregated reporting it is a necessary ingredient to arrive there. Aggregate reporting may be used for many purposes, including but not limited to product improvement, analytics, visitor counts, market research.</p></section></section>
+
+<section id=permitted-use-requirements>
+<h4>Additional Requirements for Permitted Uses</h4>
+
+<p>For each of the Permitted Uses outlined, the following requirements apply:</p>
+<ol start="1"><li>Each party engaging in Permitted Uses and claiming W3C DNT compliance, MUST provide public transparency of their data retention period</li></ol><ol start="1"><li class="c23 c0 c28">Party MAY enumerate each individually if they vary across Permitted Uses</li></ol><ol start="2"><li>Reasonable technical and organizational safeguards must be in place to prevent further processing. </li></ol><ol start="1"><li class="c23 c0 c28">[Note: While physical separation of data maintained for permitted uses is not  required, best practices should be in place to ensure technical controls ensure access limitations and information security.]</li></ol><ol start="3"><li>Outside of Security, data retained for Permitted Uses must not be used to alter a specific user's online experience based on multi-site activity. Customization outside of multi-site activity profiles is acceptable, but should be considered in light of DNT:1 signals.</li></ol><ol start="1"><li>Entities should ensure that data access and use isauditable. </li></ol><ol start="1"><li class="c23 c0 c28">[Editor's note: Whether or not the type of audit is mandated is still in discussion; an optional field exists in the TPE spec for auditors and self-regulatory commitments.]</li></ol><ol start="2"><li>Entities should publish their retention periods and specific permitted uses for which data is maintained. If necessary, the entity should explain why they retain data for permitted uses from DNT:1 transactions. Entities should maintain information for permitted uses only as long as necessary for that use; entities must make reasonable data minimization efforts to ensure that only the data necessary for the permitted use be retained.</li></ol><ol start="1"><li class="c23 c0 c28">[Editor's note: May be worthwhile to put some examples in around when it is or isn't a good idea to explain use, ie, Commonly Accepted Practices vs. security data to address unique businesses]</li></ol><ol start="3"><li>Entities must not use data retained for permitted uses in fornon-permitted uses. Once the period of time for which you have declared data retention for a given use, the data must not be used for that permitted use. After there are no remaining permitted uses for given data, the data must be rendered out of scope of this draft.</li></ol><ol start="1"><li class="c23 c0 c28">[Note: Examples of rendering data out of scope are making it unidentifiable, not linked to identifiers, or deleted. Creating an aggregate report from the data prior to rendering the data out of scope is acceptable.]</li></ol><ol start="4"><li>In most cases, the user experience should not be altered using data maintained for permitted uses. </li></ol><ol start="1"><li class="c23 c0 c28">[Note: Telling a user that you have detected behavior that has triggered a security process is acceptable, as is non-covered data like city level geolocation.]</li><li class="c23 c0 c28">[Editor's note: Frequency capping and other content delivery may alter user experience as well, but are largely not based on individalized delivery.]</li></ol><p class="note">{NOTE:  While definitely a Permitted Use, compliance with local laws and public purposes, such as copyright protection and delivery of emergency services, is not listed separately. It is unclear whether this should be specified in the draft.</p></section>
+
 </section>
 
-<section id="editors-notes-permitted">
-<h4>Editor's notes on issues raised around permitted uses</h4>
 <p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/24">ISSUE-24</a> : Possible permitted use for fraud detection and defense</p>
 <p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/25">ISSUE-25</a> : Possible permitted use for research purposes</p>
 <p>[Adherence to laws, legal and judicial process, regulations and so forth take precedence over this standard when applicable, but contractual obligations do not.</p>
@@ -414,7 +438,7 @@
 <p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/92">ISSUE-92</a> : If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking?</p>
 <p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/89">ISSUE-89</a> : Does DNT mean at a high level: (a) no customization, users are seen for the first time, every time. (b) DNT is about data moving between sites.</p>
 <p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/97">ISSUE-97</a>: Re-direction, shortened URLs, click analytics &amp;emdash; what kind of tracking is this?</p>
-</section>
+
 </section>
 <section id="user-granted-exceptions">
 <h2>User-Granted Exceptions</h2>

Received on Tuesday, 3 July 2012 22:08:38 UTC