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

Yes, that seems to be the case.  I see no point in defining something which is involuntary on both ends (such as sending and receiving IP addresses), since there is nothing we can do or say about it.

I think the tightest definition of 'retention' I can think of is:

* a per-transaction record, which contains data that identifies or could be used to identify the user, is held AFTER the HTTP response is sent.

Note that this excludes both truly anonymous (e.g. indexed against a cookie which only the user-agent knows) and aggregated data (I served 23 curry sandwiches today!), and also excludes the brief period between request and response, in which the data in and associated with the request, may be held and used (like the IP address at the other end of the TCP connection :-))

On Jan 26, 2012, at 14:59 , Bryan Sullivan wrote:

> That makes sense to me. If collection is equivalent to reception, then
> beyond immediate request processing, all further focus should be upon
> retention of the data.
> 
> On 1/26/12 3:03 AM, "Shane Wiley" <wileys@yahoo-inc.com> wrote:
> 
>> Is it fair state that if "Collection" is defined in such a stringent
>> manner that there is no technically feasible manner for a web server to
>> NOT collect data (any request/response would at a minimum be "collected"
>> in memory - even if immediately purged) and therefore the conversation
>> shifts to "Retention" for the group at that point?
>> 
>> - Shane
>> 
>> -----Original Message-----
>> From: Jonathan Mayer [mailto:jmayer@stanford.edu]
>> Sent: Wednesday, January 25, 2012 7:28 PM
>> To: David Singer
>> Cc: public-tracking@w3.org (public-tracking@w3.org)
>> Subject: 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.
>>> 
>> 
>> 
>> 
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 26 January 2012 17:26:51 UTC