- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Wed, 22 Feb 2012 17:42:40 -0800
- To: David Singer <singer@apple.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
David, While some of these are logically reasonable they do not map to real-world data processes. Have you engaged with anyone on the Apple iAd team to get their thoughts here? * 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.] * 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.] * 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?] * 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.] -----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.
Received on Thursday, 23 February 2012 01:43:29 UTC