- From: Chris Mejia <chris.mejia@iab.net>
- Date: Fri, 14 Jun 2013 03:46:47 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: W3C DNT Working Group Mailing List <public-tracking@w3.org>
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