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

WWW/2011/tracking-protection/drafts tracking-compliance.html,1.58,1.59

From: Heather West via cvs-syncmail <cvsmail@w3.org>
Date: Thu, 09 Aug 2012 01:07:42 +0000
To: public-tracking-commit@w3.org
Message-Id: <E1SzHDy-0003zV-Ma@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv15267/WWW/2011/tracking-protection/drafts

Modified Files:
	tracking-compliance.html 
Log Message:
Finished cleaning up notes and formatting

Index: tracking-compliance.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -d -r1.58 -r1.59
--- tracking-compliance.html	8 Aug 2012 21:25:38 -0000	1.58
+++ tracking-compliance.html	9 Aug 2012 01:07:40 -0000	1.59
@@ -705,14 +705,14 @@
 
 <section id="permitted-uses">
 <h3>Permitted Operational Uses for Third Parties and Service Providers</h3>
-
+<p class="note">These are options that have been discussed in the group. While many have broad consensus within the group, some are debated both based on scope of the draft and whether they should be permitted uses.</p>
 <!-- I think we've all internalized this one, so it can go
 <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:
 <ul>
-<li>Short term collection and use;</li>
+<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>
 <li>Content or Ad Delivery Based on First Party Data</li>
 <li>Frequency Capping</li>
@@ -729,133 +729,138 @@
 <li>Reasonable Security</li>
 <li>No Personalization</li>
 </ul>
-</p><p>These permitted uses are further discussed below.</p>
+</p><p>These permitted uses and requirements are further discussed below.</p>
 
-<section id=enumerated-uses>
+<section id="enumerated-uses">
 <h4>Enumerated Uses</h4>
 
-<section id=short-term>
+<section id="short-term">
 <h5>Short Term Collection and Use</h5>
+<p class="note">We have discussed allowing a N-week (anywhere from 1 week to 3 months) grace period where third parties could collect and use data, partly due to concerns , partly as a compromise to the market research/aggregate reporting issue. We do not have consensus on this permitted use at this point. If we decide to allow this, we would need to add non-normative text explaining the rationale and providing examples.</p>
+<p class="option">Information may be collected and used any purpose, so long as the information is retained for no longer than N weeks and the information is not transmitted to a third party and the information is not used to build a profile about a user or otherwise alter any individual's user experience (apart from changes that are made based on aggregate data or security concerns).</p>
+</section>
 
-<p class=option>For any purpose, so long as the information is retained for no longer than N weeks and the information is not transmitted to a third party and the information is not used to build a profile about a user or otherwise alter any individual's user experience (apart from changes that are made based on aggregate data).</p>
-
-<p class="note">We have discussed allowing a N-week (anywhere from 1 week to 3 months) grace period where third parties could collect and use data, partly due to concerns , partly as a compromise to the market research/aggregate reporting issue. We do not have consensus on this permitted use at this point. If we decide to allow this, we would need to add non-normative text explaining the rationale and providing examples.</p></section>
-
-<section id=contextual>
+<section id="contextual">
 <h5>Contextual Content or Ad Delivery</h5>
 <p class="note">Note that it is not clear that this is in scope, per Shane; others disagree. Revisit whether contextual belongs in some place other than permitted uses (potentially the definition of collection).
 </p>
-<p>For the display of contextual content or advertisements, including content or advertisements based on the first-party domain that the user visited.</p>
+<p class="option">Regardless of DNT signal, information may be collected, retained and used for the display of contextual content or advertisements, including content or advertisements based on the first-party domain that the user visited.</p>
 
-<p><i>Examples</i></p>
+<section class="informative" id="contextual-example"><h6>Examples</h6></section>
 
-<p class="informative"><ol><li>A user visits ExampleSports.com with DNT:1 enabled to read a news article about a baseball game.  ExampleSports uses the third party ExampleAds to serve ads on ExampleSports.com.  ExampleAds is not an outsourcing partner of ExampleSports, and often uses third-party behavioral data to serve targeted ads to users who have not enabled DNT:1.  ExampleAds may collect and use inforation about the user in order to render an advertisement (including IP address and information about the user agent) and information about the url of the news article in order to render an advertisement related to the baseball game.</li><br><li>A user visits ExampleLocalNews.com with DNT:1 enabled to read a news article about a local fire.  ExampleLocalNews uses the third party ExampleWeather to display a weather widget on its site.  ExampleWeather is not an outsourcing partner of ExampleLocalNews.  ExampleWeather may collect and user information about the user in order to render the weather widget (including IP address and information about the user agent) and information about the domain of the news site in order to render weather information related to the city which ExampleLocalNews reports on.</li><br></ol></p></section>
+<p><ol><li>A user visits ExampleSports.com with DNT:1 enabled to read a news article about a baseball game.  ExampleSports uses the third party ExampleAds to serve ads on ExampleSports.com.  ExampleAds is not an outsourcing partner of ExampleSports, and often uses third-party behavioral data to serve targeted ads to users who have not enabled DNT:1.  ExampleAds may collect and use information about the user in order to render an advertisement (including IP address and information about the user agent) and information about the url of the news article in order to render an advertisement related to the baseball game.</li><br><li>A user visits ExampleLocalNews.com with DNT:1 enabled to read a news article about a local fire.  ExampleLocalNews uses the third party ExampleWeather to display a weather widget on its site.  ExampleWeather is not an outsourcing partner of ExampleLocalNews.  ExampleWeather may collect and user information about the user in order to render the weather widget (including IP address and information about the user agent) and information about the domain of the news site in order to render weather information related to the city which ExampleLocalNews reports on.</li><br></ol></p></section>
 
-<section id=first-party-data>
+<section id="first-party-data">
 <h5>Content or Ad Delivery Based on First Party Data</h5>
 <p class="note">Note that it is not clear that this is in scope, per Shane; others disagree. Revisit whether contextual belongs in some place other than permitted uses (potentially the definition of collection).
 </p>
-<p class="option">For the display of content or advertisements based in part of data that the third party previously collected from the user when acting as a first party.</p>
+<p class="option">Regardless of DNT signal, information may be collected, retained and used for the display of content or advertisements based in part of data that the third party previously collected from the user when acting as a first party.</p>
 
-<p class="informative"><i>Examples</i><br><ol><li>A user visits ExampleNews.com with DNT:1 enabled to read a story about a national election.  ExamplesNews uses the third party ExamplePortal to serve content and advertisements on its site.  ExamplePortal is not an outsourcing partner of ExampleNews.  The user had previously visited ExamplePortal.com with DNT:1 enabled and read several stories about golf.  ExamplePortal may serve an advertisement related to golf to that same user on ExampleNews.  However, ExamplePortal may not use the fact that user went to ExampleNews to add to the user's ExamplePortal profile, and may only retain and use information about that fact for a permitted operational use.</li><br><li>A user visits Example Music with DNT:1 enabled to listen to recently released albums streamed online.  Example Music uses the third party Example Social to provide a widget that shows users what their Example Social friends have done on ExampleMusic.  ExampleSocial is not an outsourcing partner of ExampleMusic.  The user is a member of ExampleSocial and has several friends who also share information about what they do on ExampleMusic on ExampleSocial. ExampleSocial may display information that the users' friends had shared on ExampleSocial related to ExampleMusic within its third-party widget on ExampleMusic.  However, ExampleSocial may not use the fact that user went to ExampleMusic to add to the user's ExampleSocial profile, and may only retain and use information about that fact for a permitted operational use.</li></ol></p></section>
+<section class="informative" id="first-party-example"><h6>Examples</h6><p><ol><li>A user visits ExampleNews.com with DNT:1 enabled to read a story about a national election.  ExamplesNews uses the third party ExamplePortal to serve content and advertisements on its site.  ExamplePortal is not an outsourcing partner of ExampleNews.  The user had previously visited ExamplePortal.com with DNT:1 enabled and read several stories about golf.  ExamplePortal may serve an advertisement related to golf to that same user on ExampleNews.  However, ExamplePortal may not use the fact that user went to ExampleNews to add to the user's ExamplePortal profile, and may only retain and use information about that fact for a permitted operational use.</li><br><li>A user visits Example Music with DNT:1 enabled to listen to recently released albums streamed online.  Example Music uses the third party Example Social to provide a widget that shows users what their Example Social friends have done on ExampleMusic.  ExampleSocial is not an outsourcing partner of ExampleMusic.  The user is a member of ExampleSocial and has several friends who also share information about what they do on ExampleMusic on ExampleSocial. ExampleSocial may display information that the users' friends had shared on ExampleSocial related to ExampleMusic within its third-party widget on ExampleMusic.  However, ExampleSocial may not use the fact that user went to ExampleMusic to add to the user's ExampleSocial profile, and may only retain and use information about that fact for a permitted operational use.</li></ol></p></section></section>
 
 <section id="frequency-capping">
 <h5>Frequency Capping</h5>
+<p>Regardless of DNT signal, information may be collected, retained and used for limiting the number of times that a user sees a particular advertisement, often called "frequency capping".</p>
+<p class=option>In Seattle, we discussed specifically limiting how data was stored for frequency capping.<br><br>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>For limiting the number of times that a user sees a particular advertisement.</p>
-
-<p><i>Example</i></p>
 
-<p class="informative">A user visits ExampleNews with DNT:1 enabled.  ExamplesNews uses the third party ExampleAds to serve content and advertisements on its site.  ExampleAds is not an outsourcing partner of ExampleNews.  ExampleAds has previously shown the user an ad for ExampleCars fives times in the past week on other sites.  ExampleCars' contract with Example Ads states that Example Ads will be paid less for impressions where the user sees an ad more than five times in a week.  ExampleAds may opt not to show the user the ad for ExampleCars because the user has already seen the ad five times on other sites.</p>
+<Section class="informative" id="frequency-capping-example"><h6>Examples</h6>
+<p>A user visits ExampleNews with DNT:1 enabled.  ExamplesNews uses the third party ExampleAds to serve content and advertisements on its site.  ExampleAds is not an outsourcing partner of ExampleNews.  ExampleAds has previously shown the user an ad for ExampleCars fives times in the past week on other sites.  ExampleCars' contract with Example Ads states that Example Ads will be paid less for impressions where the user sees an ad more than five times in a week.  ExampleAds may opt not to show the user the ad for ExampleCars because the user has already seen the ad five times on other sites.</p></section></section>
 
-<p class=option>In Seattle, we discussed specifically limiting how data was stored for frequency capping.<br><br>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></section>
 
 <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>For financial fulfillment purposes such as billing and audit compliance.  This includes counting and verifiying:<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><i>Examples</i></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>
+
<section class="informative" id="financial-logging-example"><h6>Examples</h6>
 
 <p class="note">Add examples for display verification, click verification, CPA, quality measures</p></section>
-
-<p class=option>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>
+</section>
 
 <section id="security">
 <h5>Security and Fraud Prevention</h5>
-<p>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.</p>
+<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>
 
+<!-- Someone credited this to me (Heather) and it's definitely not from me, so I'm removing it until we have a proposal there
 <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><i>Examples</i></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>
+</section>
 
-<section id=debugging>
+<section id="debugging">
 <h5>Debugging</h5>
 
-<p>For identifying and repairing errors that impair existing intended functionality.</p>
+<p>Regardless of DNT signal, information may be collected, retained and used for identifying and repairing errors that impair existing intended functionality.</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="informative">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>
-
-<p><i>Example</i></p>
+<section class="informative" id="debugging-discussion"><h6>Discussion</h6>
+<p>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>
 
-<p>A user visits ExampleBlog with DNT:1 enabled.  Example News uses the third party ExampleAds to serve content and advertisements on its site.  ExampleAds is not an outsourcing partner of ExampleBlog.  ExampleAds retains [to be determined data fields] in order to later replicate users' experiences in receiving its ads to subsequently diagnose problems and understand why their particular set of variables resulted in a failure of expected functionality or presentation.</p>
+<section class="informative" id="debugging-example"><h6>Examples</h6>
+<p>A user visits ExampleBlog with DNT:1 enabled.  Example News uses the third party ExampleAds to serve content and advertisements on its site.  ExampleAds is not an outsourcing partner of ExampleBlog.  ExampleAds retains [to be determined data fields] in order to later replicate users' experiences in receiving its ads to subsequently diagnose problems and understand why their particular set of variables resulted in a failure of expected functionality or presentation.</p></section></section>
 
-<section id=aggregate-reporting>
+<section id="aggregate-reporting">
 <h5>Aggregate Reporting</h5>
 
+<!--
 <p class="note">Text is based on breakout group discussion, and large group presentation, at the Seattle meeting.  However, there is not group consensus that this should be a permitted operational use.</p>
+-->
 
-<p class=option>For aggregate reporting, such as market research and product improvement.  Data MAY be collected and retained on an individual level, but the use of the data must only be aggregate reporting, and the products of the reporting MUST be unlinkable as defined in this document.</p>
+<section class="option" id="pu-aggregate-opt-1"><h6>Option 1: Aggregate Reporting</h6><p>Regardless of DNT signal, information may be collected, retained and used for aggregate reporting, such as market research and product improvement.  Data MAY be collected and retained on an individual level, but the use of the data must only be aggregate reporting, and the products of the reporting MUST be unlinkable as defined in this document.</p></section>
 
-<p class=option>For aggregate reporting, such as market research and product improvement, if that information is collected and retained for another enumerated permitted use. Data MAY be collected and retained on an individual level, but the use of the data must only be aggregate reporting, and the products of the reporting MUST be unlinkable as defined in this document. If the operator no longer has another enumerated permitted use for which to use and retain the data, the operator MAY NOT use and retain the data for aggregat reporting unless the data has been rendered unlinkable as defined in this document.</p>
+<section class="option" id="pu-aggregate-opt-2"><h6>Option 2: Aggregate Reporting</h6><p>Regardless of DNT signal, information may be collected, retained and used for aggregate reporting, such as market research and product improvement, if that information is collected and retained for another enumerated permitted use. Data MAY be collected and retained on an individual level, but the use of the data must only be aggregate reporting, and the products of the reporting MUST be unlinkable as defined in this document. If the operator no longer has another enumerated permitted use for which to use and retain the data, the operator MAY NOT use and retain the data for aggregate reporting unless the data has been rendered unlinkable as defined in this document.</p></section>
 
-<p class=option>No permitted use for aggregate reporting outside of the grace period described earlier.</p>
+<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="note">Add examples once we pick an option.</p></section>
+<!--
+<p class="note">Add examples once we pick an option.</p>
+-->
 
-<section id=compliance>
+<section id="compliance">
 <h5>Compliance With Local Laws and Public Purposes</h5>
+<p class=note>The group has generally agreed that companies can collect and process data as required by local law despite the DNT:1 signal and still comply with this standard.  We have also conceptually agreed that companies cannot exploit this language by creating contractual requirements between companies to collect data as a "legally required" basis for the collection and use of data despite a DNT:1 signal.</p>
+<p>Regardless of DNT signal, information may be collected, retained and used for complying with local laws and public purposes, such as copyright protection and delivery of emergency services.</p>
+</section></section>
 
-<p>For complying with local laws and public purposes, such as copyright protection and delivery of emergency services.</p>
-
-<p class=note>This language has not been vetted or debated, but the group has generally agreed that companies can collect and process data as required by local law despite the DNT:1 signal and still comply with this standard.  We have also conceptually agreed that companies cannot exploit this language by creating contractual requirements between companies to collect data as a "legally required" basis for the collection and use of data despite a DNT:1 signal.</p></section></section>
-
-<section id=permitted-use-requirements>
+<section id="permitted-use-requirements">
 <h4>Additional Requirements for Permitted Uses</h4>
+<p>In order to use the Permitted Uses outlined, a party must comply with these four requirements.</p>
 
-<p>For each of the Permitted Uses outlined, the following requirements apply:</p>
-
-<section id=no-secondary-uses>
+<section id="no-secondary-uses">
 <h5>No Secondary Uses</h5>
 <p>Third Parties MUST NOT use data retained for permitted uses for non-permitted uses.</p></section>
 
-<section id=data-minimization-and-transparency>
+<section id="data-minimization-and-transparency">
 <h5>Data Minimization and Transparency</h5>
-<p>A third party MUST ONLY retain information for a Permitted Use for as long as is reasonably necessary for that use.  Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permittted use is retained.  A third party MUST provide public transparency of their data retention period. The third party MAY enumerate each individually if they vary across 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 deleted or rendered unlinkable.</p>
+<p>A third party MUST ONLY retain information for a Permitted Use for as long as is reasonably necessary for that use.  Third parties MUST make reasonable data minimization efforts to ensure that only the data necessary for the permitted use is retained.  A third party MUST provide public transparency of their data retention period. The third party MAY enumerate each individually if they vary across 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 deleted or rendered unlinkable.</p>
 
 <p class="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</p></section>
 
-<section id=reasonable-security>
+<section id="reasonable-security">
 <h5>Reasonable Security</h5>
 
 <p>Third parties MUST use reasonable technical and organizational safeguards to prevent further processing of data retained for Permitted Uses. 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. Third parties SHOULD ensure that the access and use of data retained for Permitted Uses is auditable.</p>
 
-<p class="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.</p></section>
+<p class="note">Whether or not an audit, or the type of audit, is mandated is still in discussion; an optional field exists in the TPE spec for auditors and self-regulatory commitments. The audit section of the TPE should be cross-referenced here.</p></section>
 
-<section id=no-personalization>
+<section id="no-personalization">
 <h5>No Personalization</h5>
 
 <p>Outside of Security and Frequency Capping, data retained for Permitted Uses MUST NOT be used to alter a specific user's online experience based on multi-site activity.</p></section><br>
 
+<!--
 <p class="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"><a href="http://www.w3.org/2011/tracking-protection/track/issues/25">ISSUE-25</a> : Possible permitted use for research purposes</p>
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/75">ISSUE-75</a> : How do companies claim permitted uses and is that technical or not?</p>
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/31">ISSUE-31</a> : Minimization -- to what extent will minimization be required for use of a particular permitted use? (conditional permitted uses)</p>
 <p class="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"><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"><a href="http://www.w3.org/2011/tracking-protection/track/issues/97">ISSUE-97</a>: Re-direction, shortened URLs, click analytics -- what kind of tracking is this?</p></section></section>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/97">ISSUE-97</a>: Re-direction, shortened URLs, click analytics -- what kind of tracking is this?</p>
+-->
+</section></section>
 <section id="geolocation">
 <h4>Geolocation compliance by a third party</h4>
 <p class="note">Unclear whether this section reflects group consensus.</p>
@@ -881,18 +886,19 @@
   should be avoided.</p>
 
 <section class="informative" id="geo-examples"><h3>Examples</h3>
-<dl>
-<dt>Reasonable behavior<dd> A user visits you from an IP address which a
+<!-- It has been raised that the invasive example here may be getting into UI territory. -->
+<p>Reasonable behavior: A user visits you from an IP address which a
 general geo-IP database suggests is in the NYC area, where it is 6pm on
 a Friday. You choose to show an advertisement for theaters and
-restaurants in the area.
-<dt>Invasive behavior<dd> A user visits you from an IP address which
+restaurants in the area.</p>
+<p>Invasive behavior: A user visits you from an IP address which
 suggests that they are in a particular ZIP+4, which has a distinctive
 demographic profile. Their user-agent indicates that they are a Mac
 user, further narrowing their expected profile. You serve them an ad
 for business within a few blocks of them which specializes in items
 which their expected profile indicates they may enjoy.
-</dl>
+</p>
+
 
 <p>In this example, even though the decision about which ad to serve was
 based exclusively on request specific information, but was still
@@ -908,13 +914,17 @@
 
 <p>The operator of a website may engage in practices otherwise described by this standard if the user has given explicit and informed consent. This consent may be obtained through the browser API defined in the companion [[!!TRACKING-DNT]] document, or an operator of a website may also obtain "out-of-band" consent to disregard a "Do Not Track" preference using a different technology. If an operator is relying on "out of band" consent to disregard a "Do Not Track" instruction, the operator must indicate this consent to the user agrent as described in the companion [[!!TRACKING-DNT]] document.</p>
 
+<!--
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/83">ISSUE-83</a> : How do you opt out if already opted in? - pretty sure this belongs in the technical spec</p>
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/67">ISSUE-67</a> : Should opt-back-in be stored on the client side? - pretty sure this belongs in the technical spec</p>
+-->
 
 
 <section id="interactions">
 <h3>Interaction with existing user privacy controls</h3>
+<!--
 <p class="note">There may be text on this somewhere, from Seattle meeting</p>
+-->
 
 <p>Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out signals at the same time, it'll be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.</p>
 <p>As a general principle, more specific settings override less specific settings.</p>
@@ -926,14 +936,16 @@
 <p class="note">Add note that we may be able to handle this section entirely within the consent definition, rather than calling it out; potentially thought an example in the consent section. Concern about UI creep.</p>
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/65">ISSUE-65</a> : How does logged in and logged out state work</p>
 
+<!--
 <p class="note">I believe we have consensus that the spec should be silent on the relevance of "logged-in" versus "logged-out" state.  I am deleting the various options on this issue, but we can revisit if people object.</p>
+-->
 
 </section></section>
 
-<section id=bad-UA>
+<section id="noncompliant-UA">
 <h3>Disregarding Non-Compliant User Agents</h3>
-<p class="note">Add note about the state of discussion here, potentially reorder the options, and options to address this in TPE and response header, with silence in the compliance doc; Issue 65/93 results here? Check
-</p>
+<p class="note">this section is the topic of active debate.</p>
+
 <p class=option>Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly formed even if the third party does not believe that the DNT:1 header was set with the explicit and informed consent of the user.</p>
 <p class=option>If the operator of a third-party domain has a good faith belief that a user agent is sending a DNT:1 without the explicit and informed consent of the user, the operator MAY disregard the DNT:1 header and collect, use, and retain information about the user as if no DNT signal had been sent.  If the operator disregards the DNT signal, the operator MUST signal to the user agent that it is disregarding the header as described in the companion [[!!DNT-TRACKING]] document.</p>
 <p class=option>No provision on Disregarding Non-Compliant User Agents.</p></section>
@@ -941,13 +953,13 @@
 <section id="degrade">
 <h3>Degrading User Experience for DNT:1 users</h3>
 
-<p class="note">I thought we had consensus that it's fine to degrade the experience for DNT:1 transactions, but need to find the text.</p>
+<p class="note">We have consensus that it's fine to degrade the experience for DNT:1 transactions, but need to find the text.</p>
 
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/93">ISSUE-93</a> : Should 1st parties be able to degrade a user experience or charge money for content based on DNT?</p>
 </section>
 
-<section id="enforcement">
-<h3>Public Discosure of Compliance</h3>
+<section id="compliance-statement">
+<h3>Public Disclosure of Compliance</h3>
 <p class="note">Final wording awaits how the response is designed in the <a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-TRACKING-DNT">TRACKING-DNT</a> recommendation, but we agree upon the general direction below.</p>
 <p>In order to be in compliance with this specification, a third party must make a public commitment that it complies with this standard. A "public commitment" may consist of a statement in a privacy policy, a response header, a machine-readable tracking status resource at a well-known location, or any other reasonable means. This standard does not require a specific form of public commitment.</p>
 
@@ -955,7 +967,9 @@
 <h4>Third Party Auditing</h4>
 <p class="note">Add reference to TPE, or potentially move to TPE; add reference to audit array from Action 219</p>
 <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/21">ISSUE-21</a> : Enable external audit of DNT compliance</p>
+<!--
 <p class="note">We have reviewed one audit proposal that we declined to adopt as mandatory, but there is significant support to include a flexible option to enable auditing. We may include a smaller-scoped proposal in the future, or may drop auditing all together.</p>
+-->
 </section></section>
 </section></section>
 <section id="acknowledgements">
Received on Thursday, 9 August 2012 01:07:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 August 2012 01:07:45 GMT