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

I had conversations about protocol information with a number of stakeholders this week. It seems that there might be a consensus for allowing some period of raw log retention and use. That said, there appear to be sizable differences on three specifics.  

1) What's included in protocol information? Does it include referrers? Cookies and cookie-like data?

2) What's the maximum retention period?

3) Which uses are permitted? I've heard proposals ranging from aggregation only to no fingerprinting to no profiling.

As for Ian's draft text, it seems to me a fine starting point, with the recognition that there is not a consensus on these details.  


On Saturday, May 5, 2012 at 7:56 AM, Bjoern Hoehrmann 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
>  
> 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/  
>  
>