- From: Aleecia McDonald via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 28 Jun 2012 18:00:35 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv25567
Added Files:
EditorsStrawmanComp.html
Log Message:
Adding draft of the Editor's compliance strawman, file from Heather.
--- NEW FILE: EditorsStrawmanComp.html ---
<!DOCTYPE html>
<html>
<head>
<title>Tracking Compliance and Scope Specification</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js"
class="remove"></script>
<script src="http://code.jquery.com/jquery-1.7.2.min.js" type="text/javascript" charset="utf-8"></script>
<script class="remove">
var respecConfig = {
specStatus: "ED",
shortName: "tracking-compliance",
// subtitle: "an excellent document",
// publishDate: "2012-03-13",
copyrightStart: "2011",
previousPublishDate: "2012-03-13",
previousMaturity: "WD",
edDraftURI:
"http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html",
// lcEnd: "2009-08-05",
extraCSS:
["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Justin Brookman", url: "http://cdt.org/",
company: "CDT", companyURL:
"http://cdt.org/" },
{ name: "Sean Harvey", url: "http://google.com/",
company: "Google", companyURL:
"http://google.com/" },
{ name: "Erica Newland", url: "http://cdt.org/",
company: "CDT", companyURL:
"http://cdt.org/" },
{ name: "Heather West", url: "http://Google.com/",
company: "Google", companyURL:
"http://google.com/" },
],
wg: "Tracking Protection Working Group",
wgURI: "http://www.w3.org/2011/tracking-protection/",
wgPublicList: "public-tracking",
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49311/status",
}
</script>
<link rel="stylesheet" href="additional.css" type="text/css"
media="screen" title="custom formatting for TPWG editors" charset="utf-8">
<style type="text/css" media="screen">
#toggle-widget {
position: fixed;
left: 3px;
bottom: 0;
-webkit-transform: rotate(-90deg);
-webkit-transform-origin: 0 0;
-ms-transform: rotate(-90deg);
-ms-transform-origin: 0 0;
-o-transform: rotate(-90deg);
-o-transform-origin: 0 0;
-moz-transform: rotate(-90deg);
-moz-transform-origin: 0 0;
}
.informative-hidden * {
display: none;
}
.informative-hidden *:first-child {
display: block;
}
.informative-hidden *:first-child span {
display: inline;
}
.informative-hidden h5:first-child:after, .informative-hidden h6:first-child:after, .informative-hidden h4:first-child:after {
font-style: italic;
content: " (show this section)";
font-size: 80%;
}
.informative-hidden h5:first-child, .informative-hidden h6:first-child, .informative-hidden h4:first-child {
cursor: pointer;
}
.informative:not(.informative-hidden) p:nth-of-type(1):after {
content: " (hide this section)";
font-style: italic;
font-size: 80%;
}
.informative:not(.informative-hidden) p:nth-of-type(1) {
cursor: pointer;
}
</style>
<script type="text/javascript" charset="utf-8">
$(function() {
var informativeVisible = true;
$('#toggle-button').click(function() {
if (informativeVisible) {
//$('.informative').hide();
$('.informative').addClass('informative-hidden');
} else {
$('.informative').removeClass('informative-hidden');
}
informativeVisible = !informativeVisible;
var text = informativeVisible ? 'Hide non-normative sections' : 'Show non-normative sections';
$('#toggle-button').text(text);
return false;
});
$('.informative-hidden h4, .informative-hidden h5, .informative-hidden h6').live('click', function(event) {
$(event.target).closest('.informative').removeClass('informative-hidden');
return false;
});
$('.informative:not(.informative-hidden) p:nth-of-type(1)').live('click', function(event) {
$(event.target).closest('.informative').addClass('informative-hidden');
});
});
</script>
</head>
<body>
<section id="abstract">
<p>This specification defines the meaning of a Do Not Track (DNT) preference and sets out practices for websites to comply with this preference.</p>
</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>
</section>
<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>
<p>The World Wide Web (WWW, or Web) consists of millions of sites interconnected through the use of hypertext. Hypertext provides a simple, page-oriented view of a wide variety of information that can be traversed by selecting links, manipulating controls, and supplying data via forms and search dialogs. A Web page is usually composed of many different information sources beyond the initial resource request, including embedded references to stylesheets, inline images, javascript, and other elements that might be automatically requested as part of the rendering or behavioral processing defined for that page.</p>
<p>Each of the hypertext actions and each of the embedded resource references might refer to any site on the Web, leading to a seamless interaction with the user even though the pages might be composed of information requested from many different and possibly independent Web sites. From the user's perspective, they are simply visiting and interacting with a single brand -- the first-party Web property -- and all of the technical details and protocol mechanisms that are used to compose a page representing that brand are hidden behind the scenes.</p>
<p>It has become common for Web site owners to collect data regarding the usage of their sites for a variety of purposes, including what led the user to visit their site (referrals), how effective the user experience is within the site (web analytics), and the nature of who is using their site (audience segmentation). In some cases, the data collected is used to dynamically adapt the content (personalization) or the advertising presented to the user (targeted advertising). Data collection can occur both at the first-party site and via third-party providers through the insertion of tracking elements on each page. A survey of these techniques and their privacy implications can be found in [<a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-KnowPrivacy">KnowPrivacy</a>].</p>
<p>People have the right to know how data about them will be collected and how it will be used. Empowered with that knowledge, individuals can decide whether to allow their online activities to be tracked and data about them to be collected. Many Internet companies use data gathered about people's online activities to personalize content and target advertising based on their perceived interests. While some people appreciate this personalization of content and ads in certain contexts, others are troubled by what they perceive as an invasion of their privacy. For them, the benefit of personalization is not worth their concerns about allowing entities with whom they have no direct relationship to amass detailed profiles about their activities.</p>
<p>Therefore, users need a mechanism to express their own preference regarding tracking that is both simple to configure and efficient when implemented. In turn, Web sites that are unwilling or unable to offer content without such targeted advertising or data collection need a mechanism to indicate those requirements to the user and allow them (or their user agent) to make an individual choice regarding user-granted exceptions.</p>
<p>This specification defines the terminology of tracking preferences, the scope of its applicability, and the requirements on compliant first-party and third-party participants when an indication of tracking preference is received. This specification defines the meaning of a Do Not Track preference and sets out practices for websites and other online companies to comply with this preference.</p>
<p>A companion document, [[!!TRACKING-DNT]], defines the HTTP request header field DNT for expressing a tracking preference on the Web, a well-known location (URI) for providing a machine-readable tracking status resource that describes a service's DNT compliance, the HTTP response header field Tk for resources to communicate their compliance or non-compliance with the user's expressed preference, and JavaScript APIs for determining DNT status and requesting a site-specific, user-granted exception.</p>
</section>
<section id="scope-and-goals">
<h2>Scope and Goals</h2>
<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/6">ISSUE-6</a> and is in active discussion. Currently, it satisfies no one. Like the introduction, we will revisit and finalize once the document is more complete.</p>
<p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/6">ISSUE-6</a>: What are the underlying concerns? Why are we doing this?</p>
<p>While there are a variety of business models to monetize content on the web, many rely on advertising. Advertisements can be targeted to a particular user's interests based on information gathered about one's online activity. While the Internet industry believes many users appreciate such targeted advertising, as well as other personalized content, there is also an understanding that some people find the practice intrusive. If this opinion becomes widespread, it could undermine the trust necessary to conduct business on the Internet. This Compliance specification and a companion [[!!TRACKING-DNT]] specification are intended to give users a means to indicate their tracking preference and to spell out the obligations of compliant websites that receive the Do Not Track message. The goal is to provide the user with choice, while allowing practices necessary for a smoothly functioning Internet. This should be a win-win for business and consumers alike. The Internet brings millions of users and web sites togeher in a vibrant and rich ecosystem. As the sophistication of the Internet has grown, so too has its complexity which leaves all but the most technically savvy unable to deeply understand how web sites collect and use data about their online interactions. While on the surface many web sites may appear to be served by a single entity, in fact, many web sites are an assembly of multiple parties coming together to power a user's online experience. As an additional privacy tool, this specification provides both the technical and compliance guidelines to enable the online ecosystem to further empower users with the ability to communicate a tracking preferences to a web site and its partners.</p>
<p>The accompanying <a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-TRACKING-DNT">TRACKING-DNT</a> recommendation explains how a user, through a user agent, can clearly express a desire not to be tracked. This Tracking Compliance and Scope recommendation sets the standard for the obligations of a website that receives such a DNT message.</p>
<p>Taken together these two standards should have four substantial outcomes:</p><ol start="1"><li>Empower users to manage their preference around the collection and correlation of data about Internet activities that occur on different sites and spell out the obligations of sites in honoring those preferences when DNT is enabled.</li><li>Provide an exceedingly straightforward way for users to gain transparency and control over data usage and the personalization of content and advertising on the web.</li><li>Enable a vibrant Internet to continue to flourish economically by supporting innovative business models while protecting users' privacy.</li><li>Establish compliance metrics for operators of online services</li></ol><p>This solution is intended to be persistent, technology neutral, and reversible by the user. It aims to preserve a vibrant online ecosystem, privacy-preserving secondary data uses necessary to ecommerce, and adequate security measures. We seek a solution that is persistent, technology neutal, and [something that speaks with the ability to opt back in], but that preserves a vibrant online ecosystem, privacy-preserving secondary data uses, and adequate security measures.</p>
</section>
<section id="definitions">
<h2>Definitions</h2>
<p class="note">{NOTE:Editor's note: The definitions section is a strawman proposal from editors based on discussion in Seattle. Many sections are not yet consensus text. I am adding material based on in-person discussions as reflected in the minutes, mailing list text, and other sources. - Heather</p>
<section id="def-parties">
<h3>Parties</h3>
<p class="note">{NOTE:Seattle consensus: Party size will be based on corporate ownership with a "discoverable" list of all of the affiliates acting as one entity. Previous options can be found in the last draft, section 3.2.</p>
<p class="note">{NOTE:Editor's note: Existing options for first and third party definitions have been removed. It's unclear that we need definitions for ‘parties' and ‘first and third parties' - so I have merged them. Easy enough to unmerge. - Heather to polish language</p>
<p>A party is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.</p>
<p>For unique corporate entities to qualify as a common party with respect to this standard, those entities MUST be commonly owned and commonly controlled (Affiliates) and MUST provide “easy discoverability” of affiliate organizations. An “Affiliate List” MUST be provided within one click from each page or the entity owner clearly identified within one click from each page. </p>
<p><i>Example:</i> A clear labeled link to the Affiliate List within the privacy policy would meet this requirement or the ownership brand clearly labeled on the privacy policy itself.</p>
<p class="note">{NOTE: Previous non-normative text for similar discoverable affiliates text read "This may be accomplished in many ways, including but not limited to, prominent and common branding on site pages, "one click away" within Privacy Policies, and, if available, a programmatic list of domains that share common ownership (affiliation)."</p>
<p>A First Party is the party that owns the Web site or has control over the Web site the user visits. A party may start out as a third party but become a first party later on, after the user meaningfully interacts with it.</p>
</section>
<section id="def-service-providers">
<h3>Service Providers/Outsourcers</h3>
<p class="note">{NOTE:Editor's note: Added definition here since it is more appropriate than in compliance section. Clarified language.</p>
<p>Service Providers acting on the behalf of a First Party, and with no independent rights to use the First Party's data outside of the context of that First Party and Permitted Uses, are also considered a First Party.</p>
<p>It is possible to have multiple first parties on a single page but each party must provide clear branding and a link to their respective privacy policy (co-branded experience).</p>
<p class="c11 c0"></p>
<p>A Third Party is any party other than a First Party, Service Provider, or a user.</p>
</section>
<section id="def-unident">
<h3>Unidentified Data</h3>
<p class="note">{NOTE:Editor's note: It is not yet clear what the correct term for this kind of data is. Unlinkable, unlinked, unidentified are all open options.</p>
<p>A dataset is un-linkable when 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, and which the entity will commit to make no effort to re-identify, and prohibit downstream recipients of un-linkable data from re-identifying it.</p>
<p class="note">{NOTE: Un-linkable Data is outside of the scope of the Tracking Preference standard as information is no longer reasonably linked to a particular user, user agent, or device. </p>
<p class="informative">{NON-NORM:Non-normative explanatory text: There are many valid and technically appropriate methods to de-identify or render a data set "un-linkable". In all cases, there should be confidence the information is not easily reverted to a "linkable" state.</p>
<p class="informative">{NON-NORM:Non-normative explanatory text: It is recommended that companies publically stating W3C Tracking Preference compliance provide transparency to their delinking process (to the extent that it will not provide confidential details into security practices) so external experts and auditors can assess if they feel these steps are reasonable given the risk of a particular dataset.</p>
</section>
<section id="def-network-transaction">
<h3>Network Transaction</h3>
<p class="note">{NOTE:Editor's 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-NORM: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">{NOTE:Editor's 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">{NOTE: The following text consists of proposed text that is meant to address<a href="http://www.w3.org/2011/tracking-protection/track/issues/16"> </a><a href="http://www.w3.org/2011/tracking-protection/track/issues/16">ISSUE-16.</a> This language is currently being actively debated. - I thought we came to a good solution on this - find in notes - Heather</p>
<p class="issue">{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">{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">{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">
<h4>Option 1: Non-first Party Identifiers</h4>
<p class="note">{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-on 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">
<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, beyon 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">
<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>
</section>
<section id="def-consent">
<h3>Consent</h3>
<p class="note">{NOTE:Editor's note: The term “affirmative, informed consent” is used throughout this document. While this terminology may ultimately be modified, some options for explaining the underlying idea are included. These are not that different as they sit.</p>
<p class="issue">{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-1">
<h4>Option 1: Affirmative action</h4>
<p>"Affirmative, Informed Consent to be Tracked" means consent given by an affirmative action such as clicking a consent box in response to a clear and prominent request to ignore a "Do Not Track" setting that is distinct and separate from any other notifications or requested permissions.</p>
</section>
<section id="def-consent-2">
<h4>Option 2: Meaningful interaction</h4>
<p>"Affirmative, Informed Consent to be Tracked" has been obtained when a mechanism to provide for or facilitate the acquisition and storage of permission to ignore the header has been made available to the user and the user has meaningfully interacted with the mechanism in a way that makes clear her intent to grant this permission.</p>
</section>
<section id="def-consent-silence">
<h4>Option 3: Silence</h4>
<p>The hope is that this option will ensure consistency with EU regulations; it may not unless notice is included.</p>
<p>No definition, other than explicitly leaving the definition of consent to local rules.</p>
</section>
</section>
<section id="FIXME">
<h3>Meaningful Interaction</h3>
<p class="note">{NOTE:Editor's note: This definition is consensus or near-consensus text from the pre-Seattle draft. Wording needs polish to ensure it works with accessibility issues, but other than minor edits this is agreed upon.</p>
<p>"Meaningful Interaction" with a widget or window initially presented on a third-party basis means clicking on such content (except to stop, close, silence, or otherwise impair the rendering of such content) or otherwise affirmatively engaging with the content in a manner that would reasonably be interpreted to express an affirmative intention to interact with that party. A user merely moving her cursor across the widget or window does not constitute "meaningful interaction."</p>
</section>
<section id="def-user">
<h3>User</h3>
<p class="note">{NOTE:Editor's 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">{NOTE:Editor's 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>
<section id="editorsnotes-def">
<h3>Editor's Drafting Notes</h3>
<p class="issue">{ISSUE:<a href="http://www.w3.org/2011/tracking-protection/track/issues/97">ISSUE-97</a> : A special rule for URL-shortening services remains an open issue and is not addressed in the proposal put forward in 3.2 through 3.4.</p>
<p class="issue">{ISSUE: <a href="http://www.w3.org/2011/tracking-protection/track/issues/26">ISSUE-26</a> : Providing data to 3rd-party widgets &emdash; does that imply consent?</p>
<p>The proposal put forward here does not provide a special rule for widgets. The same first party vs. third party test for static content applies.</p>
<p class="issue">{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>
<p class="note">{NOTE:Editor's 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>
</section>
</section>
<section id="compliance">
<h2>Compliance with an Expressed Tracking Preference</h2>
<p class="note">{NOTE:Editor's note: Much of section 4 is non-consensus text based on discussions in Seattle.</p>
<section id="first-party-compliance">
<h3>First Party Compliance</h3>
<p class="note">{NOTE:Editor's note: This section has been cleaned up in order to improve fluency, and is largely consensus text based on discussions in Seattle.</p>
<p>If a First Party receives a network transaction to which a DNT-1 header is attached, First Parties may engage in their normal collection and use of information. This includes the ability to customize the content, services, and advertising in the context of the first party experience. </p>
<p>The First Party must not pass information about this transaction to non-service provider third parties who could not collect the data themselves under this Recommendation. </p>
</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 – 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>
<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>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>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>
<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>
<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="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 – including those that monetize site activities.</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 is uditable. </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 for on-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 individulized 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>
<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>
<p class="note">{NOTE: All existing contracts may be honored as part of a phase-in process. New contracts should keep this permitted use in mind. Contracts should not be used to create a work-around for compliance with this draft.</p>
<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>
<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 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 (“Debugging”). </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 ‘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="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 “unlinkability” (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>
</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>
<p class="issue">{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">{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">{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 &emdash; what kind of tracking is this?</p>
</section>
</section>
<section id="user-granted-exceptions">
<h2>User-Granted Exceptions</h2>
<p class="note">{NOTE:Editor's note: Unclear to me whether this even belongs in the compliance doc at this point.</p>
<p>For the purposes of this document, a user-granted exception is a user-granted override of their default DNT status for one or more third parties within a given first party context. Details on Exceptions are found in the [!!TRACKING-DNT] draft.</p>
<p class="issue">{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">{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">{NOTE:Editor's note: I believe that there is text on this somewhere, from Seattle meeting - Heather to find</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>
<ol start="1"><li>No DNT Signal / No Opt-Out: Treat as DNT unset</li><li>DNT Signal / No Opt-Out: Treat as DNT:1</li><li>Opt-Out / No DNT Signal: Treat as DNT:1</li><li>Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; DNT User-Granted Exception is honored</li></ol>
</section>
<section id="logged-in">
<h3>Logged In Transactions</h3>
<p class="issue">{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>
</section>
<section id="logged-in-1" class="option">
<h4>Option 1: Logged In Honors DNT</h4>
<p>If a user is logged into a first-party website and it receives a DNT:1 signal, the website must respect DNT:1 signal as a first party and should handle the user login as it normally would. If a user is logged into a third-party website, and the third party receives a DNT:1 signal, then it must respect the DNT:1 signal unless it falls under an exemption described in this document.</p>
<p>Example use cases:</p>
<ol start="1"><li>A user with DNT:1 logs into a search service called "Searchy". Searchy also operates advertisements on other websites. When the user is on a news website, Searchy receives DNT:1, and it must respect it, as Searchy is operating in a third-party context.</li><li>A user with DNT:1 enabled visits a shopping website and logs in. The shopping website continues to provide recommendations, order history, etc. The shopping site includes third-party advertisements. Those third-parties continue to respect DNT:1. When the user purchases the items in their basket, a third-party financial transaction service is used. The user interacts with the third-party service, at which point it becomes first-party and may use previously collected data.</li><li>A user with DNT:1 visits a website (Website A) that uses a third-party authentication service called "LogMeIn". The user logs into the site with his LogMeIn credentials. The user has interacted with LogMeIn, and now it can act as a first-party. Now the user vsts Website B, which also uses the LogMeIn service, but is branded differently than Website A. LogMeIn must respect the DNT:1 signal until the user chooses to interact with LogMeIn in order to log into Website B.</li></ol></section>
<section id="logged-in-2">
<h4>Option 2: Dependant on logged in state</h4></section>
<section id="logged-in-silence">
<h4>Silence on Logged In</h4>
<p>No text on this topic at all, and let the existing rules work it out.</p>
<h2>Enforcement/Compliance</h2>
<p class="note">{NOTE:Editor's 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 party must make a public commitment that it complies with this standard.</p>
<p class="informative">{NON-NORM:Non-normative explanatory text: 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>
<p class="issue">{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">{NOTE:Editor's 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 id="acknowledgements">
<h2>Acknowledgements</h2>
<p>This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando (Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla), Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University), Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson (Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert), Rigo Wenning (W3C), and Shane Wiley (Yahoo!).</p>
<p>The DNT header field is based on the original Do Not Track submission by Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm (Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.</p>
</section>
<section id="FIXME">
<h2>References</h2><h3>B.1 Normative references</h3>
<p>[HTTP11</p>
<p>R. Fielding; et al. <a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext Transfer Protocol - HTTP/1.1.</a> June 1999. Internet RFC 2616. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a></p>
<p>[!!TRACKING-DNT</p>
<p>Roy T. Fielding; David Singer. <a href="http://www.w3.org/TR/tracking-dnt/">Tracking Preference Expression (DNT).</a> 13 March 2012. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-tracking-dnt-20120313/">http://www.w3.org/TR/2011/WD-tracking-dnt-20120313/</a></p>
<h3>B.2 Informative references</h3>
<p>[KnowPrivacy</p>
<p>Joshua Gomez; Travis Pinnick; Ashkan Soltani. <a href="http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf">KnowPrivacy.</a> 1 June 2009. URL: <a href="http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf">http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf</a></p>
</section>
</body></html>
Received on Thursday, 28 June 2012 18:00:43 UTC