Re: ISSUE-24 (fraud detection and defense)

On an earlier call, I agreed to merge the text David had drafted in this thread with the text we had in the editor's draft to clarify and to address Shane's concerns expressed on that call. Below is my proposal. This addresses action-462.

This creates a shorter definition of graduated response that notes it as a data minimization methodology. As before, it includes no additional normative requirements. It adds a separate example box with the examples that we previously had mixed into the definition and normative text. Examples include both "ramping up" and "ramping down" cases. This proposal also cleans up an editorial note that the graduated response definition was in the terminology section but is only used in this security section and its definition included examples which were redundant. This removes that separate definition.

I really hope this will be sufficient to close out this quite old issue.

> Regardless of the tracking preference expressed, data MAY be collected and used to the extent reasonably necessary to detect security 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.
> 
> When feasible, a graduated response to a detected security incident is preferred over widespread data collection. In this recommendation, a graduated response is a data minimization methodology where actions taken are proportional to the problem or risk being mitigated.
> 
> ---EXAMPLE---
> Examples of using a graduated response for data minimization in security and fraud prevention include:
> * 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
> * 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


I made only slight changes to the first paragraph (removing a parenthetical). I believe the reason we have the reasonably necessary clause at the end (as opposed to just relying on the general requirements on permitted uses) is that we're specifically noting here that some personalization might occur in the course of implementing a security response, and we want to say that that's allowed but that not all types of personalization are allowed.

Formatting in email is hard, but the ---EXAMPLE--- header indicates an example block (with a different color background, etc.) to note that it's an example. I suspect it would also be non-controversial to add one or two more specific examples there if people want to send them in. (I didn't include all of David's because some of that language was high-level rather than something you'd expect in an example box.)

Thanks,
Nick

Relevant links:
dsinger's email: http://lists.w3.org/Archives/Public/public-tracking/2014Oct/0032.html
teleconference minutes: http://www.w3.org/2014/10/15-dnt-minutes#item02
editor's draft section: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#security