RE: Graduated response (ACTION-279)

Would it be possible to look at “graduated response” in the opposite direction as an element of data minimization?  Collect more data up-front (security, debugging, frequency capping) and move to less data where possible as a “graduated response”.  As I stated in Amsterdam, attempting to operational-ize a technical “graduated response” in the less->more sense is not a trivial matter (if at all really possible in most circumstances), whereas the opposite is much more doable.

- Shane

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com]
Sent: Wednesday, October 24, 2012 1:11 PM
To: public-tracking@w3.org Group WG
Subject: Graduated response (ACTION-279)

Currently the text in the document associated with "graduated response" is as follows:

6.1.1.6 Security and Fraud Prevention

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.

Nick's had a concept of a "graduated response" that was proposed to be worked in here. This concept probably applies equally to "Debugging" and we might want to have a definition of "graduated response" in the definitions part of the document, and then provide examples of what a graduated response might be with respect to security and with respect to debugging.

Here's my attempt at that approach:

Graduated Response

A graduated response a methodology where the action taken is proportional to the size of the problem or risk that is trying to be mitigated. In the context of this document, the term is used to describe an increase in the collection of data about a user or transaction 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 transactions from that specific range of IP addresses as opposed to increased logging for all users in general.



Then, in 6.1.1.6 we could say "A graduated response (as defined in x.y.z) is preferred."

Under specific non-normative examples for security, we could say:

An example of a graduated response to a security incident would be logging all users from a given IP address range, regardless of DNT signal, if the party believed it was seeing a coordinated attack on its service (such as click fraud) from that IP address range. Similarly, if that attack shared some other identifiable fingerprint (such as a combination of User Agent or other protocol information), the party could retain logs on transactions matching that fingerprint that the party reasonably believes are associated with such an attack.


Under specific non-normative examples for debugging, we could say:

An example of a graduated response to debugging would be to narrow the scope of users or transactions that exhibit a bug in the behaviour of the system, and then collect log data from only those users or transactions that are closely related to that particular bug in the system. For instance, if you noticed that users of UserAgentA version X were unable to complete purchases on your website, you might log and retain data relating specifically to users of UserAgentA version X when they are in the checkout flow of your website, but not increase retention of logs from users of UserAgentA version X as relates to other activity on your website, or from users of UserAgentB or users of UserAgentX version Y if only version X exhibited the problematic behaviour.


-Ian