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

Agree with the issues that David and Bryan have raised. Can you remind me what additional clarity we want to provide here? Im not convinced that these are helpful and appear to be adding to the complexity.

In addition, the intentional expansiveness and late date of these submissions has the effect of overriding many weeks of discussion on other portions of the spec. For example, under the current text, any first party that has a redirect on its site so that it can receive (untargeted) ads or content or even analytics for visitors to its site, would under the "share" definition be"sharing" with that third party ad or content or analytics provider -- and therefore be in noncompliance with DNT compliance spec.

Sent from my Windows Phone
________________________________
From: Bryan Sullivan
Sent: 1/26/2012 1:15 AM
To: Jonathan Mayer; David Singer
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Defining Collection/Retention/Use/Sharing (ACTION-64, ISSUE-16)

The fact that per these definitions there will be so many inherent
exceptions in order for requests to be processed (of which the first step
is reception, equivalent I believe in what Johathan terms "collection"),
is an example of one reason why I said that including detailed info in the
DNT response header (or doing the request/response info at HTTP layer at
all) will result in excessive overhead to disclose these inherent
exceptions.

Per the current TPE draft, only an "I comply with exceptions" flag could
ever be returned for DNT-compliant sites, with the additional info re "the
appropriate *explanation* describes all of these possible exceptions."

The only reasonable alternative (to avoid this inherent overhead) would be
to avoid requiring any info about exceptions from needing to be returned,
unless the exceptions are only contextually valid (not inherent, like
operational, legal, protocol-essential). Even in that case, because most
sites will include some degree of aggregate analytics collection (falling
under the "unidentified data" exception), its very likely that even that
exception would need to be disclosed, every time.

This is my reading per the TPE spec as it stands, apologies if I have
misunderstood something (please clarity if so, as I expect I'm not the
only one).

On 1/25/12 10:28 AM, "Jonathan Mayer" <jmayer@stanford.edu> wrote:

>
>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.
>>
>
>