W3C home > Mailing lists > Public > public-tracking-commit@w3.org > March 2013

CVS WWW/2011/tracking-protection/drafts

From: CVS User jbrookma <cvsmail@w3.org>
Date: Tue, 05 Mar 2013 20:03:32 +0000
Message-Id: <E1UCy5E-0008BQ-S4@gil.w3.org>
To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv31456

Modified Files:
	EditorsStrawmanComp.html 
Log Message:
convent Bare Bones draft to Editors' Draft, update first and third party defs, typos, etc.

--- /w3ccvs/WWW/2011/tracking-protection/drafts/EditorsStrawmanComp.html	2012/08/06 19:10:34	1.8
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/EditorsStrawmanComp.html	2013/03/05 20:03:32	1.9
@@ -1,910 +1,1737 @@
-<!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>
-
-<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">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">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"><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 together 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 neutral, 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">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>
-
-	<section id="def-parties">
-	<h3>Parties</h3>
-		
-<p class="note">Dsinger has asked to add something about the responsibility following the data</p>
-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.
-<br/><br/>
-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>
-<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>
-
-	<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>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>
-
-<p>
-	A <a>first party</a> or a <a>third party</a> MAY outsource functionality to another <a>party</a>, in which case the <a>third party</a> may act as the original <a>first party</a> or <a>third party</a> under this standard, with the following additional restrictions:
-</p>
-<ul>
-	<li> Data collected by each outsourced company is separated for each party they collect data for by both technical means and organizational process, AND </li>
-	<li> The outsourced company has no independent rights to the collected information, AND </li>
-	<li>  A contractual relationship exists between the outsourced and the party they collect data for that outlines and mandates these requirements. </li>
-	</ul>
-
-<p>An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)</p>
-
-<section class="informative">
-	<h2>Non-Normative</h2>
-	<p class="informative">Outsourced companies that act purely as vendors for their customers (often first parties in this context) are not the intended target for the Tracking Preference Expression but it is important there are no unintended activities that are extended to another party through this allowance. In all cases, its expected an outsourced company acting on the part of a customer follows all of the same restrictions placed on that customer.</p>
- 
-	<p>For the data separation requirement, outsourced companies have technical options to achieve appropriate separation but in each the critical element is that data is never reconstituted for users that have indicated a preference not to be tracked. One possible approach would be to leverage a per partner hash against a common cookie identifier, ensuring the resulting identifier is consistent for a specific customer, but is unable to be linked with another customer’s identifier.</p>
- 
-	<p>Contractual requirements that enforce data rights and responsibilities for separation are a critical element of establishing an outsourcer acting on another party’s behalf. Contracts may occur directly through parties (for example, a Publisher in an Ad Network) or between intermediaries (for example, an Ad Network acting through an Ad Exchange). In either case, data separation and removal of independent rights are necessary elements that must survive intermediary contractual constructs.</p>	
-	</section> <!-- closes non-normative, h2 -->	
-
-  <section>
-	<h2>Technical Precautions</h2>
-<p>
-	Throughout all data <a>collection</a>, <a>retention</a>, and <a>use</a>, outsourced parties MUST use all feasible technical precautions to both mitigate the identifiability of and prevent the identification of data from different first parties.
-</p>
-	
-<p>
-	Structural separation ("siloing") of data per first party, including both
-<ol>
-	<li>separate data structures and</li>
-	<li>avoidance of shared unique identifiers</li>
-</ol>
-
-<p>
-are necessary, but not necessarily sufficient, technical precautions.
-</p>  
-	</section> <!-- closes technical precautions, h2 -->
-  
-  <section class="informative">
-	<h2>Non-Normative Discussion</h2>
-  		<section>
-			<h3>Siloing in the Browser</h3>
-<p>
-	Outsourcing services should use browser access control features so that stored data specific to one party is never accessed or collected when the user visits another party.
-</p>
-  				
-  		<section>
-			<h4>Same-Origin Policy</h4>
-<p>
-	The same-origin policy silos stored data by domain name.  An outsourcing service can use a different domain name for each first party.
-</p>
-
-	<pre class="example">
-	Example Analytics provides an outsourced analytics service to Example News
-	and Example Sports, two unrelated websites. Example Analytics stores its
-	cookies for Example News at examplenews.exampleanalytics.com, and it
-	stores its cookies for Example Sports at
-	examplesports.exampleanalytics.com.
-	</pre>
-  			</section> <!-- closes same origin policy, h4 -->
-
-			<section>
-				<h4>Cookie Path Attribute</h4>
-<p>
-	The HTTP cookie path can be used to silo data to a first party.
-</p>
-
-	<pre class="example">
-	Example Analytics stores its cookies for Example News with
-	"Path=/examplenews", and it stores its cookies for Example Sports with
-	"Path=/examplesports".
-	</pre>
-	
-			</section> <!-- closes cookie path attribute, h4 -->
-
-			<section>
-				<h4>Storage Key</h4>
-<p>
-	For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.
-	<pre class="example">
-	Example Analytics stores data for Example News at
-	window.localStorage["examplenews"] and data for Example Sports at
-	window.localStorage["examplesports"].
-	</pre>
-				</section> <!-- closes storage key, h4 -->
-  		</section> <!-- closes siloing in the browser, h3 -->
-  		
-  		<section>
-			<h3>Siloing in the Backend</h3>
-  				<section>
-					<h4>Encryption Keys</h4>
-<p>
-	An outsourcing service should encrypt each <a>first party</a>'s data with a different set of keys.
-</p>	
-  				</section> <!-- closes encryption keys, h4 -->
-  
-  			<section>
-  				<h4>Access Controls</h4>
-<p>
-	An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.
-</p>
-  			</section> <!-- closes access controls, h4 -->
-
-  			<section>
-  				<h4>Access Monitoring</h4>
-<p>
-	An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.</p>
-  			</section> <!-- closes access monitoring, h4 -->
-		</section> <!-- closes siloing in the Backend, h3 -->
-
-			<section>
-				<h3>Retention in the Backend</h3>
-<p>
-	An outsourcing service should <a>retain</a> information only so long as necessary to provide necessary functionality to a first party. If a service creates periodic reports, for example, it should delete the data used for a report once it is generated. An outsourcing service should be particularly sensitive to retaining protocol logs, since they may allow correlating user activity across multiple first parties.
-</p>
-			</section> <!-- closes retention in the backend, h3 -->
-  </section> <!-- closes Non-Normative Discussion, h2 -->
- 
-  <section> 	 
-	<h2>Internal Practices</h2>
-<p>
-	Throughout all data collection, retention, and use, outsourced parties MUST use sufficient internal practices to prevent the identification of data from different parties.
-</p>
-
-		<section class="informative"> <!-- Unclear whether this non-norm tagging works, may need to fix -->
-			<h3>Non-Normative Discussion</h3>
-				<section>
-					<h4>Policy</h4>
-<p>
-	An outsourcing service should establish a clear internal policy that gives guidance on how to <a>collect</a>, <a>retain</a>, and <a>use</a> outsourced data in compliance with this standard.
-</p>
-				</section>  <!-- closes policy, h4 -->
-
-				<section>
-					<h4>Training</h4>
-<p>
-	Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.
-</p>
-				</section> <!-- closes Training, h4 -->
-
-				<section>
-					<h4>Supervision and Reporting</h4>
-<p>
-	An outsourcing service should establish a supervision and reporting structure for detecting improper access.
-</p>
-				</section> <!-- closes supervision and reporting, h4 -->
-				
-				<section>
-					<h4>Auditing</h4>
-<p>
-	External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices.  Auditor reports should be made available to the public.
-</p>
-
-				</section> <!-- closes auditing, h4 -->
-			</section> <!-- closes non-normative discussion, h3 -->
-	</section> <!-- closes internal practices, h2 -->
-
-	<section>
-		<h2>Use Direction</h2>
-<p>
-	An outsourced service:
-</p>
-
-<ol>
-	<li>MUST <a>use</a> data <a>retained</a> on behalf of a <a>party</a> ONLY on behalf of that <a>party</a>, and</li>
-	<li>MUST NOT <a>use</a> data <a>retained</a> on behalf of a <a>party</a> for their own business purposes, or for any other reasons.</li>
-</ol>
-
-	</section> <!-- closes use direction, h2 -->
-	
-  <section>
-	<h2>First Party or Third Party Requirements</h1>
-  		<section>
-			<h3>Representation</h3>
-<p>
-	A <a>party</a>'s representation that it is in compliance with this standard includes a representation that its outsourcing parties comply with this standard.
-</p>
-  		</section> <!-- closes representation, h3 -->
-  		
-  <section>
-  		<h3>Contract</h3>
-<p>
-	A <a>first party</a> MUST enter into a contract with an outsourced party that requires that outsourced party to comply with these requirements.
-</p>
-  		</section> <!-- closes contract, h3 -->
-	</section> <!-- closes first or third party requirements, h2 -->
-	</section></section>

[2251 lines skipped]
Received on Tuesday, 5 March 2013 20:03:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 March 2013 20:03:35 GMT