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

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

From: Dobbs, Brooks <Brooks.Dobbs@kbmg.com>
Date: Mon, 30 Jul 2012 14:48:37 +0000
To: Tamir Israel <tisrael@cippic.ca>, Shane Wiley <wileys@yahoo-inc.com>
CC: 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>
Message-ID: <2B40EB3A3384EB4CB812241DDDC41D87017708@KBMEXMBXPR01.kbm1.loc>
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 Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com

This email ­ including attachments ­ may contain confidential information.
If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.

On 7/29/12 3:40 PM, "Tamir Israel" <tisrael@cippic.ca> wrote:

>I have not looked into SOX reporting in detail, but at bottom the
>reporting obligations and internal accountability mechanisms seem
>premised on the need to take reasonable steps to ensure accurate
>reporting of assets/transactions.
>So if, for example, you can use jonathan/arvind's algorithm to ensure
>that 5,000 advertisements were served and none violated a frequency cap,
>you should have your transaction record w/out need to resort to unique
>ID (assuming the algorithm can work).
>On 7/29/2012 1:02 PM, Shane Wiley wrote:
>> Tamir,
>> We use unique IDs for both the impression and the individual to
>>validate the transaction.  I believe this is where the physical world
>>and digital world diverge a bit.  The question is if the grocery store
>>collected a user's loyalty information to discount the price of the good
>>received, are they responsible for saving the loyalty card info with the
>>transaction to prove the discount was fairly and legally applied.  I
>>believe the answer is yes but haven't asked our Finance team that exact
>>question before.
>> - Shane
>> -----Original Message-----
>> From: Tamir Israel [mailto:tisrael@cippic.ca]
>> Sent: Sunday, July 29, 2012 9:58 AM
>> To: Shane Wiley
>> Cc: Lee Tien; Craig Spiezle; 'Chris Mejia'; 'David Wainberg'; 'Jonathan
>>Mayer'; 'Dobbs, Brooks';public-tracking@w3.org; 'Nicholas Doty'
>> Subject: Re: SOX Requirements RE: ACTION-216 - Financial Reporting
>> On 7/29/2012 12:22 PM, Shane Wiley wrote:
>>> (b) if so, does the retention requirement apply to the actual
>>>ad-serving transactional records that are generated by users'
>>>interactions with 3rd-party ad networks/companies?
>>> (Part of what I'm asking is what data/records the companies are
>>>currently retaining because of Sarb-Ox compliance -- and also, I think,
>>>the legal standard that defines the compliance line.)
>>> [Yes - as this is considered a "receipt" of the transaction as it's
>>>the billed element.  It's like asking if a grocery store must keep a
>>>record of each item purchased or if they can simply say a customer
>>>spent X in their store.  When ads are sold by impression - each
>>>impression must be retained to prove its validity and to be the actual
>>>record of receipt.]
>>> (c) if so, must the records contain user- or device-identifying
>>>information, or is that unnecessary?
>>> (Again, the legal standard may be ambiguous, but it would be helpful
>>>to know what that legal standard is....
>>> [Alteration of a legal record could be considered "evidence tampering"
>>>and therefore companies tend to stay on the conservative side of this
>> This is where you lose me. If, as Jonathan and others have suggested, it
>> is possible to confirm the # of transactions without unique IDs, why
>> would the SEC care if you are or are not collecting identifiers? To pick
>> up your grocery store example, no one forces Walmart to force customers
>> to present a drivers license as a condition of cash payments....
>> Best,
>> Tamir
Received on Monday, 30 July 2012 14:49:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:53 UTC