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

Re: [Issue-5] [Action-77] Defining Tunnel-Vision 'Do Not (Cross-Site) Track'

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 2 Feb 2012 19:16:44 -0800
Cc: David Singer <singer@apple.com>, John Simpson <john@consumerwatchdog.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <E162465B-C083-4349-903A-59FCC8C1215C@gbiv.com>
To: Lauren Gelman <gelman@blurryedge.com>
On Feb 2, 2012, at 4:24 PM, Lauren Gelman wrote:

> Can you limit the sites who would be required to keep it for audit purposes to only first parties or their service providers?

I don't think we can anticipate what sites are required to
keep data for auditing purposes, especially since many of
the third-party sites are auditors.  Why does it matter,
assuming they aren't allowed to share the data or use it
operationally (to target or modify responses)?

I think it is more effective to place limits on retention
in user-identifiable form, since auditors generally do not
want to retain the raw data anyway unless it has been detected
as likely fraudulent.  Another possibility is to only
allow pair-wise retention of referral data, meaning that any
user-identifiable data in the record is hashed with something
unique to the referring site, or stored separately per site,
such that it is difficult to correlate them.  And note that
this would only be for sites that *need* to retain this
information for billing/auditing/fraud control -- it is not
a general exception.

We are already limiting data collection to the site operator
and data processors contracted by that site, but "site" in
that case includes third-party services.  I am assuming that
companies like


are at least capable of siloing data per contract (destination site).
I do not know if they do so already.  I doubt that a first party
would ever willingly share referral data with anyone else, aside
from aggregate forms (like in marketing reports).

Received on Friday, 3 February 2012 03:17:09 UTC

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