W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

RE: Defining Collection (ISSUE-16)

From: Amy Colando (LCA) <acolando@microsoft.com>
Date: Wed, 7 Mar 2012 23:28:36 +0000
To: Kevin Smith <kevsmith@adobe.com>, Jonathan Mayer <jmayer@stanford.edu>
CC: Tracking Protection Working Group WG <public-tracking@w3.org>
Message-ID: <81152EDFE766CB4692EA39AECD2AA5B6130C568B@TK5EX14MBXC295.redmond.corp.microsoft.com>
A question - and possible correction  -- on this proposal, in connection with our approach to first parties.

Scenario: My uncle runs a small site called Silver Surfers in the UK.  He displays ads from Google on his site to help fund his pub trips (I have not been able to sell him on Microsoft Advertising yet).  Is he "sharing" data with Google when he enables the ad call to Google in order for Google to deliver an ad to his site?  Remember, we currently prohibit first parties from "sharing" data with third parties.  I don't think that we are requiring publishers to change their ad calls/redirects, but wanted to test this understanding with the group.  I think that the right result in this scenario is that as the first party, my uncle doesn't need to change anything about what he does on his site (other than not reselling data), but the ad network that receives a DNT signal upon redirect does need to take some action by delivering a non-targeted ad and not adding more data to an ad profile.

Does that sound roughly right?  If so, do we need another verb?

From: Kevin Smith [mailto:kevsmith@adobe.com]
Sent: Wednesday, March 07, 2012 3:01 PM
To: Jonathan Mayer
Cc: Tracking Protection Working Group WG
Subject: RE: Defining Collection (ISSUE-16)

My apologies.  I object, but not formally, to the term collection, and would recommend the following text for the compliance doc:

A party "receives" 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.
A party "shares" data if the party enables another party to collect[[receive?]] the data.

I feel this is more clear.  I think the fact that 'receives' is not common in the current privacy space is the reason it works better here.  Its meaning is obvious and it does not carry any other connotation.

From: Jonathan Mayer [mailto:jmayer@stanford.edu]<mailto:[mailto:jmayer@stanford.edu]>
Sent: Wednesday, March 07, 2012 3:54 PM
To: Kevin Smith
Cc: Tracking Protection Working Group WG
Subject: Re: Defining Collection (ISSUE-16)

FYI, the Formal Objection is a specific W3C procedure that is available after a decision.  See http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection.  It is a move that should not be considered lightly.

I've heard "receives" used before in this context, and I agree that it's closest in plain meaning to what we're discussing-but it's not particularly common terminology in the privacy space.  If the group prefers "receives," fine by me.  So long as we're all in substantive agreement.

Jonathan

On Mar 7, 2012, at 2:23 PM, Kevin Smith wrote:

The problem is that collection is such a common term in the industry and usually includes both your version of collection and retention.  Granted, I work in the analytics industry, but if you look back through other threads about 'collection' it is clear that I am not the only one for whom this has strong connotations that include retention.  Thus, using this term does not promote 'precision' but rather confusion.  So, I formally object to the text under review and again ask that you find a term with less historical context.

Some other suggestions:
* Transmission - this actually seems more accurate anyway since if I understand you right, you would like to prevent sending data.  If data is sent, you cannot prevent receiving the data, which is closer to the term collection.
* Acquires - again focuses on the process of getting rather than retaining, but I am not fond of this one
* Requests
* Receives - probably the most precise

Collection implies retention.  We simply cannot use that term and expect members of the industry not to be confused.



-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu]<mailto:[mailto:jmayer@stanford.edu]>
Sent: Wednesday, March 07, 2012 2:33 PM
To: Kevin Smith
Cc: Tracking Protection Working Group WG
Subject: Defining Collection (ISSUE-16)

(retitled for issue tracking)

Here's the PENDING REVIEW text in the compliance document:

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.
A party "shares" data if the party enables another party to collect the data.

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.


I think these definitions make a lot of sense in both plain meaning and analytical structure-they compel us to be precise with our exceptions.

If there's disagreement, I'm listening.

On Mar 7, 2012, at 10:17 AM, Kevin Smith wrote:

I have a request.  To me, 'collection' is synonymous to 'retention' and I automatically translate the 1st into the latter.  From a lot of responses over the last few months (not necessarily on this thread), I think many others have a hard time separating these two terms as well.  However, usually when Jonathon uses the term 'collection' he is not referring to 'retention', but rather the actual request that goes over the wire, and I quickly get confused.  Jonathon, any chance you can use a different word (transmission perhaps) to refer to the request?
Received on Wednesday, 7 March 2012 23:29:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:26 UTC