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