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

Re: Proposed Text for Local Law and Public Purpose

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 26 Oct 2012 12:15:49 -0700
Cc: <public-tracking@w3.org>
Message-Id: <F1CAC2F4-99E0-4786-998B-7EA2ED2E3C48@gbiv.com>
To: Walter van Holst <walter.van.holst@xs4all.nl>
On Oct 25, 2012, at 8:53 AM, Walter van Holst wrote:
> On 2012-10-25 16:54, Dobbs, Brooks wrote:
>> They are attempting to reliably indicate that some counting of ads was
>> actually consumed or displayed to or made available to (insert term
>> here) to "quality" recipients. Now, to your linkability question 
>> yes "quality" probably is an indication that they are a "real" person.
>> So MRC or any audit company doesn't need an identified list of
>> individuals who saw the million ads, but in many ways what they are
>> saying is that these e.g. million impressions have enough linkability
>> to them that I can assure you that they aren't "low quality" i.e. not
>> a person. Without direct knowledge of MRC's secret sauce, I am sure
>> that IP address plays a role in this as a primary source and that IP
>> is very likely still used even where the cookie reads Opt_Out. I would
> 
> A cryptographic hash of the IP-address, UA string, the first 7 bytes of a 64 bit Unix timestamp salted with the date string would suffice to provide a pretty hard to link identifier that would meet the needs as you just described.

I seriously doubt that an identifier that changes at least every
4.27 minutes, and also at 00:00 UTC, would be useful to
anyone. Moreover, it doesn't take IP masking into account
(grouping identifiers by allocation block).

I know Walter wasn't here the last time around, so I'll say this
again:  DNT will have no effect on data collection or retention
for the purpose of detecting or preventing malicious activity.
Performing that function in the real world requires both the
collection of IP addresses and the setting of various types of
cookies, including identifier cookies, though not necessarily
retaining those cookies on the server.  AFAICT, this is allowed
by EU laws because they are necessary to secure any online
service from existing attacks.

Some attacks are detected and prevented (if possible) in real
time -- mostly denial of service or repeated credit card use.
Most attacks, particularly those involving clickjacking
or impression fraud, are not detected in real time, but rather
discovered after the fact and then addressed by removing those
entries from the billable counts.  One of the things that an
audit will perform is an assessment of whether the counting
service is adequately detecting and accounting for those attacks.
This has nothing to do with OBA -- the attacks are on any form
of advertising based on impression or clickthrough counts.

So, when folks here claim that "an audit company doesn't need X",
where X has anything to do with cookies or IP addresses, please
understand that it isn't going to work out that way.  Yes,
these processes have heightened privacy concerns and should be
subject to all sorts of regulations surrounding disclosure and
proper use, but they are not subject to DNT as long as the
usage is limited to the permitted use and retention is limited
to what is necessary for that use.  This is not a matter that
can be subject to user preference.

IIRC, the only reason MRC came up is because they have a one year
retention policy for source data used in an audit.  That kind
of requirement is normally satisfied by off-line storage of the
audited source material.  We are neither qualified nor responsible
for deciding whether such retention is necessary -- regulators
are -- nor are we responsible for MRC adapting its future
policies to the presence of DNT.  The W3C is not a forum for
establishing or enforcing regulations.

There is no need to mention it in our specs, and no need for
the specs to include anything about local laws and public purpose.
These are simply not our concerns and we have wasted far too much
of our time on them already.

....Roy
Received on Friday, 26 October 2012 19:16:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:37 UTC