Re: ACTION-408 - security & fraud proposed text - Section 6.2.

On Jun 13, 2013, at 6:16 AM, Chris Mejia wrote:

> Roy, John,
> 
> While I appreciate that you want to keep things simple, the ask of me was to vet the previous draft text with industry security professionials.  That's what I did, and the resultant text is what I proposed.  There are substantive reasons for the revised text-- we didn't just make it up to complicate things.

That's what I asked ... what are those reasons?

> The group asked for domain experts to weigh in, and that's what happened.

Sorry, I am more of a domain expert than anyone you asked, unless you
mean you asked lawyers about something other than technology.

>  With all respect, if you have particular substantive issues with the revised text, let's examine those-- I think it be more productive than dismissing the work we've done here; it wasn't done without thought.

Okay, here is what the current WD text says:

===========           

6.2.2.6 Security and Fraud Prevention

Information may be collected, retained and used to the extent
reasonably necessary for detecting security risks and fraudulent
or malicious activity.
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.

===========

and here is what is different with the text you suggested:

> 6.2.2.6 Detection, Prevention or Prosecution of Malicious, Nefarious or Invalid Activity

"Security" encompasses all of those words except "invalid", which
isn't actually used in your text.  "Nefarious" is a silly word to
use here -- it is just a dramatic form for malicious.

> Data may be collected, retained and used to the extent reasonably necessary for detecting and/or preventing malicious, nefarious or disingenuous activity.

"Information" -> "Data"
  -- editorial

"detecting" -> "detecting and/or preventing"
  -- unnecessary, data for detecting is a superset

"security risks and fraudulent or malicious" ->
"malicious, nefarious or disingenuous"
  -- nefarious speaks to reputation and disingenuous speaks to
     user beliefs, neither of which are relevant here

     Fraudulent is the correct word here. I know about David's
     concerns about the word "fraud" -- they are irrelevant because
     we are not talking about the legal definition of "fraud", but
     rather the adjective for criminal deception. If we need more
     adjectives, it would be "illegal or deceptive activity", not
     disingenuous and certainly not nefarious.

Clearly, none of the above changes were motivated by technical people.

> Additionally, data related to malicious, nefarious or disingenuous activity may be retained when reasonably necessary to support civil or criminal prosecution of parties that conduct, support or perpetuate malicious, nefarious or disingenuous activity.

This doesn't need to be stated because retention in that
case is reasonably necessary, and is further elaborated in the
definition for graduated response.

> This data may also be used to alter the user's experience in order to preserve or bolster the security of a site/service/user(s), or to prevent malicious, nefarious or disingenuous activity.

We have "reasonably keep a service secure or prevent fraud" because
it isn't actually possible to "prevent ... activity".  This change
is entirely misinformed, but the existing text is redundant anyway.

> The term "malicious, nefarious or disingenuous activity" means: 
> 
>     (a) disingenuous Web traffic/server requests (for example: non-human activity generating bogus server requests, ad-impressions or clicks);
> 
>     (b) bogus, malicious, automated or non-human Web-form submissions;
> 
>     (c) attacks intended to disrupt a site, service or user experience;
> 
>     (d) malicious or nefarious intrusions, or attempts to intrude into private or corporate networks;
> 
>     (e) fraudulent activity, including any activity that's purpose is to defraud a site, service or users of a site or service;
> 
>     (f) any activity that's reasonably determined to abuse, or attempts to abuse a site/service/user in any way.

And here we have an incomplete list of security risks, none of which
matter for the existing text because it just says "reasonably necessary
for detecting security risks and fraudulent or malicious activity".

(a) and (b) are challenged on so many levels that they aren't worth
discussing. Automated requests are not inherently disingenuous, but
they might be used for fraudulent purposes.  (c) and (d) is what
people who aren't in the security field think of as security.
(e) restates fraudulent in a way that is more limiting than its
dictionary definition.  (f) is nonsense except to the extent it
speaks to system integrity.

So, I say again, this text is not an improvement on what we already
have in a WD, is much longer, and actually covers a smaller space
of security concerns than actual practitioners like me will continue
to defend against regardless of any W3C standard.

If there is a problem with the existing text, then name it.
If you are concerned about retention for prosecution, that only
requires three words.  If you are concerned about the legal term
"fraud", then "deceptive or illegal" are good words to add.

In anticipation of those concerns (and Dan's), here is my
suggested replacement for the entire section, incorporating the
text that Ian suggested:

=====

   Regardless of the tracking preference expressed, data may be
   collected, retained, 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 (profiling or personalization)
   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 (see <defn>).
   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
   transactions 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.

=====


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

Received on Thursday, 13 June 2013 20:53:05 UTC