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

Re: action-190

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 30 May 2012 18:35:11 -0700
Message-Id: <644F3D0D-B7CE-4826-8455-CFFEA9E6D862@gbiv.com>
To: "W3C tracking protection wg" <public-tracking@w3.org>
My position on log files, in general, is that I am not aware of any
plans to remove, partition, or segregate entries based on the value
of a DNT header field.  I certainly have no intention of changing
our logfile retention policies based on DNT.

Access logs and error logs provide many functions, most of which are
focused on security and basic operations (keeping the servers alive
in the near future, or discovering what went wrong in the near past).
They need to be treated with the same care and regulations as telecom
companies maintain call logs.  I think they should only be kept as
long as necessary, where necessity may often be dependent on what
might have occurred on a given day, but I don't think that retention
period has anything to do with the user's preference --- it won't be
determined by this standard.  I think all of that falls under the
permitted use for security and fraud control.

Hence, I agree with Shane's comment.  There is no need for a specific
window on retention of logfiles because there is no requirement in
DNT that logfiles be purged.  There might be requirements on purging
data for all users, regardless of DNT setting, but that is outside
the scope of our standard.

There are (or at least should be) requirements that the DNT-enabled
logfile entries not be shared, correlated across sites, or otherwise
used in a manner that would be considered tracking.

There are not (or at least should not be) any requirements that the
DNT-enabled entries be excluded from non-identifying statistical
reports, such as aggregate demand over time or categorization by
context (information included within the protocol stream that isn't
specific to the user or device).

In other words, I don't believe the concern raised by Ian is
necessary for small, non-tracking operators to comply with the
protocol.  What is necessary is that we fix the definitions in
the compliance document so that they don't claim things that
we have no intention of implementing.

....Roy
Received on Thursday, 31 May 2012 01:35:40 UTC

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