Re: SOX Requirements RE: ACTION-216 - Financial Reporting "Exceptions"

Hi Tamir, all,

I appreciate your question, but as a general rule, we shouldn't post
industry fraud prevention techniques/information to any public forum-- the
bad guys scrape these forums looking for useful information.  That's just
a gentle reminder to industry folks on the forum.  And please don't
construe my message here as an attempt to stonewall these proceedings--
that is not my intention.  I just want us all to be prudent when it comes
to security and user/publisher protection.

Kind Regards,

Chris

Chris Mejia | Digital Supply Chain Solutions | Ad Technology Group |
Interactive Advertising Bureau - IAB






On 8/21/12 2:45 PM, "Tamir Israel" <tisrael@cippic.ca> wrote:

>Hi Brooks,
>
>Sorry for getting back to this so late.
>
>I'm wondering, if it's overt attempts at defrauding that are the case
>study, does UID really take care of this problem? How hard would it be
>to go the extra step and add in random UIDs into [time], [ad], [event]
>based on prior/future logs if the scenario you're referring to comes up?
>
>Conversely, on the fraud detection flip side (where the server is trying
>to prevent gaming of its systems) how does this work with users who
>regularly delete UID cookies?
>
>Thanks again,
>Tamir
>
>On 7/30/2012 10:48 AM, Dobbs, Brooks wrote:
>> Maybe it is helpful to back up and look at what contractually is being
>> sold (CPM as an example).  It is NOT impressions; it is a subset of
>> impressions and it is confidence in this subset.  It is impressions
>>which
>> have been filtered for quality, where a large part of the filtration
>> occurs on IP address (and other data as well).
>>
>> Allow me to digress into a story. HypotheticallyŠ in 1995 I knew someone
>> who wrote a really bad PERL based adserver for the online newspaper
>>where
>> he worked.  One Friday before he left for the weekend, he failed to make
>> sure there was enough disk space for logging to make it through till
>> Monday morning.  Predictably, sometime late Sunday evening we ran out of
>> disk space.  Knowing the ads at that time where just in simple rotation,
>> he "fixed" the problem by copying Saturday evening's logs, adding 86,400
>> seconds to each event, and appended this to what I actually had for
>> Sunday.  Okay before you act horrified at the crime perpetrated here,
>>know
>> that we made about $10-15 in ad revenue from 15 clients for the entire
>> weekend so billing may have been off by pennies.
>>
>> The point here is that sites don¹t use homegrown PERL logs anymore and
>>we
>> aren't talking $10, but the core data is the same.  Now we use reputable
>> 3rd parties who participate in audits that look at things like IP
>> addresses, cookies and UA combos to make sure no one cooked the books or
>> has even broken terms of contracts like going beyond frequency caps or
>> delivering campaigns to wrongly targeted GEO codes.  Writing down things
>> like IP address, cookie, referring URL etc may not prevent sophisticated
>> log editing but they do raise the likelihood of getting caught by
>>auditors
>> (or clients with their own logs).  If all that is written down is:
>>
>> [time], [ad], [event]
>> 12:01:33, Ad ABC, Impression
>> 12:03:44, Ad ABC, Impression
>> 12:07:55, Ad ABC, Impression
>> Š
>>
>> There is not much to audit, not much to convince anyone that no one
>> "printed" events and not much to prove that all events were "quality" in
>> terms of what was contracted for.
>>
>>
>> -Brooks
>>

Received on Tuesday, 21 August 2012 19:34:00 UTC