- From: CVS User jbrookma <cvsmail@w3.org>
- Date: Wed, 17 Apr 2013 14:12:42 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv2074/WWW/2011/tracking-protection/drafts
Modified Files:
tracking-compliance.html
Log Message:
added DK's definition for deidentified data, fixed formatting on E&I consent
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html 2013/04/12 21:05:21 1.90
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html 2013/04/17 14:12:42 1.91
@@ -691,7 +691,7 @@
<section id="def-unlinkable">
<h3>Deidentified Data</h3>
- <p>Data is <dfn>deidentified</dfn> when a party:<br>
+ <p class=option>Data is <dfn>deidentified</dfn> when a party:<br>
(1) has taken measures to ensure with a reasonable level of
justified confidence that
the data cannot be used to infer information about,
@@ -701,10 +701,17 @@
(3) contractually prohibits downstream recipients from trying to re-identify the data.
</p>
- <p class="note">The language above is based on the definition of unlinkable data
- in the 2012 FTC privacy report, but is not yet as consensus. There remains disagreement
- about whether internal access controls within an organization are sufficient to
- sufficiently de-identify data for the purposes of this standard.</p>
+ <p class=option>Data can be considered sufficiently de-identified to the extent
+ that it has been deleted, modified, aggregated, anonymized or otherwise manipulated
+ in order to achieve a reasonable level of justified confidence that the data cannot
+ reasonably be used to infer information about, or otherwise be linked to, a
+ particular user, user agent, or device.</p>
+
+ <p class="note">The first option above is based on the definition of unlinkable data
+ in the 2012 FTC privacy report; the second option was proposed by Daniel Kaufman.
+ The group has a fundamental disagreement about whether internal access controls
+ within an organization could be sufficient to de-identify data for the purposes of
+ this standard.</p>
<!--
<p class="note">JMayer would like an option that limits use of
unlinkable data, but that should be in the compliance sections.</p>
@@ -906,17 +913,13 @@
We have not reached agreement on how precisely we need to define this
term.
</p>
- <p class="issue" data-number="69" title="Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)"></p>
<!--
<p class="note">David Singer & Shane to work with Justin on alternative
text on consent, check mailing list and Bellevue minutes for additional
suggestions</p>
-->
- <section class="option" id="def-consent-prescribe">
- <h4>Option 1: Prescriptive</h4>
-
- <p>
+ <p class="option" id="def-consent-prescribe">
Explicit and informed choice must satisfy the following bright-line
requirements:<br>
<b>1. Actual presentation:</b> The choice mechanism MUST be
@@ -930,15 +933,13 @@
<b>4. No default permission:</b> The choice MUST NOT have the user
permission selected by default.
</p>
- </section>
- <section class="option" id="def-consent-silence">
- <h4>Option 2: Silence</h4>
- <p>
+ <p class="option" id="def-consent-silence">
No definition, other than explicitly leaving the definition of
consent to local rules.
</p>
- </section>
+
+ <p class="issue" data-number="69" title="Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy)"></p>
</section>
</section>
Received on Wednesday, 17 April 2013 14:12:43 UTC