- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Tue, 1 Oct 2013 14:54:05 +0100
- To: "'Dobbs, Brooks'" <Brooks.Dobbs@kbmg.com>, "'Vinay Goel'" <vigoel@adobe.com>, "'David Wainberg'" <dwainberg@appnexus.com>
- Cc: "'Rob Sherman'" <robsherman@fb.com>, <public-tracking@w3.org>, "Walter van Holst" <walter.van.holst@xs4all.nl>
- Message-ID: <1d4601cebead$b255cc30$17016490$@baycloud.com>
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
Attachments
- image/png attachment: image001.png
Received on Tuesday, 1 October 2013 13:54:46 UTC