Re: Defining Collection/Retention/Use/Sharing (ACTION-64, ISSUE-16)

On Jan 25, 2012, at 6:28 PM, David Singer wrote:

> I'm not sure I get it.  
> 
> For example, do I 'collect' the IP address of the user, while the transaction is in process?  Does 'collect' apply to any information that is the server is exposed to?

Yes.

> I would have thought that some extra action is needed before it becomes 'collection'.

Not by this definition.

> I think we need to say that the data concerned are 'per-transaction records that contain data that is indexed against a specific user, or an identifier that could be used to identify a specific user'.  That way, transaction logs that are not indexed by IP address (you'd have to troll the log to extract the entries for a given IP) are not in scope, nor are any aggregate counts.

We'll talk about protocol data and unidentifiable data in the context of exceptions.  I don't see any reason to make our treatment of them implicit.

> I wonder if retention is 'keeping information from or about the transaction, after sending the response', i.e. the persistence after the immediate requested transaction.
> 
> 
> On Jan 25, 2012, at 10:54 , Jonathan Mayer wrote:
> 
>> Operative text:
>> A party "collects" data if the data comes within its control.
>> A party "retains" data if data remains within a party's control.
>> A party "uses" data if the party processes the data for any purpose other than storage.
> …storage?  any other purpose than responding to the inbound request?
> 
>> A party "shares" data if the party enables another party to collect the data.
>> 
>> Non-normative text:
>> The definitions of collection, retention, use, and sharing are drafted expansively so as to comprehensively cover a party's user information practices.  These definitions do not require a party's intent; a party may inadvertently collect, retain, use, or share data.  The definition of collection includes information that a party did not cause to be transmitted, such as protocol headers.
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
>

Received on Wednesday, 25 January 2012 18:29:11 UTC