W3C home > Mailing lists > Public > public-tracking@w3.org > November 2013

RE: Consolidated Proposal for Definition of Collect

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Fri, 1 Nov 2013 16:47:30 +0000
To: David Wainberg <dwainberg@appnexus.com>, Vinay Goel <vigoel@adobe.com>, "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com>, Walter van Holst <walter.van.holst@xs4all.nl>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C3510E38B16@WABOTH9MSGUSR8D.ITServices.sbc.com>
I agree, I don't see any value in defining a role of "facilitator". This is such a broad concept that even the user is a "facilitator", by the choice they may in sites they visit and the relationships they have established, in many if not most cases transparently to a 1st party (e.g. SocNet accounts which may be associated with linked/embedded widgets). Further it could lead to arguments that the simple act of providing a link to another site, without any action taken until the user selects the link, is a form of "facilitation". This is a rabbit hole we don't need to go down.

Thanks,
Bryan Sullivan

From: David Wainberg [mailto:dwainberg@appnexus.com]
Sent: Friday, November 01, 2013 9:33 AM
To: Vinay Goel; Dobbs, Brooks; Walter van Holst; public-tracking@w3.org
Subject: Re: Consolidated Proposal for Definition of Collect

Hi all,

I'm coming late to this party, but I don't why we'd define facilitator. What's the intended obligation of a facilitator? And why is this needed for the current path forward? Even if we include a definition of tracking, none of the proposals include facilitation.

-David
On 2013-11-01 12:20 PM, Vinay Goel wrote:
Hi Brooks,

How about this?

A party facilitates any other party's collection of data if it enables such party to collect data and engage in tracking.

I believe this language covers the your use case of 'facilitate others to engage...' because the original party still enabled this to occur by working with that party which enabled others.  I also think I kept your concept of 'leading to tracking' but simp lied the language.

Does this better capture what you were going after?

-Vinay

From: <Dobbs>, Brooks <Brooks.Dobbs@kbmg.com<mailto:Brooks.Dobbs@kbmg.com>>
Date: Friday, November 1, 2013 at 11:09 AM
To: Vinay Goel <vigoel@adobe.com<mailto:vigoel@adobe.com>>, Walter van Holst <walter.van.holst@xs4all.nl<mailto:walter.van.holst@xs4all.nl>>, "public-tracking@w3.org<mailto:public-tracking@w3.org>" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: Consolidated Proposal for Definition of Collect

So Vinay great start!

But where I may be stuck is "facilitate".  Does the creation of a new network connection within an interaction necessarily facilitate tracking?  If I redirect to a social media icon, and unbeknownst to me the consumer has provided permission to the icon provider to "track" them across the web, then arguably the social media provider isn't really tracking, so I haven't facilitated tracking.  Or alternatively, have I facilitated technical tracking, but the tracking is permitted owing to exceptions which I'd further need to port from the compliance doc?

I suppose another alternative would be:
A party facilitates collection by another party where it enables such party to collect data itself, and where such party may either engage in tracking or facilitate others to engage in collection leading to tracking.  <just created this>



--

Brooks Dobbs, CIPP | Chief Privacy Officer |KBM Group | Part of the Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com

[cid:2D83F7CF-CB92-475D-9790-51132720D91D]

This email - including attachments - may contain confidential information. If you are not the intended recipient,
 do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message.

From: Vinay Goel <vigoel@adobe.com<mailto:vigoel@adobe.com>>
Date: Friday, November 1, 2013 10:38 AM
To: Brooks Dobbs <brooks.dobbs@kbmg.com<mailto:brooks.dobbs@kbmg.com>>, Walter van Holst <walter.van.holst@xs4all.nl<mailto:walter.van.holst@xs4all.nl>>, "public-tracking@w3.org<mailto:public-tracking@w3.org>" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: Consolidated Proposal for Definition of Collect

Hi all,

I think more of us are converging on the idea that share is the wrong work for facilitate/induce.  To start the ball rolling, how do these definitions look:

  *   A party collects data received in a network interaction if it retains that data after the network interaction is complete.  <from Roy's suggested tweaks to the compromise change proposal, but removed the sharing aspect>
  *   A party retains data if the data remains within the party's control after the network interaction during which it was collected is complete. <from Lee's change proposal>
  *   A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.  <from editor's draft>
  *   A party shares data if it transfers or provides a copy of data that it has collected to any other party.  <from Amy's change proposal; takes out the facilitating aspect>
  *   A party facilitates tracking within a network interaction if it enables any other party to collect data itself.  <just created this>
Thoughts?

-Vinay


On 11/1/13, 10:26 AM, "Dobbs, Brooks" <Brooks.Dobbs@kbmg.com<mailto:Brooks.Dobbs@kbmg.com>> wrote:

Walter,

I agree these are compliance issues but they seem to now be tied to
definitions we've moved to the new 3.5, "TePliance" doc.

To be clear, I am not trying to completely remove a first party's
responsibility for what they induce, facilitate or whatever the word, but
"share" (and relatedly collect) are the wrong words!  You could have a
hypothetical site which has no forms and all logging turned off and no 3rd
party service providers (in my mind zero collection) meet a definition of
collecting simply by including social media icons.

We may or may not have strong agreement on facilitator responsibilities,
but I do hear a common refrain that we must bring more definitions into a
TPE if that TPE is meant to apply to a single compliance doc.  IMHO for
either a poll 3 or 4 approach to work the TPE must be written in such a
way that it can stand on its own.  Right now it appears we are struggling
with the 2 potential ways of achieving this:
1) piecemeal moving a compliance doc into the TPE, TePliance - which in
fairness is NOT option 3.5 but rather a renamed option 1, or
2) writing the TPE in a way that it doesn't assume anything from the
compliance doc but is written generally to allow for multiple compliance
standards, including one which may come from this group.



-Brooks


--

Brooks Dobbs, CIPP | Chief Privacy Officer | KBM Group | Part of the
Wunderman Network
(Tel) 678 580 2683 | (Mob) 678 492 1662 | kbmg.com
brooks.dobbs@kbmg.com<mailto:brooks.dobbs@kbmg.com>



This email  including attachments  may contain confidential information.
If you are not the intended recipient,
do not copy, distribute or act on it. Instead, notify the sender
immediately and delete the message.



On 11/1/13 6:09 AM, "Walter van Holst" <walter.van.holst@xs4all.nl<mailto:walter.van.holst@xs4all.nl>> wrote:

On 01/11/2013 11:02, David Singer wrote:
OK, maybe a concrete question.  If I (a first party) write a page
that pulls in a third-party resource, this causes clients who visit
my page also to contact that third party.  Lee is saying that that
constitutes "sharing" by the first party, even though the transaction
from client to third party never came actually "through" the first
party.  It's sort of an inducement, or the like.
Do we need to define this?  Is it really 'share', and an inducement
to share?  Anyway, the first party will not re-write pages for DNT
users, I doubt.

It reeks more of induced collection than of sharing. For all intents and
purposes, the third party does not receive the data through the first
party, but directly from the UA.

It is more a matter for a compliance spec to attach consequences to this
than for the TPE.

Regards,

Walter
Received on Friday, 1 November 2013 16:48:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:20 UTC