- From: CVS User npdoty <cvsmail@w3.org>
- Date: Wed, 19 Nov 2014 06:25:43 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv27517
Modified Files:
tracking-compliance.html
Log Message:
issue-24 security section updated and consolidated
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html 2014/10/21 23:39:31 1.128
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html 2014/11/19 06:25:43 1.129
@@ -248,18 +248,6 @@
such party to collect data and engage in tracking.
</p>
</section>
- <section id="graduated-response">
- <h3>Graduated Response</h3>
- <p>
- A <dfn>graduated response</dfn> is a methodology where the action taken is proportional to the size of the problem or risk that is trying to be mitigated. In this specification, the term is used to describe an increase in the collection of data about a user or interaction in response to a specific problem that a party has become aware of, such as an increase in fraudulent activity originating from a particular network or IP address range resulting in increased logging of data relating to interactions from that specific range of IP addresses, as opposed to increased logging for all users in general.
- </p>
- <p class="note">
- Only used in security, below, and may overlap with the explanation
- there. Delete the definition and let it be defined the only place
- it's used?
- </p>
-
- </section>
</section> <!-- end definitions -->
<section id="server-compliance">
<h3>Server Compliance</h3>
@@ -439,25 +427,26 @@
<section id="security">
<h4>Security</h4>
- <p>Regardless of the tracking preference expressed, data MAY be collected
- and used to the extent reasonably necessary to detect <dfn>security</dfn>
- incidents, protect the service against malicious, deceptive, fraudulent,
- or illegal activity, and prosecute those responsible for such activity,
- provided that such data is not used for operational behavior
- (profiling or personalization) beyond what is reasonably necessary
- to protect the service or institute a <a>graduated response</a>.</p>
-
- <p>When feasible, a <a>graduated response</a> to a detected security incident
- is preferred over widespread data collection. An example would be recording
- all use from a given IP address range, regardless of DNT signal, if the
- party believes it is seeing a coordinated attack on its service (such as
- click fraud) from that IP address range. Similarly, if an attack shared
- some other identifiable fingerprint, such as a combination of User Agent
- and other protocol information, the party could retain logs on all
- interactions matching that fingerprint until it can be determined that
- they are not associated with such an attack or such retention is no
- longer necessary to support prosecution.</p>
-
+
+ <p>
+ Regardless of the tracking preference expressed, data MAY be collected and used to the extent reasonably necessary to detect <dfn>security</dfn> incidents, protect the service against malicious, deceptive, fraudulent, or illegal activity, and prosecute those responsible for such activity, provided that such data is not used for operational behavior beyond what is reasonably necessary to protect the service or institute a graduated response.
+ </p>
+ <p>
+ When feasible, a graduated response to a detected security incident is preferred over widespread data collection. In this recommendation, a <dfn>graduated response</dfn> is a data minimization methodology where actions taken are proportional to the problem or risk being mitigated.
+ </p>
+ <aside class="example">
+ <p>
+ Examples of using a graduated response for data minimization in security and fraud prevention include:
+ </p>
+ <ul>
+ <li>
+ recording all use from a given IP address range, regardless of DNT signal, when the party believes it is seeing a coordinated click fraud attack on its service from that IP address range.
+ </li>
+ <li>
+ collecting all data matching an identifiable fingerprint (a combination of User Agent and other protocol information, say) and retaining logs until it can be determined that they are not associated with such an attack or such retention is no longer necessary to support prosecution
+ </li>
+ </ul>
+ </aside>
</section>
<section id="debugging">
Received on Wednesday, 19 November 2014 06:26:03 UTC