- From: Justin Brookman via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 06 Jul 2012 21:26:55 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv24984
Modified Files:
EditorsStrawmanComp.html
Log Message:
Substantial restructuring, revise UGE, revise and eliminate defs
Index: EditorsStrawmanComp.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/EditorsStrawmanComp.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- EditorsStrawmanComp.html 5 Jul 2012 21:17:22 -0000 1.4
+++ EditorsStrawmanComp.html 6 Jul 2012 21:26:53 -0000 1.5
@@ -546,6 +546,8 @@
embedded social sharing button. The average user would understand that by
clicking the button she is communicating with Example Social.</li></ol>
+ <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>
+
</section>
</section>
</section>
@@ -603,42 +605,22 @@
</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>
+ <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>
+ <section 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>
+
<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>
+ <h4>Option 2: Silence</h4>
+ <p class=option>No definition, other than explicitly leaving the definition of consent to local rules.</p>
</section>
</section>
+
+ <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-interaction">
-<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="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>
@@ -656,19 +638,21 @@
<section id="user-agent-compliance">
<h3>User Agent Compliance</h3>
-<p>A user agent MAY offer a control to express a tracking preference to third parties. The control MUST communicate the user's preference in accordance with the [[!!TRACKING-DNT]] recommendation and otherwise comply with that recommendation. A user agent MUST NOT express a tracking preference for a user unless the user has interacted with the user agent in such a way as to indicate a tracking preference.</p>
+<p>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. A User Agent must obtain explicit, informed consent to turn on the DNT header<br>2. The User Agent must also make available via a link in explanatory text where DNT is enabled to provide more detailed information about DNT functionality<br>3. Any User Agent claiming compliance must have a functional implementation of the browser exceptions in this specification</p>
+<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>
</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>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="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/71">ISSUE-71</a>: Does DNT also affect past collection or use of past collection of info?</p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/19">ISSUE-19</a>: Data collection / Data use (3rd party)</p>
<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/88">ISSUE-88</a>: different rules for impression of and interaction with 3rd-party ads/content</p>
-<p>If the operator of a third-party domain receives a communication to which a DNT:1 header is attached:</p>
-<ol start="1"><li>that operator must not collect, share, or use information related to that communication outside of the permitted uses as defined within this standard and any explicitly-granted exceptions, provided in accordance with the requirements of this standard;</li><li>that operator must not use information about previous communications in which the operator was a third party, outside of the explicitly expressed permitted uses as defined within this standard;</li><li>that operator may delete information about previous communications in which the operator was a third party, outside of the explicitly expressed permitted uses as defined within this standard.</li></ol>
<section id="geolocation">
<h4>Geolocation compliance by a third party</h4>
@@ -707,7 +691,7 @@
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>
+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>
@@ -792,8 +776,6 @@
<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 isauditable. </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 fornon-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 individalized 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></section>
-</section>
-
<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>
@@ -806,8 +788,9 @@
</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="note">Heather: Unclear to me whether this even belongs in the compliance doc at this point.</p>
+
+<p>The operator of a website may engage in practices otherwise described by this standard if the user has given explicit and informed consent. This consent may be obtained through the browser API defined in the companion [[!!TRACKING-DNT]] document, or an operator of a website may also obtain "out-of-band" consent to disregard a "Do Not Track" preference using a different technology. If an operator is relying on "out of band" consent to disregard a "Do Not Track" instruction, the operator must indicate this consent to the user agrent as described in the companion [[!!TRACKING-DNT]] document.</p>
<p class="issue">{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>
@@ -815,7 +798,7 @@
<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 class="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>
@@ -824,32 +807,33 @@
<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>
+<p class=issue><a href="http://www.w3.org/2011/tracking-protection/track/issues/65">ISSUE-65</a> : How does logged in and logged out state work</p>
-<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 ists 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>
+<p class=note>I believe we have consensus that the spec should be silent on the relevance of "logged-in" versus "logged-out" state. I am deleting the various options on this issue, but we can revisit if people object.</p>
-<section id="logged-in-2">
-<h4>Option 2: Dependant on logged in state</h4></section>
+</section></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>
+<section id="degrade">
+<h3>Degrading User Experience for DNT:1 users</h3>
-<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>
+<p class="note">{Heather:I thought we had consensus that it's fine to degrade the experience for DNT:1 transactions, but need to find the text.</p>
+
+<p class="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>
</section>
+<section id=enforcement>
+<h3>Public Discosure of Compliance</h3>
+<p class="note">Final wording awaits how the response is designed in the <a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#bib-TRACKING-DNT">TRACKING-DNT</a> recommendation, but we agree upon the general direction below.</p>
+<p>In order to be in compliance with this specification, a third party must make a public commitment that it complies with this standard. A "public commitment" may consist of a statement in a privacy policy, a response header, a machine-readable tracking status resource at a well-known location, or any other reasonable means. This standard does not require a specific form of public commitment.</p>
+
+<section id="3p-audit">
+<h4>Third Party Auditing</h4>
+<p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/21">ISSUE-21</a> : Enable external audit of DNT compliance</p>
+<p class="note">We have reviewed one audit proposal that we declined to adopt as mandatory, but there is significant support to include a flexible option to enable auditing. We may include a smaller-scoped proposal in the future, or may drop auditing all together.</p>
+</section></section>
+</section></section>
<section id="acknowledgements">
-<h2>Acknowledgements</h2>
+<h1>Acknowledgements</h1>
<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>
Received on Friday, 6 July 2012 21:26:58 UTC