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

Re: Allowed uses of protocol data in first N weeks (ACTION-190)

From: イアンフェッティ <ifette@google.com>
Date: Sat, 5 May 2012 16:08:51 -0700
Message-ID: <CAF4kx8ejRjN3jL9oLRLaFvoa-ens2mPQDXaGp1yCHnBkCShLHA@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
On Sat, May 5, 2012 at 7:56 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Ian Fette wrote:
> >Protocol data, meaning data that is transmitted by a user agent, such as a
> >web browser, in the process of requesting content from a provider,
> >explicitly including items such as IP addresses, cookies, and request
> URIs,
> >MAY be stored for a period of 6 weeks in a form that might not otherwise
> >satisfy the requirements of this specification. For instance, the data may
> >not yet be reduced to the subset of information allowed to be retained for
> >permitted uses (such as fraud detection), and technical controls limiting
> >access to the data for permitted uses may not be in place on things like
> >raw logs data sitting on servers waiting for processing and aggregation
> >into a centralized logs storage service.
> The idea seems to be that requirements regarding data retention do not
> apply during a six week period (starting with collection, presumably).
> So whenever the specifciation says "retain" you want that to mean "re-
> tain past the six week period where retention requirements don't apply".
> If that is the intent, then I find your text very misleading, starting
> with the use of "MAY". I think this needs to be part of all the reten-
> tion requirements. For instance, instead of saying
The entire spec is already structured around having general principles and
exceptions to these principles (in the form of permitted uses and
user-granted exceptions). I really don't find this to be that different,
but I don't care. I was asked to draft text, I'm certainly open to
suggestions / changes / friendly amendments. I will say though that I don't
share your view of this being problematic from a 2119 perspective.

>  If this data is retained, there must be technical controls limiting...
> the specification would say
>  If this data is retained for a period longer than six weeks, then,
>  starting with the seventh week at the latest, there must be techni-
>  cal controls limiting ...
> That would avoid contradictory requirements that override each other.
> >Within this six week period, a data collector MUST NOT share data with
> >other parties in a manner that would be prohibited outside of the six week
> >period. Similarly, a data collector MUST NOT use the data to build any
> >profile, or associate the data to any profile, of a user used for purposes
> >other than would be allowed outside of the the six week period. As
> >examples, a data collector MAY use the raw data within a six week period
> to
> >debug their system, a data collector MAY use the raw data within the six
> >week period to build a profile of a user fraudulently or maliciously
> >accessing the system for purposes such as blocking access to the system by
> >that user, but the data collector MUST NOT build a profile to serve
> >targeted advertisements based on the user's past six weeks of browsing
> >activity.
> >
> >After the six week period has passed, only the subset of data necessary to
> >accomplish the permitted exceptions in this specification may be retained,
> >and the data must be controlled in such a way that only access to the data
> >for these permitted exceptions is allowed.
> This is all redundant and misleading as best as I can tell. If "MUST"
> and friends are supposed to be RFC 2119 keywords, you cannot use them
> to reflect on conformance requirements specified elsewhere, only to
> specify them, for instance. You seem to be including this only due to
> the earlier error of using "MAY" rather than clearly stating that the
> retention requirements do not apply during the six week period, and so
> you need to "un-override" "MAY"'s implications on usage and sharing.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Saturday, 5 May 2012 23:09:22 UTC

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