- From: Justin Brookman via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 04 Oct 2012 11:29:31 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv18081
Modified Files:
tracking-compliance.html
Log Message:
Addressed recently assigned ACTION items and typos
Index: tracking-compliance.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -d -r1.80 -r1.81
--- tracking-compliance.html 2 Oct 2012 09:05:27 -0000 1.80
+++ tracking-compliance.html 4 Oct 2012 11:29:29 -0000 1.81
@@ -918,7 +918,7 @@
is a third party. The user has interacted with Example
Weather's widget, but an ordinary user would not expect that
scrolling through the widget involves communicating with
- Example News.</li>
+ Example Weather.</li>
<li>Example Social, a popular social network, hosts a social
sharing button that other websites can embed. The button is
@@ -939,10 +939,10 @@
<h5>Option 2: First and Third Parties</h5>
<p>
- First Party is the party that owns the Web site or has control over
- the Web site the consumer visits. A First Party also includes
- the owner of a widget, search box or similar service with which a
- consumer interacts.
+ First Party is the party that owns or has control over
+ the resource the consumer visits. A First Party also includes
+ the owner or controller of an embedded widget, search box or similar
+ service with which a consumer interacts.
</p>
<p class="note">
If a user merely mouses over, closes, or mutes third-party content,
@@ -1069,7 +1069,7 @@
<p>
A party may receive, retain, and use data as otherwise prohibited
- by this standard, so long as is unaware of such information
+ by this standard, so long as it is unaware of such information
practices and has made reasonable efforts to understand its
information practices. If a party learns that it possesses
information in violation of this standard, it must delete that
@@ -1406,8 +1406,111 @@
<p>
These permitted uses and requirements are further discussed below.
</p>
+
+ <section id="permitted-use-requirements">
+ <h4>Global Requirements for Permitted Uses</h4>
+
+ <p>
+ In order to use the Permitted Uses outlined below, a party MUST comply
+ with these four requirements.
+ </p>
+
+ <section id="no-secondary-uses">
+ <h5>No Secondary Uses</h5>
+
+ <p>
+ Third Parties MUST NOT use data retained for permitted uses for
+ non-permitted uses.
+ </p>
+ </section>
+
+ <section id="data-minimization-and-transparency">
+ <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.
+ </p>
+
+ <p class="note">
+ Jonathan Mayer to provide non-normative examples per ACTION-298.
+ </p>
+ </section>
+
+ <section id="reasonable-security">
+ <h5>Reasonable Security</h5>
+
+ <p>
+ Third parties MUST use reasonable technical and organizational
+ safeguards to prevent further processing of data retained for
+ Permitted Uses. 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. Third parties SHOULD ensure that the access
+ and use of data retained for Permitted Uses is auditable.
+ </p>
+ <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>
+ </section>
+
+ <section id="no-personalization">
+ <h5>No Personalization</h5>
+
+ <p>
+ Outside of Security and Frequency Capping, data retained for
+ Permitted Uses MUST NOT be used to alter a specific user's online
+ experience based on multi-site activity.
+ </p>
+ </section>
+
+ <section id="no-persistent-identifiers">
+ <h5>No Persistent Identifiers</h5>
+
+ <p class="option">
+ A third party may only collect, use, and retain for permitted
+ uses information that a user agent necessarily shares with a web
+ server when it communicates with the web server (e.g. IP address
+ and User-Agent), and the URL of the top-level page, communicated
+ via a Referer header or other means, unless the URL contains
+ information that is not unlinkable (e.g. a username or user
+ ID).<br>
+ <br>
+ A third party may not collect, use, or retain information that a
+ web server could cause to not be sent but still be able to
+ communicate with the user agent (e.g. a cookie or a Request-URI
+ parameter generated by the user agent), except the URL of the
+ top-level page, or any data added by a network intermediary that
+ the operator of a web server has actual knowledge of (e.g. a
+ unique device identifier HTTP header).
+ </p>
+
+ <p class="note">
+ The EFF/Mozilla/Stanford proposal is heavily dependent upon a
+ requirement that permitted use data is not correlated to a unique
+ cookie or other persistent identifier. This issue remains one of
+ the biggest areas of dispute in the working group, as the
+ industry proposal allows for the use of cookies and other unique
+ identifiers by third parties despite a DNT:1 instruction.
+ </p>
+ </section></section>
+
<section id="enumerated-uses">
- <h4>Enumerated Uses</h4>
+ <h4>Enumerated Permitted Uses</h4>
<section id="short-term">
<h5>Short Term Collection and Use</h5>
@@ -1489,7 +1592,7 @@
<p class="option">
Regardless of DNT signal, information may be collected, retained
and used for the display of content or advertisements based in
- part of data that the third party previously collected from the
+ part on data that the third party previously collected from the
user when acting as a first party.
</p>
@@ -1498,7 +1601,7 @@
<ol>
<li>A user visits ExampleNews.com with DNT:1 enabled to read a
- story about a national election. ExamplesNews uses the third
+ story about a national election. ExampleNews uses the third
party ExamplePortal to serve content and advertisements on its
site. ExamplePortal is not an outsourcing partner of
ExampleNews. The user had previously visited ExamplePortal.com
@@ -1551,11 +1654,11 @@
<h6>Examples</h6>
<p>
- A user visits ExampleNews with DNT:1 enabled. ExamplesNews uses
+ A user visits ExampleNews with DNT:1 enabled. ExampleNews uses
the third party ExampleAds to serve content and advertisements
on its site. ExampleAds is not an outsourcing partner of
ExampleNews. ExampleAds has previously shown the user an ad for
- ExampleCars fives times in the past week on other sites.
+ ExampleCars five times in the past week on other sites.
ExampleCars' contract with Example Ads states that Example Ads
will be paid less for impressions where the user sees an ad
more than five times in a week. ExampleAds may opt not to show
@@ -1605,36 +1708,18 @@
<section id="security">
<h5>Security and Fraud Prevention</h5>
- <p>
- Regardless of DNT signal, information may be collected, retained
- and used for 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. In this example specifically, this information may be
- used to alter the user's experience in order to reasonably keep a
- service secure or prevent fraud.
- </p>
- <div class="note">
- <p>
- The more likely options at this point may be represented in
- Nick Doty's proposed:
- </p>
- <blockquote>
- To the extent reasonably necessary for protection of computers
- and networks and to detect ad or other fraud, third parties may
- engage in tracking. Use of graduated response is preferred.
- </blockquote>
- <p>
- or David Wainberg's proposed:
- </p>
- <blockquote>
- Parties may collect and use data in any way to the extent
- reasonably necessary for the detection and prevention of
- malicious or illegitimate activity.
- </blockquote>
- </div>
+ <p>To the extent reasonably necessary for detecting security risks and
+ fraudulent or malicious activity, parties may collect, retain, and use data
+ regardless of a DNT signal. This includes data reasonably necessary for
+ enabling authentication/verification, detecting hostile and invalid
+ transactions and attacks, providing fraud prevention, and maintaining system
+ integrity. In this example specifically, this information may be used to alter
+ the user's experience in order to reasonably keep a service secure or prevent
+ fraud. Graduated response is preferred when feasible.</p>
+
+ <p=note>There is an open action to define "graduated response," and an open
+ question of whether "graduated response" should be in the normative text, or
+ addressed through non-normative examples</p>
<section class="informative" id="security-example">
<h6>Examples</h6>
@@ -1685,54 +1770,7 @@
</section>
</section>
- <section id="aggregate-reporting">
- <h5>Aggregate Reporting</h5>
-<!--
-<p class="note">Text is based on breakout group discussion, and large group
-presentation, at the Seattle meeting. However, there is not group consensus
-that this should be a permitted operational use.</p>
--->
-
- <section class="option" id="pu-aggregate-opt-1">
- <h6>Option 1: Aggregate Reporting</h6>
-
- <p>
- Regardless of DNT signal, information may be collected,
- retained and used for aggregate reporting, such as market
- research and product improvement. Data MAY be collected and
- retained on an individual level, but the use of the data must
- only be aggregate reporting, and the products of the reporting
- MUST be unlinkable as defined in this document.
- </p>
- </section>
-
- <section class="option" id="pu-aggregate-opt-2">
- <h6>Option 2: Aggregate Reporting</h6>
-
- <p>
- Regardless of DNT signal, information may be collected,
- retained and used for aggregate reporting, such as market
- research and product improvement, if that information is
- collected and retained for another enumerated permitted use.
- Data MAY be collected and retained on an individual level, but
- the use of the data must only be aggregate reporting, and the
- products of the reporting MUST be unlinkable as defined in this
- document. If the operator no longer has another enumerated
- permitted use for which to use and retain the data, the
- operator MAY NOT use and retain the data for aggregate
- reporting unless the data has been rendered unlinkable as
- defined in this document.
- </p>
- </section>
-
- <section class="option" id="pu-aggregate-opt-3">
- <h6>Option 3: No Aggregate Reporting</h6>
-
- <p>
- There is no permitted use for aggregate reporting outside of
- the grace period described earlier.
- </p>
- </section>
+
</section>
<p class="issue" data-number="25" title="Possible exception for research purposes"></p>
@@ -1757,110 +1795,13 @@
and used for complying with local laws and public purposes, such
as copyright protection and delivery of emergency services.
</p>
+
+ <p class=note>There had previously been an open debate about whether Aggregate Reporting
+ (including market research and product improvement) should be a dedicated Permitted Use.
+ The group has since decided to address this issue through the exception for Unlinkable Data.</p>
+
</section>
- </section>
-
- <section id="permitted-use-requirements">
- <h4>Additional Requirements for Permitted Uses</h4>
-
- <p>
- In order to use the Permitted Uses outlined, a party must comply
- with these four requirements.
- </p>
-
- <section id="no-secondary-uses">
- <h5>No Secondary Uses</h5>
-
- <p>
- Third Parties MUST NOT use data retained for permitted uses for
- non-permitted uses.
- </p>
- </section>
-
- <section id="data-minimization-and-transparency">
- <h5>Data Minimization and Transparency</h5>
-
- <p>
- A third party MUST ONLY retain information for a Permitted Use
- for as long as is reasonably necessary for that use. 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, 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.
- </p>
-
- <p class="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
- </p>
- </section>
-
- <section id="reasonable-security">
- <h5>Reasonable Security</h5>
-
- <p>
- Third parties MUST use reasonable technical and organizational
- safeguards to prevent further processing of data retained for
- Permitted Uses. 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. Third parties SHOULD ensure that the access
- and use of data retained for Permitted Uses is auditable.
- </p>
- <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>
- </section>
-
- <section id="no-personalization">
- <h5>No Personalization</h5>
-
- <p>
- Outside of Security and Frequency Capping, data retained for
- Permitted Uses MUST NOT be used to alter a specific user's online
- experience based on multi-site activity.
- </p>
- </section>
-
- <section id="no-persistent-identifiers">
- <h5>No Persistent Identifiers</h5>
-
- <p class="option">
- A third party may only collect, use, and retain for permitted
- uses information that a user agent necessarily shares with a web
- server when it communicates with the web server (e.g. IP address
- and User-Agent), and the URL of the top-level page, communicated
- via a Referer header or other means, unless the URL contains
- information that is not unlinkable (e.g. a username or user
- ID).<br>
- <br>
- A third party may not collect, use, or retain information that a
- web server could cause to not be sent but still be able to
- communicate with the user agent (e.g. a cookie or a Request-URI
- parameter generated by the user agent), except the URL of the
- top-level page, or any data added by a network intermediary that
- the operator of a web server has actual knowledge of (e.g. a
- unique device identifier HTTP header).
- </p>
-
- <p class="note">
- The EFF/Mozilla/Stanford proposal is heavily dependent upon a
- requirement that permitted use data is not correlated to a unique
- cookie or other persistent identifier. This issue remains one of
- the biggest areas of dispute in the working group, as the
- industry proposal allows for the use of cookies and other unique
- identifiers by third parties despite a DNT:1 instruction.
- </p>
- </section>
+
<!--
<p class="issue" data-number="24" title="Possible permitted use for fraud detection and defense"></p>
<p class="issue" data-number="25" title="Possible permitted use for research purposes"></p>
Received on Thursday, 4 October 2012 11:29:32 UTC