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

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

From: John Simpson <john@consumerwatchdog.org>
Date: Thu, 13 Jun 2013 11:21:30 -0700
Cc: Lee Tien <tien@eff.org>, "Roy T. Fielding" <fielding@gbiv.com>, W3C DNT Working Group Mailing List <public-tracking@w3.org>
Message-Id: <90720A80-2211-423F-9929-1FD5D69191B4@consumerwatchdog.org>
To: Chris Mejia <chris.mejia@iab.net>
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> 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> 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> 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> 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> 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.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 


Received on Thursday, 13 June 2013 18:22:02 UTC

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