W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

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

From: Tamir Israel <tisrael@cippic.ca>
Date: Tue, 21 Aug 2012 14:45:28 -0400
Message-ID: <5033D748.1010403@cippic.ca>
To: "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com>
CC: Shane Wiley <wileys@yahoo-inc.com>, Lee Tien <tien@eff.org>, Craig Spiezle <craigs@otalliance.org>, 'Chris Mejia' <chris.mejia@iab.net>, 'David Wainberg' <david@networkadvertising.org>, 'Jonathan Mayer' <jmayer@stanford.edu>, "public-tracking@w3.org" <public-tracking@w3.org>, 'Nicholas Doty' <npdoty@w3.org>
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 18:46:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC