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