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

I believe that the motivation for this text stemmed from concern about
specifying "fraud" and "malicious activity" in particular as it would
leave out other types of invalid activity. Is an automated account
sign-up that is disallowed by a service considered "fraud" or "malicious
activity"? I'm not sure if there is precedent around these sorts of
issues. Instead of relying on the general language, we were attempting
to provide greater clarity for the actual security and fraud uses, so
that security folks could breathe more easily and not worry about DNT. I
would be OK with the old text too.

Dan

On 06/13/2013 12:13 PM, John Simpson wrote:
> This not attack.  It is a question seeking clarification that is meant
> for all of you involved in offering the new security text.  You, Dan
> and David.   Chris, you've been most active on the email chain, so
> most of the messages have been in response to you.
>
> But could one of the three of you please explain what was wrong with
> the text many of us thought had consensus agreement and how your
> proposals fix that?
>
> Thanks.
>
>
> On Jun 13, 2013, at 12:03 PM, Chris Mejia <chris.mejia@iab.net
> <mailto:chris.mejia@iab.net>> wrote:
>
>> Peter: can you please cue this up for a call?  Doesn't have to be on
>> the weekly call— but those with real concerns on my proposed text
>> should be invited so they may ask their questions, and I can defend
>> my proposal.
>>
>> John: if you mean that we all hummed (or at least those of us who
>> were in the room at the time a "hum" was called, hummed— not to be
>> confused with a vote, because we don't vote in this working group),
>> and the former co-chair did her best to interpret the loudness of the
>> humming in the room, and her determination based on the loudness of
>> the humming was used as a proxy for real consensus, then your right.
>>  If you think we had REAL consensus on this topic though, your
>> mistaken.  And if I'm not mistaken, we are still drafting the entire
>> spec, and I'm now submitting this text for consideration to be
>> included with the last call draft document.  
>>
>> Btw- Dan has offered a proposal and I don't see you busting him on
>> it.  Why not?  On a personal note, I don't appreciate your biased
>> attacks.  I offered something of substance.  If you don't understand
>> the substance, then ask me about what you don't understand (in
>> particular), and I'll be happy to answer.  Otherwise, I'm glad that
>> was your "one last try".
>>
>> Chris
>>
>> Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group |
>> Interactive Advertising Bureau – IAB 
>>
>> From: John Simpson <john@consumerwatchdog.org
>> <mailto:john@consumerwatchdog.org>>
>> Date: Thursday, June 13, 2013 1:50 PM
>> To: Chris Mejia - IAB <chris.mejia@iab.net <mailto:chris.mejia@iab.net>>
>> Cc: Lee Tien <tien@eff.org <mailto:tien@eff.org>>, "Roy T. Fielding"
>> <fielding@gbiv.com <mailto:fielding@gbiv.com>>, W3C DNT Working Group
>> Mailing List <public-tracking@w3.org <mailto:public-tracking@w3.org>>
>> Subject: Re: ACTION-408 - security & fraud proposed text - Section 6.2.
>>
>> I'll give this one last try.  There was text that many of us --
>> including industry professionals well aware of security issues --
>> thought had been settled by consensus a year or so ago. You want to
>> propose new text.  I've always understood that if you're offering new
>> text you need to explain what's wrong with the existing text and why
>> the proposal is better. 
>>
>> I'm not fishing for anything other than understanding.  One last
>> time: What's deficient in the old text?  How does the new proposal
>> fix that?
>>
>>
>>
>> On Jun 13, 2013, at 11:40 AM, Chris Mejia <chris.mejia@iab.net
>> <mailto:chris.mejia@iab.net>> wrote:
>>
>>> John,
>>>
>>> I'm happy to answer SPECIFIC questions you have about the new
>>> proposed text I submitted.  Ask away.  Otherwise, I thought the text
>>> I proposed was self-explanitory (which might explain why Dan
>>> considered it to be "verbose").  If you have a question on
>>> substance, I'm here to answer it.  But please ask pointed questions
>>> on the merits of my proposal— is that too much to ask?
>>>
>>> You should also know that I provided Dan and Alan very specific
>>> reasons for my edit requests in the new draft, while we were
>>> drafting in our sub-group.  We can re-hash those, but at least Dan
>>> had the courtesy to ask pointed questions and raise specific
>>> concerns— all of which I replied to in that sub group.  Sounds to me
>>> like you're just fishing here…  If I'm wrong, your next reply should
>>> be a list of your specific concerns about my proposed text.  If you
>>> don't have pointed and substantive concerns, then you should be
>>> satisfied with the proposal as-is— again, it's self-explanitory.
>>>  Tell me what you don't understand…
>>>
>>> Chris
>>>
>>> Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group |
>>> Interactive Advertising Bureau - IAB
>>>
>>> From: John Simpson <john@consumerwatchdog.org
>>> <mailto:john@consumerwatchdog.org>>
>>> Date: Thursday, June 13, 2013 1:21 PM
>>> To: Chris Mejia - IAB <chris.mejia@iab.net <mailto:chris.mejia@iab.net>>
>>> Cc: Lee Tien <tien@eff.org <mailto:tien@eff.org>>, "Roy T. Fielding"
>>> <fielding@gbiv.com <mailto:fielding@gbiv.com>>, W3C DNT Working
>>> Group Mailing List <public-tracking@w3.org
>>> <mailto:public-tracking@w3.org>>
>>> Subject: Re: ACTION-408 - security & fraud proposed text - Section 6.2.
>>>
>>> Chris,
>>>
>>> I don't think this is the way the working group works at all.
>>>
>>> There was long standing text that was thought to represent a
>>> consensus for more than a year.  People are asking you to please
>>> explain why that text is deficient and how the new proposed text
>>> solves that deficiency.  It is simply a request for clarification.
>>>  In other words, this was the problem with the existing text and
>>> this if how the proposed text solves that...
>>>
>>> You answer seems to be, "I talked to security professionals and this
>>> is the text I am proposing based on those talks. Trust me."
>>>
>>> That isn't at all helpful to understanding the issues or clarifying
>>> what's at stake.
>>>
>>> John
>>>
>>> On Jun 13, 2013, at 7:39 AM, Chris Mejia <chris.mejia@iab.net
>>> <mailto:chris.mejia@iab.net>> wrote:
>>>
>>>> Lee,
>>>>
>>>> I'm happy to answer any specific questions you have about the
>>>> substance of the text-- that's normally how this working group
>>>> works.  Would you kindly be more specific about your request for
>>>> more information?  Is there something in particular you have a
>>>> concern about in the text I proposed?
>>>>
>>>> Thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>>> On Jun 13, 2013, at 9:22 AM, "Lee Tien" <tien@eff.org
>>>> <mailto:tien@eff.org>> wrote:
>>>>
>>>>> Chris, perhaps you could explain the text differences in terms of
>>>>> the substantive reasons gleaned from the industry security
>>>>> professionals?  
>>>>>
>>>>> Lee
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jun 13, 2013, at 6:16 AM, Chris Mejia <chris.mejia@iab.net
>>>>> <mailto:chris.mejia@iab.net>> 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. The group
>>>>>> asked for domain experts to weigh in, and that's what happened.
>>>>>>  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.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> On Jun 12, 2013, at 8:26 PM, "John Simpson"
>>>>>> <john@consumerwatchdog.org <mailto:john@consumerwatchdog.org>> wrote:
>>>>>>
>>>>>>> I must say I agree with Roy's take here.  What is wrong with the
>>>>>>> language on security and fraud that is in the April 29 Public
>>>>>>> Working Draft?  I though the outstanding issue was around
>>>>>>> graduated response and I don't see how any of the new text
>>>>>>> addresses that…
>>>>>>>
>>>>>>> On Jun 12, 2013, at 4:37 PM, Roy T. Fielding <fielding@gbiv.com
>>>>>>> <mailto:fielding@gbiv.com>> wrote:
>>>>>>>
>>>>>>>> While I appreciate that some folks are actually making good on
>>>>>>>> their
>>>>>>>> action items, these proposed texts are not an improvement over what
>>>>>>>> has already been published in the compliance spec WD:
>>>>>>>>
>>>>>>>> http://www.w3.org/TR/2013/WD-tracking-compliance-20130430/#security
>>>>>>>>
>>>>>>>> and for which the only open concern I am aware of is the last
>>>>>>>> sentence
>>>>>>>> that requires a definition of graduated response, for which we
>>>>>>>> had an
>>>>>>>> apparent agreement at the F2F to adopt Ian's proposed definition.
>>>>>>>>
>>>>>>>> So, why are we even talking about this?  What exactly do you object
>>>>>>>> to in the text that is in the WD?
>>>>>>>>
>>>>>>>> [I am ignoring the June draft, at the moment, since it has almost
>>>>>>>> the same text as the WD except the section numbering is gone
>>>>>>>> and the
>>>>>>>> first sentence has been reversed in a way that makes it harder to
>>>>>>>> read.]
>>>>>>>>
>>>>>>>> ....Roy
>>>>>>>>
>>>>>>>> On Jun 12, 2013, at 12:33 PM, Dan Auerbach wrote:
>>>>>>>>
>>>>>>>>> We largely agree but Chris's text was not agreed to be the
>>>>>>>>> version we sent out. But here's my version, which I think is
>>>>>>>>> more precise, appropriately tailored, and less verbose:
>>>>>>>>>
>>>>>>>>> /6.2.2.6 Detection and Prevention //of Malicious or Invalid
>>>>>>>>> Activity//
>>>>>>>>> //
>>>>>>>>> //Information may be collected, retained and used to the
>>>>>>>>> extent reasonably necessary for detecting and preventing
>>>>>>>>> //malicious or invalid //activity. Information related to
>>>>>>>>> malicious or invalid activity may furthermore be retained if
>>>>>>>>> necessary for particular civil actions being pursued, or for
>>>>>>>>> particular criminal investigations that are in process.
>>>>>>>>> ///This// information may be used to alter the user's
>>>>>>>>> experience in order to reasonably keep a service secure //or
>>>>>>>>> prevent//malicious or invalid activity./
>>>>>>>>>
>>>>>>>>> The term "malicious or invalid activity"//means:
>>>>>>>>>     (a) //invalid Web traffic (for instance bot activity
>>>>>>>>> generating impressions or clicks),
>>>>>>>>>     (b) bogus, malicious or automated sign ups or form
>>>>>>>>> submissions,
>>>>>>>>>     (c) attacks intended to disrupt the availability of a
>>>>>>>>> service,
>>>>>>>>>     (d) malicious intrusions into corporate networks,
>>>>>>>>>     (e) fraud prevention, //or
>>>>>>>>>     (f) abuse of a service in a way that harms the integrity
>>>>>>>>> or security of a service or the security of the users of a
>>>>>>>>> service./
>>>>>>>>>
>>>>>>>>> On 06/12/2013 09:17 AM, Chris Mejia wrote:
>>>>>>>>>> David Wainberg, Dan Auerbach and I worked on this draft text.
>>>>>>>>>>  I'm submitting it now for consideration by the wider group,
>>>>>>>>>> as there were only small gaps between Dan and our text proposals.
>>>>>>>>>> */
>>>>>>>>>> /*
>>>>>>>>>> */--/*
>>>>>>>>>> */
>>>>>>>>>> /*
>>>>>>>>>> */
>>>>>>>>>>
>>>>>>>>>> 6.2.2.6 Detection, Prevention or Prosecution of
>>>>>>>>>> Malicious, Nefarious or Invalid Activity
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> Data may be collected, retained and used to the extent
>>>>>>>>>> reasonably necessary for detecting and/or
>>>>>>>>>> preventing malicious, nefarious or disingenuous activity. 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 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. 
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>
>>
>