- From: CVS User jbrookma <cvsmail@w3.org>
- Date: Mon, 04 Feb 2013 23:35:10 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv32669
Modified Files:
CambridgeBareBones.html
Log Message:
incorporating Yianni's/Roy's/Shane's suggestions to Cambridge doc
--- /w3ccvs/WWW/2011/tracking-protection/drafts/CambridgeBareBones.html 2013/02/02 20:06:15 1.1
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/CambridgeBareBones.html 2013/02/04 23:35:10 1.2
@@ -344,7 +344,7 @@
</section> --->
<section id="def-service-providers">
- <h4>Service Providers/Outsourcers</h4>
+ <h4>Service Providers</h4>
<p class="note">
We do not expect outsourcing to be a major topic of discussion at the
@@ -617,8 +617,24 @@
experience).
</p>
</section>
+ <section class="option" id="def-first-third-parties-opt-3">
+ <h5>Option 3: User Expectations Not Tied to Legal Ownership</h5>
+ <p>The scope of a "first party" is determined by user expectations
+ and control over the data collected, not limited to a specific
+ site, domain, or legal entity. The first party includes the legal
+ entity that owns and controls the site intended by the user's action
+ and any employees, officers, affiliates, and contractors that operate
+ on behalf of that entity and that are bound under contract to keep
+ data collected on behalf of that entity confidential within the
+ scope of the first party, separated from data collected on behalf
+ of other parties, and to have no independent rights to use, share,
+ or retain the collected data except as directed by the first party.
+ A site that is operated on behalf of multiple legal entities is
+ considered to have a joint first party if a user's expectation
+ would be that each of those entities have control over the data
+ collected.</p>
<!-- <p class="issue" data-number="26" title="Providing data to 3rd-party widgets — does that imply consent?"></p> -->
- </section>
+ </section></section>
<section id="def-unlinkable">
<h3>Unlinkable Data</h3>
@@ -638,7 +654,7 @@
<p>
A party render a dataset <dfn>unlinkable</dfn> when it<br>
1. takes [commercially] reasonable steps to
- de-identify data such that there is confidence that it contains
+ de-identify data such that there is high probability that it contains
information which could not be [reasonably] linked to a specific user, user
agent, or device [in a production environment]<br>
2. publicly commits to retain and use the data in unlinkable
@@ -700,8 +716,9 @@
-->
<p class="issue" data-number="16" title="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 "collects" data if it receives the data and either shares
+ the data with other parties or stores the data for more than a
+ transient period.</li>
<li>A party "retains" data if data remains within a party's control
beyond the scope of the current interaction.</li>
@@ -710,8 +727,8 @@
purpose other than storage or merely forwarding it to another
party.</li>
- <li>A party "shares" data if the party enables another party to
- receive or access that data.</li>
+ <li>A party "shares" data if the party provides a copy or access to the data
+ to a third party.</li>
</ol>
<p>
The definitions of collection, retention, use, and sharing are
@@ -1000,6 +1017,86 @@
<p class="issue" data-number="88" title="different rules for impression of and interaction with 3rd-party ads/content"></p>
-->
+<section id="geolocation">
+ <h4>Geolocation compliance by a third party</h4>
+
+ <p class="note">
+ Unclear whether this section reflects group consensus.
+ </p>
+<!-- note - I moved this section because for some reason it was before
+ the permitted uses generally
+<p class="note">TODO: Get Ian’s suggestions from the mailing list and
+Ian/dwainberg’s review of this geolocation section</p>
+-->
+<!--
+<p class="note">Make sure that elements of user agent aren’t in geolocation
+section; revisit invasive behavior example </p>
+-->
+
+ <p class="issue" data-number="39" title="Tracking of geographic data (however it's determined, or used)"></p>
+ <p>
+ If the operator of a third-party domain receives a communication to
+ which a DNT:1 header is attached:
+ </p>
+ <ol start="1">
+ <li>Geo-location information that is more granular than postal code
+ is too granular. Geolocation data must not be used at any level more
+ granular than postal code. Note that while the number of people
+ living in a postal code varies from country to country, postal codes
+ are extant world-wide.</li>
+
+ <li>If specific consent has been granted for the use of more granular
+ location data, than that consent prevails.</li>
+ </ol>
+
+<!--- <section class="informative" id="geo-discussion">
+ <h3>Discussion</h3>It is acceptable to use data sent as part of this
+ particular network interaction when composing a response to a DNT:1
+ request, but it is not acceptable to store that data any longer than
+ needed to reply. For instance, it would be appropriate to use an IP
+ address to guess which country a user is in, to avoid showing them an
+ advertisement for products or services unavailable where they live.
+ </section>
+
+ <p>
+ When using request-specific information to compose a reply, some
+ levels of detail may feel invasive to users, and may violate their
+ expectations about Do Not Track. These sorts of detailed assessments
+ should be avoided.
+ </p>
+
+ <section class="informative" id="geo-examples">
+ <h3>Examples</h3>
+ <!-- It has been raised that the invasive example here may be getting
+ into UI territory. -->
+
+ <p>
+ Reasonable behavior: A user visits you from an IP address which a
+ general geo-IP database suggests is in the NYC area, where it is
+ 6pm on a Friday. You choose to show an advertisement for theaters
+ and restaurants in the area.
+ </p>
+ <p>
+ Invasive behavior: A user visits you from an IP address which
+ suggests that they are in a particular ZIP+4, which has a
+ distinctive demographic profile. Their user-agent indicates that
+ they are a Mac user, further narrowing their expected profile. You
+ serve them an ad for business within a few blocks of them which
+ specializes in items which their expected profile indicates they
+ may enjoy.
+ </p>
+ <p>
+ In this example, even though the decision about which ad to serve
+ was based exclusively on request specific information, but was
+ still tailored to a highly-specific user profile. In particular,
+ the estimation of a user's location to within a single ZIP+4 may
+ make a user feel that they are being followed closely, even if the
+ decision was made on the fly, and the information was only held
+ ephemerally.
+ </p>
+ </section> --->
+
+
<section id="permitted-uses">
<h3>Permitted Operational Uses for Third Parties and Service
Providers</h3>
@@ -1092,24 +1189,18 @@
<h5>Data Minimization and Transparency</h5>
<p>
-
- Data retained by a party for permitted uses MUST be limited to the data
- reasonably necessary for such permitted uses, and MUST be retained no
- longer than is reasonably necessary for such permitted uses. Third
- parties MUST make reasonable data minimization efforts to ensure
- that only the data necessary for the permitted use is retained. A
- third party MUST provide public transparency of their data
- retention period. The third party MAY enumerate each individually
- if they vary across Permitted Uses. Once the period of time for
- which you have declared data retention for a given use has expired,
- the data MUST NOT be used for that permitted use. After there are no
- remaining Permitted Uses for given data, the data must be deleted
- or rendered unlinkable.
+ Data retained by a party for permitted uses MUST be limited to the
+ data reasonably necessary for such permitted uses, and MUST be
+ retained no longer than is reasonably necessary for such permitted
+ uses. A third party MUST make reasonable data minimization efforts
+ to ensure that only data necessary for each permitted use is
+ retained. A third party MUST provide public transparency of their
+ data retention period for each permitted use. Once a retention
+ period for a given use has expired, the data MUST NOT be used for
+ that permitted use; when there are no remaining permitted uses for
+ some data, that data MUST either be deleted or rendered unlinkable.
</p>
- <p class="note">
- Jonathan Mayer to provide non-normative examples per ACTION-298.
- </p>
</section>
<section id="reasonable-security">
@@ -1124,12 +1215,12 @@
information security. Third parties SHOULD ensure that the access
and use of data retained for Permitted Uses is auditable.
</p>
- <p class="note">
+<!--- <p class="note">
Whether or not an audit, or the type of audit, is mandated is
still in discussion; an optional field exists in the TPE spec for
auditors and self-regulatory commitments. The audit section of
the TPE should be cross-referenced here.
- </p>
+ </p> --->
</section>
<section id="no-personalization">
@@ -1180,16 +1271,13 @@
<h5>Short Term Collection and Use</h5>
<p class="note">
- We have discussed allowing a N-week (anywhere from 1 week to 3
- months) grace period where third parties could collect and use
- data, partly due to concerns , partly as a compromise to the
- market research/aggregate reporting issue. We do not have
- consensus on this permitted use at this point. If we decide to
- allow this, we would need to add non-normative text explaining
- the rationale and providing examples.
+ This is not a consensus option. It has alternatively been proposed as
+ a way to address inadvertent collection, collection where party is not
+ sure whether collection or use is proper, and research/reporting. Those
+ issues may be addressed elsewhere.
</p>
<p class="option">
- Information may be collected and used any purpose, so long as the
+ Information may be collected, retained, and used any purpose, so long as the
information is retained for no longer than N weeks and the
information is not transmitted to a third party and the
information is not used to build a profile about a user or
@@ -1197,6 +1285,11 @@
changes that are made based on aggregate data or security
concerns).
</p>
+ <p class=option>
+ Operators MAY collect and retain data related to a communication in a
+ third-party context for up to N weeks. During this time, operators may
+ render data <dfn>deidentified</dfn> or perform processing of the data
+ for any of the other permitted uses.</p>
</section>
<section id="contextual">
@@ -1215,7 +1308,7 @@
domain that the user visited.
</p>
- <section class="informative" id="contextual-example">
+<!--- <section class="informative" id="contextual-example">
<h6>Examples</h6>
</section>
@@ -1241,7 +1334,7 @@
about the domain of the news site in order to render weather
information related to the city which ExampleLocalNews reports
on.</li>
- </ol>
+ </ol> --->
</section>
<section id="first-party-data">
@@ -1255,17 +1348,20 @@
user when acting as a first party.
</p>
- <p class=note>This text will be revised to offer two alternatives:
+ <p class=note>This text may be revised to offer two alternatives:
first parties can use any data to offer content in the third party
context, or first parties can only use declared data to offer
- content in the third party context. The issue is also contingent
+ content in the third party context. Shane Wiley has proposed
+ defining "declared data" as Information directly and expressly
+ supplied by a user to a party through meaningful interaction with
+ that party.<br><br>The issue is also contingent
upon what identifiers third parties can use in when Do Not Track is
turned on. If third parties cannot read cookies, they may be
unable to associate first parties in third-party scenarios.<br><br>
Others have argued that this language is unnecessary because the
standard places no limitations on the use of first party data.</p>
- <section class="informative" id="first-party-example">
+ <!--- <section class="informative" id="first-party-example">
<h6>Examples</h6>
<ol>
@@ -1296,7 +1392,7 @@
profile, and may only retain and use information about that
fact for a permitted operational use.</li>
</ol>
- </section>
+ </section> --->
</section>
<section id="frequency-capping">
@@ -1319,7 +1415,7 @@
other permitted uses.
</p>
- <section class="informative" id="frequency-capping-example">
+ <!--- <section class="informative" id="frequency-capping-example">
<h6>Examples</h6>
<p>
@@ -1334,7 +1430,7 @@
the user the ad for ExampleCars because the user has already
seen the ad five times on other sites.
</p>
- </section>
+ </section> --->
</section>
<section id="financial-logging">
@@ -1364,14 +1460,14 @@
identifiers) to uniquely count users who have DNT:1 enabled.
</p>
- <section class="informative" id="financial-logging-example">
+<!--- <section class="informative" id="financial-logging-example">
<h6>Examples</h6>
<p class="note">
Add examples for display verification, click verification, CPA,
quality measures
</p>
- </section>
+ </section> --->
</section>
<section id="security">
@@ -1390,14 +1486,14 @@
question of whether "graduated response" should be in the normative text, or
addressed through non-normative examples</p>
- <section class="informative" id="security-example">
+<!--- <section class="informative" id="security-example">
<h6>Examples</h6>
<p class="note">
Add examples with and without outsourced parties (J- not sure
what this means)
</p>
- </section>
+ </section> --->
</section>
<section id="debugging">
@@ -1409,7 +1505,7 @@
existing intended functionality.
</p>
- <section class="informative" id="debugging-discussion">
+ <!--- <section class="informative" id="debugging-discussion">
<h6>Discussion</h6>
<p>
@@ -1436,10 +1532,9 @@
particular set of variables resulted in a failure of expected
functionality or presentation.
</p>
- </section>
+ </section> --->
</section>
- <p class="issue" data-number="25" title="Possible exception for research purposes"></p>
<!--
<p class="note">Add examples once we pick an option.</p>
-->
@@ -1447,7 +1542,7 @@
<section id="compliance">
<h5>Compliance With Local Laws and Public Purposes</h5>
- <p class="note">
+ <!--- <p class="note">
The group has generally agreed that companies can collect and
process data as required by local law despite the DNT:1 signal
and still comply with this standard. We have also conceptually
@@ -1455,9 +1550,9 @@
contractual requirements between companies to collect data as a
"legally required" basis for the collection and use of data
despite a DNT:1 signal.
- </p>
+ </p> --->
<p>
- Regardless of DNT signal, information may be collected, retained
+ Regardless of DNT signal, information may be collected, retained, shared,
and used for complying with local laws and public purposes, such
as copyright protection and delivery of emergency services.
</p>
@@ -1480,90 +1575,15 @@
-->
</section>
- <section id="geolocation">
- <h4>Geolocation compliance by a third party</h4>
-
- <p class="note">
- Unclear whether this section reflects group consensus.
- </p>
-<!-- note - I moved this section because for some reason it was before
- the permitted uses generally
-<p class="note">TODO: Get Ian’s suggestions from the mailing list and
-Ian/dwainberg’s review of this geolocation section</p>
--->
[139 lines skipped]
Received on Monday, 4 February 2013 23:35:11 UTC