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

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

Modified Files:
	EditorsStrawmanComp.html 
Log Message:


Index: EditorsStrawmanComp.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/EditorsStrawmanComp.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- EditorsStrawmanComp.html	28 Jun 2012 18:00:32 -0000	1.1
+++ EditorsStrawmanComp.html	2 Jul 2012 19:38:49 -0000	1.2
@@ -135,6 +135,8 @@
 	<p>This document is an editor's strawman reflecting a snapshot of live discussions within the <a href="http://www.w3.org/2011/tracking-protection/">Tracking Protection Working Group</a>. It does not yet capture all of our work. Text in white is typically closed: we have reached a consensus decision. Text in blue boxes presents options the group is considering. In some cases we are close to agreement, and in others we have more to discuss. An issue tracking system is available for recording <a href="http://www.w3.org/2011/tracking-protection/track/issues/raised">raised</a>, <a href="http://www.w3.org/2011/tracking-protection/track/issues/open">open</a>, <a href="http://www.w3.org/2011/tracking-protection/track/issues/pendingreview">pending review</a>, <a href="http://www.w3.org/2011/tracking-protection/track/issues/closed">closed</a>, and <a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a> issues regarding this document.</p>
 </section>
 
+<p class="note">This draft is a work-in-progress toward a Third Public Working Draft.  Until the Third Public Working Draft is finalized, this document should not be relied upon as an indicator of the status of consensus (or lack of consensus) among the working group.</p>
+
 <section id="introduction">
 <h2>Introduction</h2>
 	<p class="note">{NOTE:Editor's note: This introduction will be re-worked after details of substantive text is closer to being finalized.</p>
@@ -297,38 +299,61 @@
 
 <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>
 </section>
-
-<section id="def-service-provider">
-<h3>Service Provider to First Party</h3>
-<p>A party MUST NOT share (send or receive) collected data or profiles with another party (unless that party is ONLY working on the behalf of that specific party &ndash; aka Service Provider relationship).</p>
-<ol start="1"><li>Data collected by a 3rd party under a first party service provider relationship MUST be segregated according to the 1st party from which it was collected.  A 3rd party MUST NOT aggregate, correlate, or use together data that was collected on different 1st party sites.</li><li>3rd parties MUST NOT use data across multiple, non-affiliated websites.</li></ol></section>
-
-<section id="intermediary-compliance">
-<h3>Intermediary compliance</h3>
-<p class="note">{NOTE:Editor's note: This issue is being addressed in the <a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-TRACKING-DNT">TRACKING-DNT</a> specification. Explanatory text below is non-consensus.</p>
-<p>Compliance by intermediaries, such as ISPs, employer networks, and non-user agent software, is addressed in the [!!TRACKING-DNT] draft.</p>
+<section id="user-agent-compliance">
+<h3>User Agent Compliance</h3>
+<p>A user agent MAY offer a control to express a tracking preference to third parties.  The control MUST communicate the user's preference in accordance with the [[!!TRACKING-DNT]] recommendation and otherwise comply with that recommendation.  A user agent MUST NOT express a tracking preference for a user unless the user has interacted with the user agent in such a way as to indicate a tracking preference.</p>
+<p>We do not specify how tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled. For example, a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., "Privacy settings: high"). Likewise, a user might install or configure a proxy to add the expression to their own outgoing requests.</p>
+<p class="option">NOTE: Shane's proposal has suggested the additional compliance requirements of user agents:<br>1. A User Agent must obtain explicit, informed consent to turn on the DNT header<br>2. The User Agent must also make available via a link in explanatory text where DNT is enabled to provide more detailed information about DNT functionality<br>3. Any User Agent claiming compliance must have a functional implementation of the browser exceptions in this specification</p>
+</section>
+<section id="third-party-compliance">
 <h3>Third Party Compliance</h3>
-<p class="note">{NOTE:Editor's note: This section is based on draft text and significant discussions in Seattle.</p>
-<p class="note">{NOTE: This section consists of proposed text that is meant to address<a href="http://www.w3.org/2011/tracking-protection/track/issues/19"> ISSUE-19</a> and<a href="http://www.w3.org/2011/tracking-protection/track/issues/39"> ISSUE-39</a> and is pending discussion and [PENDING REVIEW]. - Heather to make sure that this is still true post-draft.</p>
-<p class="note">{NOTE: The following consists of proposed text that is meant to address<a href="http://www.w3.org/2011/tracking-protection/track/issues/71"> ISSUE-71</a> and is pending discussion and [PENDING REVIEW]. - Heather to make sure that this is still true post-draft.</p>
-<p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/71">ISSUE-71</a> : Does DNT also affect past collection or use of past collection of info?</p>
-<p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/19">ISSUE-19</a> : Data collection / Data use (3rd party)</p>
-<p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/88">ISSUE-88</a> : different rules for impression of and interaction with 3rd-party ads/content</p>
+<p class="note">NOTE: This language was the more general of the two previous options in the draft. The other text was more specific and prescriptive with regard to identifers --- this view is now presented as an option in the permitted collection and usage for operational use.</p>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/71">ISSUE-71</a>: Does DNT also affect past collection or use of past collection of info?</p>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/19">ISSUE-19</a>: Data collection / Data use (3rd party)</p>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/88">ISSUE-88</a>: different rules for impression of and interaction with 3rd-party ads/content</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 class="note">{NOTE:Editor's note: The following non-normative text is consensus text from the pre-Seattle draft, but may need to be changed or deleted in light of new edits. It is likely that the text itself will need editing.</p>
-<p class="informative">{NON-NORM:Non-normative explanatory text: It is acceptable to use data sent as part of this particular network interaction when composing a response to a [DNT-ON] request, but it is not acceptable to store that data any longer than needed to reply. For instance, it would be appropriate to use an IP address to guess which country a user is in in order to show only available services, or to target local personalization at a city level. It would be inappropriate to target at a zip+4 level or with a highly specific user profile.</p>
-<p>When using request-specific information to compose a reply, some levels of detail may feel invasive to users, and may violate their expectations about Do Not Track. These sorts of detailed assessments should be avoided.</p>
-
-<p>A third party may collect non-protocol information if it is, independent of protocol information, un-linkable data.</p>
-</section>
 
 <section id="geolocation">
 <h4>Geolocation compliance by a third party</h4>
-<p class="note">{NOTE:Editor's note: This section was part of existing pre-Seattle draft text, but may not be necessary anymore. It is still under debate, and may change sections as appropriate.</p>
+<p class="note">This section does not reflect group consensus.</p>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/39">ISSUE-39</a>: Tracking of geographic data (however it's determined, or used)</p>
 <p>If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached:</p>
-<ol start="1"><li>Geo-location information that is more granular than postal code is too granular. Geolocation data must not be used at any level more granular than postal code. Note that while the number of people living in a postal code varies from country to country, postal codes are extant world-wide.</li><li>If specific consent has been granted for the use of more granular location data, than that consent prevails.</li></ol><h3>User Agent Compliance</h3>
-<p class="note">{NOTE:Editor's note: While User Agent compliance is an actively debated topic, it was not a focus in Seattle. - Heather to find applicable issues to insert</p>
+<ol start="1"><li>Geo-location information that is more granular than postal code is too granular. Geolocation data must not be used at any level more granular than postal code. Note that while the number of people living in a postal code varies from country to country, postal codes are extant world-wide.</li><li>If specific consent has been granted for the use of more granular location data, than that consent prevails.</li></ol>
+<p><i>Non-normative text</i><br><p>It is acceptable to use data sent as part of this particular network
+interaction when composing a response to a [DNT-ON] request, but it is
+not acceptable to store that data any longer than needed to reply. For
+instance, it would be appropriate to use an IP address to guess which
+country a user is in, to avoid showing them an advertisement for
+products or services unavailable where they live.</p>
+
+<p>When using request-specific information to compose a reply, some
+levels of detail may feel invasive to users, and may violate their
+expectations about Do Not Track. These sorts of detailed assessments
+  should be avoided.</p>
+
+<p><i>Examples</i></p>
+<dl>
+<dt>Reasonable behavior<dd> 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
+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>In this example, even though the decision about which ad to serve was
+based exclusively on request specific information, but was still
+tailored to a highly-specific user profile. In particular, the
+estimation of a user's location to within a single ZIP+4 may make a
+user feel that they are being followed closely, even if the decision was
+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>

Received on Monday, 2 July 2012 19:38:53 UTC