Re: possible 'transient un-analyzed data exception'?

Thanks Shane

at the moment, we kinda require 'immediate' compliance, and I am trying to recognize that lag between collection and data extraction/reduction here, and formalize it.

On Feb 22, 2012, at 17:42 , Shane Wiley wrote:

> David,
> 
> * require that the DNT status be kept with every record (i.e. under what DNT setting was it collected)
> [Agreed - or if records are separately contained or managed as a DNT data set this would achieve the same goal.]
> 
> * require that the raw data and all copies (if any) of it be erased after the extraction is run
> [Depends if that raw data is also used for other permitted operational purposes outside of "aggregate and anonymous" outcomes.  If not, then deletion or anonymization is reasonable.]

I mean, after you extract ALL the data you're allowed to extract (for whatever reason, exception, permission, or the like), the raw data that would enable other, non-permitted extractions has to be dealt with.  I didn't mean extraction for only the aggregated data exception. One of the 'extractions' might be a 'raw data reduction' that makes an acceptable reduced data-set of the raw data.

> * require that the extraction be done in a reasonable time (less than 8 days?)
> [As I've stated many times, it isn't appropriate to setup arbitrary timeframes as there are too many business models to possibly review to ensure the timeframe is appropriate.  Again, we should use a "minimization standard" here and force companies to defend why their raw data retention period is necessary for whatever the stated period.]

The trouble is, I would have hard time defending a spec. which called compliant "I am not building the records linked to your identity, but I retain indefinitely all the raw data that would enable that to be done". I think we all would.  "I am not keeping the key to your house, but I have an impression of it that enables a key to be made at any time".  Hm.  How do we deal with this?

> * that though the raw data contains data not permitted under DNT, the extracted data must comply (though exceptions may be claimed, as usual, alas)
> [I've not seen a prohibition on specific data elements within data collection yet - what are you envisioning here?]

I mean, there is a lag between raw data collection, and then extraction.  You can claim compliance as long as your data *after* extraction is compliant, even if the raw data contains information that is not.

> * recommend that copies/backups etc. not be made, as that merely makes it harder to ensure deletion has happened
> [For some areas this may be acceptable, but for financial records or legal compliance requirements, backups will definitely need to be made.]

If you need to retain the data, then that needs to be documented as a separate exception, not under 'transient raw data'.


> 
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: Wednesday, February 22, 2012 5:26 PM
> To: public-tracking@w3.org (public-tracking@w3.org)
> Subject: possible 'transient un-analyzed data exception'?
> 
> Do we need a "transient data" exception?  That basically, raw log data can be kept for a limited period before the 'legitimate' (permitted) long-term data is extracted, and the raw data then discarded?
> 
> I would envisage such an exception would:
> 
> * require that the DNT status be kept with every record (i.e. under what DNT setting was it collected)
> * require that the raw data and all copies (if any) of it be erased after the extraction is run
> * require that the extraction be done in a reasonable time (less than 8 days?)
> * that though the raw data contains data not permitted under DNT, the extracted data must comply (though exceptions may be claimed, as usual, alas)
> * recommend that copies/backups etc. not be made, as that merely makes it harder to ensure deletion has happened
> 
> 
> On Feb 9, 2012, at 13:12 , Shane Wiley wrote:
> 
>> David,
>> 
>> You hit the core issue straight away - raw data retention and dissemination to service operational purpose exceptions.  While the end-points I described below do result in aggregate and anonymous outcomes, we need to retain the raw data to build those results (different intervals: real-time, daily, weekly, monthly, quarterly, annual).  In some cases we compound aggregation (build annual aggregations from quarterly aggregations) where we can without compromising the data but there are reporting uses where the raw data is retained for a more accurate result (financial reporting, for example).
>> 
>> - Shane
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 23 February 2012 02:20:48 UTC