- From: Heather West via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 08 Aug 2012 21:25:40 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv31312/WWW/2011/tracking-protection/drafts
Modified Files:
tracking-compliance.html
Log Message:
Midpoint in updating: cleaning up notes, readability edits. Will finish this evening.
Index: tracking-compliance.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -d -r1.57 -r1.58
--- tracking-compliance.html 6 Aug 2012 19:27:24 -0000 1.57
+++ tracking-compliance.html 8 Aug 2012 21:25:38 -0000 1.58
@@ -127,7 +127,7 @@
</section>
<section id="sotd">
- <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>
+ <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 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>
@@ -155,18 +155,24 @@
<section id="definitions">
<h2>Definitions</h2>
+<!--
<p class="note">The definitions section is a strawman proposal from editors based on discussion in Seattle. Many sections are not yet consensus text.</p>
+-->
<section id="def-user">
<h3>User</h3>
+<!--
<p class="note">This definition is consensus or near-consensus text from the pre-Seattle draft.</p>
+-->
<p>A user is an individual human. When user-agent software accesses online resources, whether or not the user understands or has specific knowledge of a particular request, that request is made "by" the user.</p>
</section>
<section id="def-user-agent">
<h3>User Agent</h3>
+<!--
<p class="note">This definition is consensus or near-consensus text from the pre-Seattle draft, but there may be some debate on the definition.</p>
+-->
<p>This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including but not limited to browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [<a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-HTTP11">HTTP11</a>].</p>
</section>
@@ -174,7 +180,12 @@
<section id="def-parties">
<h3>Parties</h3>
+<!--
<p class="note">Dsinger has asked to add something about the responsibility following the data</p>
+-->
+<!-- I have shuffled this language around for clarity and simplicity, but it should retain the same meaning. Previous language retained in comments. -->
+A <dfn>party</dfn> is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person which acts as a functional entity. A set of functional entities is considered affiliated when they are related by both common majority ownership and common control, and affiliation is made easily discoverable by a user.
+<!--
A <dfn>functional entity</dfn> is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.
<br/><br/>
Functional entities are <dfn>affiliated</dfn> when they are related by both common majority ownership and common control.
@@ -182,6 +193,7 @@
A <dfn>party</dfn> is a set of functional entities that are affiliated.
<section>
+<!--
<h2>Transparency</h2>
<p class="note">This section is at best out of place, and should be in the compliance section, not definitions.</p>
<section>
@@ -190,16 +202,30 @@
</section>
<section>
<h2>Non-Normative Discussion</h2>
-<p class="informative">Affiliation may be made easily discoverable by prominent and common branding by a functional entity of affiliation on its webpages, within a privacy policy linked from its webpages, or a machine-readable format in a well-known location.</p>
-</section></section>
+<p class="informative">Affiliation may be made easily discoverable by prominent and common branding by a functional entity of affiliation on its webpages, within a privacy policy linked from its webpages, or a machine-readable format in a well-known location.</p>
+-->
+<!--<h2>Affiliated Parties</h2>
+<p class="note">I changed this text to reflect that it's a definition of affiliated parties, but should retain the requirement that an affiliated party must be discoverable in order to be considered affiliated under this draft.</p>
+<section>
+<h2>Requirement</h2>
+A <a>functional entity</a> must make its <a>affiliated</a> functional entities easily discoverable by a user.
+</section>
+<section>
+<h2>Non-Normative Discussion</h2>
+<p class="informative">Affiliation may be made easily discoverable by prominent and common branding by a functional entity of affiliation on its webpages, within a privacy policy linked from its webpages, or a machine-readable format in a well-known location.</p>
+-->
+
+</section>
<section id="def-service-providers">
<h4>Service Providers/Outsourcers</h4>
- <p class="note">This section was taken largely from the combo draft Aleecia shared is Seattle, which was based an expansion of the Mayer pre-Seattle draft to allow for outsourcing by both first and third parties. I am not sure there is consensus around this proposal.</p>
-<p class="note">Definition of service provider needs to be reworked (AI: http://lists.w3.org/Archives/Public/public-tracking/2012Mar/0001.html,http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0462.html); put various options into the document. Seemed to have consensus in theory but not in language.</p>
-<p class="note">Ensure that third party can act as a third party, or as a first party within section</p>
-<p class="note">hwest to propose an alternative definition of first party (based on ownership? alternative to inference?) [recorded in http://www.w3.org/2012/07/11-dnt-minutes.html#action01]</p>
+<p class="note">We seem to have consensus in theory but not in language for the definition of a service provider.</p>
+<!-- <p class="note">Ensure that third party can act as a third party, or as a first party within section</p>
+<p class="note">hwest to propose an alternative definition of first party (based on ownership? alternative to inference?) [recorded in http://www.w3.org/2012/07/11-dnt-minutes.html#action01]</p> -->
+
+<section class="option" id="def-service-providers-opt-1"><h3>Option 1: Service Provider/Outsourcer Definition</h3>
+<p class="note">This option contains both definitions and normative compliance requirements.</p>
<p>This section applies to parties engaging in an outsourcing relationship, wherein one party "stands in the shoes" of another party to perform a specific task. Both parties have responsibilities, as detailed below.</p>
@@ -389,7 +415,14 @@
</p>
</section> <!-- closes contract, h3 -->
</section> <!-- closes first or third party requirements, h2 -->
- </section></section>
+ </section>
+ <section class="option" id="def-service-provider-opt-2">
+<h4>Option 2: Service Provider/Outsourcer Definition</h4> Outsourced service providers are considered to be the same
+ party if they only act as data processors on behalf of that party,
+ silo the data so that it cannot be accessed by other parties, and
+ have no control over that data except as directed by that party.
+ </section>
+ </section>
<section id="first-third-parties">
<h3>First and Third Parties</h3>
@@ -407,11 +440,10 @@
</section>
<section class="informative">
-<h2>Non-Normative Discussion</h2>
+<h2>Discussion</h2>
<section>
<h2>Overview</h2>
-
<p>We draw a distinction between those parties an ordinary user would
or would not expect to share information with, "first parties" and
"third parties" respectively. The delineation exists for three
@@ -555,53 +587,64 @@
<section id="def-unlinkable">
<h3>Unlinkable Data</h3>
- <p class="note">There is debate about whether to use the terms unlinkable, unlinked, or unidentified to describe this type of data.</p>
- <p class="note">Unstable, but established options. Make sure text/discussion from Bellevue is captured in the document.</p>
-<p class="note">Add an option to limit use of unlinkable data, since it’s a broader exception, per jmayer</p>
- <p class=option>A party render a dataset <dfn>unlinkable</dfn> when it<br>1. takes commercially reasonable steps have been taken to de-identify data such that there is confidence that it contains information which could not be linked to a specific user, user agent, or device in a production environment<br>2. publicly commits to retain and use the data in unlinkable fashion, and not to attempt to re-identify the data<br>3. contracually prohibits any third party that it transmits the unlinkable data to from attempting to re-identify the data. Parties SHOULD provide transparency to their delinking process (to the extent that it will not provided confidential details into security practices) so external experts and auditors can assess if the steps are reasonably given the particular data set.</p>
- <p class=option>A dataset is <dfn>unlinkable</dfn> when there is a high probability that it contains only information that could not be linked to a particular user, user agents, or device by a skilled analyst. A party renders a dataset unlinkable when either:<br>1. it publicly publishes information that is sufficiently detailed for a skilled analyst to evaluate the implementation, or<br>2. ensure that the dataset is at least 1024-unlinkable.</p>
+ <p class="note">There is debate about whether to use the terms unlinkable, unlinked, or unidentified to describe this type of data.
+ <!-- <p class="note">JMayer would like an option that limits use of unlinkable data, but that should be in the compliance sections.</p> -->
+ <section class="option"><h4>Option 1: Unlinkable Data</h4>
+ <p>A party render a dataset <dfn>unlinkable</dfn> when it<br>1. takes commercially reasonable steps have been taken to de-identify data such that there is confidence that it contains information which could not be linked to a specific user, user agent, or device in a production environment<br>2. publicly commits to retain and use the data in unlinkable fashion, and not to attempt to re-identify the data<br>3. contracually prohibits any third party that it transmits the unlinkable data to from attempting to re-identify the data. Parties SHOULD provide transparency to their delinking process (to the extent that it will not provided confidential details into security practices) so external experts and auditors can assess if the steps are reasonably given the particular data set.</p></section>
+ <section class="option"><h4>Option 2: Unlinkable Data</h4>
+ <p>A dataset is <dfn>unlinkable</dfn> when there is a high probability that it contains only information that could not be linked to a particular user, user agents, or device by a skilled analyst. A party renders a dataset unlinkable when either:<br>1. it publicly publishes information that is sufficiently detailed for a skilled analyst to evaluate the implementation, or<br>2. ensure that the dataset is at least 1024-unlinkable.</p></section>
</section>
<section id="def-network-transaction">
<h3>Network Transaction</h3>
+<!--
<p class="note">This definition is consensus or near-consensus text from the pre-Seattle draft.</p>
+-->
<p>A "network interaction" is an HTTP request and response, or any other sequence of logically related network traffic.</p>
<p class="informative">Non-normative explanatory text: Determination of a party's status is limited to a single interaction because a party's status may be affected by time, context, or any other factor that influences user expectations.</p>
</section>
<section id="def-transactional-data">
<h3>Transactional data</h3>
+<!--
<p class="note">This definition is consensus or near-consensus text from the pre-Seattle draft. However, it is unclear that it is necessary to the document.</p>
+-->
<p>Transactional data is information about the user's interactions with various websites, services, or widgets which could be used to create a record of a user's system information, online communications, transactions and other activities, including websites visited, pages and ads viewed, purchases made, etc.</p>
</section>
<section id="def-collection">
<h3>Data collection, retention, use, and sharing</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">Still contention around these definitions. Get all the options into the doc.</p>
+-->
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/16">ISSUE-16</a> : What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.)</p> <ol start="1"><li>A party "collects" data if the data comes within its control.</li><li>A party "retains" data if data remains within a party's control.</li><li>A party "uses" data if the party processes the data for any purpose other than storage.</li><li>A party "shares" data if the party enables another party to collect the data.</li></ol><p>The definitions of collection, retention, use, and sharing are drafted expansively so as to comprehensively cover a party's user-information practices. These definitions do not require a party's intent; a party may inadvertently collect, retain, use, or share data. The definition of collection includes information that a party did not cause to be transmitted, such as protocol headers.</p>
</section>
<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"> 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>
+-->
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/trac/k/issues/117">ISSUE-117</a>: Terms: tracking v. cross-site tracking</p>
+<!--
<p>The WG has not come to consensus regarding the definition of tracking and whether the scope of DNT includes all forms of user-identifying data collection or just cross-site data collection/use. This issue will be resolved in the TCS document, though its resolution is a necessary prerequisite to understanding and correctly implementing the protocol defined by this document.</p>
+-->
- <section id="def-tracking-1">
+ <section class="option" id="def-tracking-1">
<h4>Option 1: Non-first Party Identifiers</h4>
<p class="note"> Concerns with this section include undefined term "user data" plus as written, this may apply more broadly than the authors intended</p>
<p>Tracking is the collection or use of user data via either a unique identifier or a correlated set of data points being used to approximate a unique identifier, in a context other than "first party" as defined in this document. This includes:</p><ol start="1"><li>a party collecting data across multiple websites, even if it is a first party in one or more (but not all) of the multiple contexts</li><li>a third party collecting data on a given website</li><li>a first party sharing user data collected from a DNT:1 user with third parties "after the fact".</li></ol><p>Examples of tracking use cases include:</p><ol start="1"><li>personalized advertising</li><li>cross-site analytics or market research that has not been de-identified</li><li>automatic preference sharing by social applications</li></ol>
</section>
- <section id="def-tracking-2">
+ <section class="option" id="def-tracking-2">
<h4>Option 2: Cross-site or Over Time</h4>
<p>Tracking is defined as following or identifying a user, user agent, or device across multiple visits to a site (time) or across multiple sites (space).</p>
<p>Mechanisms for performing tracking include but are not limited to:</p><ol start="1"><li>assigning a unique identifier to the user, user agent, or device such that it will be conveyed back to the server on future visits;</li><li>personalizing references or referral information such that they will convey the user, user agent, or device identity to other sites;</li><li>correlating data provided in the request with identifying data collected from past requests or obtained from a third party; or,</li><li>combining data provided in the request with de-identified data collected or obtained from past requests in order to re-identify that data or otherwise associate it with the user, user agent, or device.</li></ol><p>A preference of "Do Not Track" means that the user does not want tracking to be engaged for this request, including any mechanism for performing tracking, any use of data retained from prior tracking, and any retention or sharing of data from this request for the purpose of future tracking, beyod what is necessary to enable:</p><ol start="1"><li>the limited permitted uses defined in this specification;</li><li>the first-party (and third-parties acting as the first-party) to provide the service intentionally requested by the user; and</li><li>other services for which the user has provided prior, specific, and informed consent.</li></ol>
</section>
- <section id="def-tracking-silence">
+ <section class="option" id="def-tracking-silence">
<h4>Option 3: Silence</h4>
<p>One proposal is not to define "tracking," but rather to list what is, or is not, required and allowed in order to comply with the recommendation.</p>
</section>
@@ -610,27 +653,29 @@
<section id="def-consent">
<h3>Explicit and Informed Consent</h3>
<p class="note">The spec currently envisions that users should consent to both the setting of a DNT preference as well as any user-granted exceptions. We have not reached agreement on how precisely we need to define this term.</p>
- <p class="note">Include note that asks whether this applies to all consent, both turning DNT on and asking for an exception; may need to rephrase choice mechanism</p>
-<p class="note">David Singer & Shane to work with Justin on alternative text on consent, check mailing list and Bellevue minutes for additional suggestions
-</p>
+ <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/69">ISSUE-69</a> : Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)</p>
- <section id=def-consent-prescribe>
+<!--
+<p class="note">David Singer & Shane to work with Justin on alternative text on consent, check mailing list and Bellevue minutes for additional suggestions</p>
+-->
+
+
+ <section class=option id=def-consent-prescribe>
<h4>Option 1: Prescriptive</h4>
- <p class=option>Explicit and informed choice must satisfy the folllowing bright-line requirements:<br><b>1. Actual presentation:</b> The choice mechanism MUST be actually presented to the user. It MUST NOT be on a linked page, such as a terms of service or privacy policy.<br><b>2. Clear Terms:</b>The choice mechanism MUST use clear, non-confusing technology.<br><b>3. Independent choice:</b> The choice mechanism MUST be presented independent of other choices. It MUST NOT be bundled with other user preferences.<br><b>4. No default permission:</b> The choice MUST NOT have the user permission selected by default.</p></section>
+ <p>Explicit and informed choice must satisfy the folllowing bright-line requirements:<br><b>1. Actual presentation:</b> The choice mechanism MUST be actually presented to the user. It MUST NOT be on a linked page, such as a terms of service or privacy policy.<br><b>2. Clear Terms:</b>The choice mechanism MUST use clear, non-confusing technology.<br><b>3. Independent choice:</b> The choice mechanism MUST be presented independent of other choices. It MUST NOT be bundled with other user preferences.<br><b>4. No default permission:</b> The choice MUST NOT have the user permission selected by default.</p></section>
- <section id="def-consent-silence">
+ <section class=option id="def-consent-silence">
<h4>Option 2: Silence</h4>
- <p class=option>No definition, other than explicitly leaving the definition of consent to local rules.</p>
+ <p>No definition, other than explicitly leaving the definition of consent to local rules.</p>
</section>
</section>
-
- <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/69">ISSUE-69</a> : Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)</p></section></section>
+ </section>
<section id="first-party-compliance">
<h3>First Party Compliance</h3>
-<p class="note">Clear that 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 still in flux, and may not yet allow third parties to do anything on a publisher site. <!-- (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>
@@ -641,68 +686,50 @@
<h3>User Agent Compliance</h3>
<p>A user agent MUST 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 given express and informed consent 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. 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>2. Any User Agent claiming compliance must have a functional implementation of the browser exceptions in this specification</p>
+<p class="option">Shane's proposal has suggested the additional compliance requirements of user agents:<br>1. 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>2. 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: 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="note">We will be using this language as one of three or more options to evaluate for third party compliance.</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>
+<!-- All these issues are listed as closed, so commenting them out for now
<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>
+-->
-<section id="geolocation">
-<h4>Geolocation compliance by a third party</h4>
-<p class="note">Unclear whether this section reflects group consensus.</p>
-<p class="note">TODO: Get Ian’s suggestions from the mailing list and Ian/dwainberg’s review of this geolocation section</p>
-<p class="note">Make sure that elements of user agent aren’t in geolocation section; revisit invasive behavior example </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:1 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>
-<p><i>Non-normative text</i><br><p class="informative">It is acceptable to use data sent as part of this particular network
-interaction when composing a response to a DNT:1 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 id="permitted-uses">
<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 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>
+<!-- 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 the permitted uses enumerated below:</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>Contextual content or ad delivery;</li>
+<li>Content or Ad Delivery Based on First Party Data</li>
+<li>Frequency Capping</li>
+<li>Financial Logging and Auditing</li>
+<li>Security and Fraud Prevention</li>
+<li>Aggregate Reporting</li>
+<li>Debugging</li>
+<li>Compliance With Local Laws and Public Purposes</li>
+</ul>
+As long as there is:
+<ul>
+<li>No Secondary Use</li>
+<li>Data Minimization and Transparency</li>
+<li>Reasonable Security</li>
+<li>No Personalization</li>
+</ul>
+</p><p>These permitted uses are further discussed below.</p>
<section id=enumerated-uses>
<h4>Enumerated Uses</h4>
@@ -829,6 +856,51 @@
<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>
+<section id="geolocation">
+<h4>Geolocation compliance by a third party</h4>
+<p class="note">Unclear whether this section reflects group consensus.</p>
+<!-- note - I moved this section because for some reason it was before the permitted uses generally
+<p class="note">TODO: Get Ian’s suggestions from the mailing list and Ian/dwainberg’s review of this geolocation section</p>
+-->
+<!--
+<p class="note">Make sure that elements of user agent aren’t in geolocation section; revisit invasive behavior example </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:1 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>
+<section class="informative" id="geo-discussion"><h3>Discussion</h3>It is acceptable to use data sent as part of this particular network
+interaction when composing a response to a DNT:1 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.</section>
+
+<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>
+
+<section class="informative" id="geo-examples"><h3>Examples</h3>
+<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="user-granted-exceptions">
<h2>User-Granted Exceptions</h2>
Received on Wednesday, 8 August 2012 21:25:43 UTC