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

Ok Roy, I'm happy to answer your questions below and defend my proposal
where it's defensible.  You've brought up some interesting points, and
I'll consider those as well.  I've also posed a few questions back to you.
Thanks for being more pointed and candid here-- that's helpful.  See my
replies and question to you below, marked "CM:"

-Chris



On 6/13/13 3:42 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

>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?


CM: General response for a general question: According to those I
consulted, and based on my own experience with advertising specific
threats, the old text did not adequately cover everything related to how
advertising industry security and fraud professionals reasonably use data
for site/service/network/user security and fraud
detection/prevention/prosecution purposes.


>
>> 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.


CM:  Sorry Roy, but I don't actually know that to be the case. I don't
mean that with any disrespect for your experience or knowledge.  I did
consult an array of security and fraud professionals though, including
heads of security and fraud prevention operations for Fortune companies,
software engineers (some of whom have between 10-18 years experience
working in this field), lawyers and business people.


>
>>  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.


CM:  Good catch on the word invalid in the heading-- that should have been
changed in the subject line to "disingenuous".  The words all have
separate (albeit related) meanings, especially in legal contexts, which is
why I included them in my proposal.  For example, nefarious and malicious
are differentiated by intent.  It was pointed out to me, by a lawyer who
prosecutes these sorts of cases, that it's possible to have nefarious
intent and not be found malicious.  An actor found to be nefarious may be
prosecuted to a lesser extent than someone found to be malicious.  Now I'm
not a lawyer, to be clear.  And some lawyers would likely argue that there
is no difference.  But one lawyer with specific experience prosecuting
these sorts of cases, did suggest the change.  In any case, what's your
particular issue with including all/any of these words?  Is your issue
more semantic, or is there another substantive reason for the exclusion of
certain words?


>
>> 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


CM: By information, I assume you mean data, no?  Isn't the scope of DNT
around data collection and use?  If so, why not call it data?  Information
can have a lot of other meanings that I don't think are germane to the
scope here.  Can you support the use of the word information over the word
data for this section?


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


CM: Again, even if YOU find it redundant, but others don't, what's your
particular issue with leaving it in?  There is an operational difference
between detecting and preventing. Both should be allowed.  Do you disagree?


>
>"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


CM: as they relate to the word "traffic" (or server requests), these words
have distinct meaning.  We want to detect and prevent nefarious traffic,
and disingenuous traffic.  I'm not sure what "invalid" traffic is?  I
think I know what you might mean, but the traffic itself is just traffic--
it's not invalid per se, it's just traffic. Again, all of these
descriptors relate to the intent of the traffic.

Nefarious means evil; wicked; sinful. The word's meaning does not "speak"
to reputation.  It can relate to reputation, but that is not an exclusive
meaning/use of the word. Reputation is past tense. Nefarious can be
present tense.

Similarly, I did not tie the word disingenuous to "user beliefs" per se;
my intent was to tie it to the traffic itself, and the intent of that
traffic, sent by a user (bad actor, in this case).

Definition of disingenuous:  lacking in candor; also : giving a false
appearance of simple frankness: calculating

I think these are appropriate words to categorize the type of traffic we'd
like to detect, prevent and prosecute, in addition to malicious traffic of
course.  These are words we commonly use in the digital advertising
industry when relating to this type of traffic.


>
>     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.


CM:  David was not the only person concerned with the word fraud here. But
to be sure, we did leave fraud in the proposed text (moved it down
though).  In your argument above, you say that the concern about the use
of the word fraud here is irrelevant-- but I'd point out that it IS
relevant if you are going to prosecute (go to court).  In this context,
the legal definition of the word fraud is important.  Btw, I can't find a
reference to "criminal deception" as it relates to fraud-- criminal is a
relative term, that's jurisdictionally defined by local laws.

I'm not opposed to "illegal" or "deceptive" in addition to the other words
we have proposed, but on their own, I find them too narrow and limiting
for our purpose here.


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


CM:  Not true. I've replied to you about this off-thread.


>
>> 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.


CM: In my proposed text, I'm making it crystal clear what is "reasonably
necessary", rather than leaving that up to speculation and interpretation.
 I have issues with the graduated response model for DNT. I don't think we
need to specify a response structure-- THAT would be limiting.


>
>> 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.


CM:  Disagree that it's not possible to prevent activity.  But if you
don't like the word prevent, then I'm open to another word in addition or
in place of prevent.  Defend?  Deter?


>
>> 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".


CM:  I think you're putting a lot of dependence on the term "reasonably
necessary" if you are going to use it with less context.


>
>(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.


CM: If they are used for "fraudulent purposes" they are disingenuous-- see
definition of disingenuous above.  Btw, it's also possible to have
disingenuous traffic that's not fraudulent per se (per the legal
definition)


>(c) and (d) is what
>people who aren't in the security field think of as security.


CM:  Well, that's funny then.  What do you propose as an alternative in
this case, rather than just shooting it down?  How do you define security
Roy?


>(e) restates fraudulent in a way that is more limiting than its
>dictionary definition.


CM: please describe how it's MORE limiting?


>(f) is nonsense except to the extent it
>speaks to system integrity.


CM:  By your own accord then, it's not nonsense.  Btw, disagree with you
about it's limitation to system integrity only.


>
>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.


CM:  Roy, if you intend to ignore it anyway, why do you care so much about
it and what it says?  You are one practitioner, but you are not the only
practitioner with an opinion.  Regardless, I don't think I've proposed
anything here that would limit you-- if so, what is it?  I also don't see
how the original text covered a larger set of security concerns?


>
>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.


CM: I like a few more words, so if those extra words don't limit you,
what's the problem?


>If you are concerned about the legal term
>"fraud", then "deceptive or illegal" are good words to add.


CM: Agreed-- see above where I also agreed with you on this point.


>
>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 Friday, 14 June 2013 03:47:56 UTC