RE: New Change Proposal: New text for First Party Compliance (Issue-170)

David, Brooks

 

I am objecting to third-party sharing being added as there is no reason to
do so and it dilutes the standard. Permitted uses, if any, are discussed
elsewhere in the document. If there is a need to share unique ids for a
permitted use this should be covered by a service-provider relationship.

 

The loophole I had in mind is where a 1st party cookie (or localStorage
item) holds a unique id. Third-party cookie blocking in UAs and extensions
give people a way to stop cross-domain tracking so there are now several
examples where script is used to transmit the unique id cross-domain (using
postMessage or XHR). Adding language that appears to allow sharing like this
weakens our standard because we are trying to create a clear signal that
good actors will honour, and help remove the necessity for cookie or script
blocking which damages the web.

 

Mike

 

 

 

From: Dobbs, Brooks [mailto:Brooks.Dobbs@kbmg.com] 
Sent: 01 October 2013 14:06
To: Mike O'Neill; 'Vinay Goel'; 'David Wainberg'
Cc: 'Rob Sherman'; public-tracking@w3.org
Subject: Re: New Change Proposal: New text for First Party Compliance
(Issue-170)

 

Mike,

I think you are losing me here.  If the requirement is that third parties
must comply with any applicable requirements of the specification, where's
the gaping loophole?  I don't see this as okaying sharing carte blanche but
rather if you were allowed to have it as a 3rd party, you can have it; if
not - not.  What am I missing?

-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



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: Mike O'Neill <michael.oneill@baycloud.com>
Date: Tuesday, October 1, 2013 4:48 AM
To: 'Vinay Goel' <vigoel@adobe.com>, 'David Wainberg'
<dwainberg@appnexus.com>
Cc: Rob Sherman <robsherman@fb.com>, "public-tracking@w3.org"
<public-tracking@w3.org>
Subject: RE: New Change Proposal: New text for First Party Compliance
(Issue-170)
Resent-From: <public-tracking@w3.org>
Resent-Date: Tuesday, October 1, 2013 4:49 AM

 

Hi Vinay, David,

 

I  think any dilution of the 1st party sharing restriction weakens DNT.
Tracking techniques based on passing unique ids from 1st to 3rd parties are
becoming widespread, as an arms-race response to 3rd party cookie blocking.
Exempting sharing now between parties when DNT is set creates a gaping
loophole, and would make the standard useless in Europe. If data
processor/controller contracts are in place then OK, but this is covered by
the service-provider exemption. 

 

Mike

 

 

From: Vinay Goel [mailto:vigoel@adobe.com] 
Sent: 01 October 2013 02:46
To: David Wainberg
Cc: Rob Sherman; public-tracking@w3.org List
Subject: Re: New Change Proposal: New text for First Party Compliance
(Issue-170)

 

Hi David

 

Im okay with accepting the intent of what you're trying to capture, but I'm
not sure we need all of the new language you added. How about:

 

"If a first party receives a DNT:1 signal, the first party MAY collect,
retain, and use data in a manner consistent with any commitments the first
party makes to its users. A first party MAY share data about this network
interaction with its service providers and with third parties, provided that
any third parties that the first party shares data with must abide by any
applicable requirements of this specification."

This way, there is no obligation for the first party to 'pass' the signal;
but is inherent by saying the the third parties with who the first party
shares the data must comply with the applicable requirements. 

 

Would this new language cover what you were intending to amend?

 

Vinay

Sent from my phone


On Sep 30, 2013, at 4:49 PM, "David Wainberg" <dwainberg@appnexus.com>
wrote:

Vinay,

I'd offer a friendly amendment, as well. Your new text reverts from the old
version that prohibits first parties from sharing with "third parties who
could not collect the data themselves under this standard," but not from
sharing altogether. I understand there's a concern about giving 1st parties
a loophole to share data to be used in contradiction to the spec. However, I
think a total prohibition goes too far. If this were to be the language for
1st party compliance, I'd propose this edit:

"If a first party receives a DNT:1 signal, the first party MAY collect,
retain, and use data in a manner consistent with any commitments the first
party makes to its users. A first party MAY share data about this network
interaction with its service providers and with third parties, provided that
the first party MUST pass the DNT:1 signal with the data and that any third
parties receiving the data must abide by any applicable requirements of this
specification."

-David





On 2013-09-27 12:18 PM, Vinay Goel wrote:

Hi Rob,

 

Thanks for the thoughtful explanation and edits.  Yes, I'd accept your
suggested changes as edits to my proposed text.

 

-Vinay

 

From: Rob Sherman <robsherman@fb.com>
Date: Friday, September 27, 2013 12:12 PM
To: Vinay Goel <vigoel@adobe.com>, "public-tracking@w3.org List"
<public-tracking@w3.org>
Subject: Re: New Change Proposal: New text for First Party Compliance
(Issue-170)

 

Vinay,

 

Would you accept a friendly amendment to your text, as follows:

 

"If a first party receives a DNT:1 signal, the first party MAY collect,
retain, and use data in a manner consistent with any commitments the first
party makes to its users to both analyze usage and customize the content,
services, and advertising within the context of a first party experience.  A
first party MAY share data about this network interaction with its service
providers, but it MAY NOT share data about this network interaction with
third parties."

 

I am concerned about claiming to limit what a first party can do with data
collected when a user directly interacts with it, particularly given that
the specified uses here (analysis and customization) would exclude
activities that we've already agreed as a group are permissible even in the
third-party context.  For example, this text doesn't seem to anticipate use
of first-party data for security purposes.  More generally, though, it seems
inappropriate to have a list of permitted uses for first parties, given that
first-party services are going to vary quite substantially in how they will
need to use data, depending on what service they are providing.  My sense is
that it is more prudent here to simply say that the first party has to
comply with whatever commitments it makes and avoid circumventing DNT by
passing data to a non-service provider that couldn't collect it directly -
and I think this is consistent with the rationale you articulate below that
"the first party should be able to define/describe whatever it follows
within its Privacy Policy."

 

(Obviously, as with the rest of the standard, all of this would be subject
to consent.  As a result, for example, if you post a status update on
Facebook and share it with your friends, the prohibition on third-party
sharing  shouldn't prohibit Facebook from sharing that status update with
third-parties who are your friends, because we are doing this with your
consent.  But I don't think this point is controversial.)

 

I also had some feedback on one of your other change proposals but will
raise that separately in that thread.

 

Thanks.

 

Rob

 

Rob Sherman

Facebook | Manager, Privacy and Public Policy

1155 F Street, NW Suite 475 | Washington, DC 20004

office 202.370.5147 | mobile 202.257.3901

 

From: Vinay Goel <vigoel@adobe.com>
Date: Tuesday, September 24, 2013 10:55 AM
To: "public-tracking@w3.org List" <public-tracking@w3.org>
Subject: New Change Proposal: New text for First Party Compliance
(Issue-170)
Resent-From: <public-tracking@w3.org>
Resent-Date: Tuesday, September 24, 2013 10:56 AM

 

Current text: "If a first party receives a DNT:1 signal the first party may
engage in its normal collection and use of information. This includes the
ability to customize the content, services, and advertising in the context
of the first party experience.

The first party must not pass information about this network interaction to
third parties who could not collect the data themselves under this standard.
Information about the transaction may be passed on to service providers
acting on behalf of the first party

First parties may elect to follow third party practices."

 

Proposed new text: "If a first party receives a DNT:1 signal, the first
party MAY collect, retain, and use data to both analyze usage and customize
the content, services, and advertising within the context of a first party
experience.  A first party MAY share data about this network interaction
with its service providers, but it MAY NOT share data about this network
interaction with third parties."

 

Rationale: First off, we use the term 'data' within the definitions of
Collect, use, share, etc. but now switch to 'information'.  We should be
consistent within the document unless there is a reason for the switched
term (though if there is a reason, its unclear).  Second, what does 'normal
collection and use' mean?  What if that first party believes its normal use
is to sell/share the information with a data broker?  We need to set
parameters on what normal collection and use mean.  Because we need to set
parameters, we should use the defined terms collect, retain and use.  In
addition, the current text introduces the term 'pass' which is
undefined/unclear.  Instead, why not use the defined term of share?  Last,
the last sentence 'First partys MAY elect.' is completely unnecessary.
First Parties MAY also choose to elect SOME third party practices but not
all.  Do we need to state that as well?  Instead, the first party should be
able to define/describe whatever it follows within its Privacy Policy.

 

Draws upon: Issue-170

 

-Vinay

 

 

Received on Tuesday, 1 October 2013 13:54:46 UTC