W3C home > Mailing lists > Public > public-tracking@w3.org > June 2013

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

From: Dan Auerbach <dan@eff.org>
Date: Wed, 12 Jun 2013 15:14:02 -0700
Message-ID: <51B8F2AA.5040507@eff.org>
To: public-tracking@w3.org
Chris,

You, David, and I had a shared action item. The last thread between the
three of us ended with an email from me detailing some suggestions.
Before that was an email from David with concerns about your language.
Instead of engaging with us and trying to finish the action together,
you decided to unilaterally send your text out to the group and label it
as our shared text, despite the fact that David and I both subsequently
proposed revisions after your text was sent out. This is incredibly
disrespectful, and put me in a position where I had no choice but to
give the group more context about where I stand with respect to your
language. It is simply not accurate to label this as the language
associated with that open action.

As for the substance of my criticism and your reply, if you'd like, we
can email the entire thread to the group so that they can judge who has
provided more thoughtful analysis. It is inaccurate to say my criticism
amounted to saying "that's too verbose", but rather than rehashing that
thread all over again, I'd be happy to send it out with David's consent.

The goal of course would be to come to consensus language first between
the three of us, so that the full group could be spared from the
discussion, but since you've chosen to forego that path, it seems we
have no choice but to lay out both possibilities (as well as David's
latest draft, if he wishes) and consider this an unresolved open issue
for the group to debate.

If others have particular scenarios that they worry are not covered by
the language, I think we definitely should hear them, and include them
in whatever text gets finalized.

Dan

On 06/12/2013 01:34 PM, Chris Mejia wrote:
> Dan, respectfully, I don't appreciate the assertion that I have been
> unnecessarily "verbose", imprecise, or ill tailored in proposing my
> draft language to the working group for consideration.  Those are all
> baseless arguments.  I've explained to you in detail, in our back and
> forth discussions before the due date for this action item, why my
> constituency (industry security professionals) felt it necessary to
> include the language I've included.  Despite my detailed explanations
> to you, you've really only replied with "it's too verbose".  So if you
> disagree with the actual merits of my positions, or the merits of the
> proposed text, let's hear that.  Otherwise, I think we are largely in
> agreement on substance, and you'll be ok with my proposed language.
>
> Thanks,
>
> Chris
>
> ++++++++++++++++++++++++
> Chris Mejia
> Digital Supply Chain Solutions
> Ad Technology Group
> Interactive Advertising Bureau - IAB
>
>
> On Jun 12, 2013, at 2:32 PM, "Dan Auerbach" <dan@eff.org
> <mailto:dan@eff.org>> 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.
>>>
>>>
>>>
>>> /*
>>
Received on Wednesday, 12 June 2013 22:14:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:41 UTC