- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Wed, 25 Jun 2014 10:30:16 +0100
- To: "'Justin Brookman'" <jbrookman@cdt.org>, "'Shane M Wiley'" <wileys@yahoo-inc.com>
- Cc: <public-tracking@w3.org>
- Message-ID: <168301cf9058$156bc5a0$404350e0$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shane, I am with Justin on this pone, “implied consent” is hard to justify especially when the user in unaware that their agreement has been assumed and by whom. That is the reason for the “explicit” adjective, though “prior” works also. mike From: Justin Brookman [mailto:jbrookman@cdt.org] Sent: 24 June 2014 21:20 To: Shane M Wiley Cc: public-tracking@w3.org Mailing List Subject: Re: ISSUE-219 (context separation) Certainly, any party can get an exception to the DNT request, and signal back to the user a TSV of "C" indicating "A tracking status value of C means that the origin server believes it has received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol." I suspect arguing implicit consent would be challenging (!), but a first party could require that users consent to give an DNT exception as a condition of service (if legally allowed in a particular jurisdiction), or otherwise ask users if it's OK for the company to track or customize content/ads on other websites. On Jun 24, 2014, at 4:10 PM, Shane M Wiley <wileys@yahoo-inc.com> wrote: Wouldn’t many first parties be able to argue they have user consent (implied or explicit) to do this thus trumping this provision? If yes, then perhaps this isn’t an issue as 1st parties will still be able to use data collected in the 1st party context in a 3rd party context (use only; all collection is still covered by DNT). - - Shane From: Justin Brookman [mailto:jbrookman@cdt.org] Sent: Tuesday, June 24, 2014 1:05 PM To: Alan Chapell Cc: public-tracking@w3.org Subject: Re: ISSUE-219 (context separation) I think Walter's language is trying to accomplish what you want. When he says "the third party must not use data gathered in another context," I think "another context" logically includes all first-party when that party was previously a first party. Would you prefer to say: "the third party must not use data gathered in another context, including when it was a first party . . ."? Or something like that? You had previously proposed: "Use of this data outside the first party context is tracking and subject to third party rules for tracking, as outlined in Section 5." but I can't tell from the wiki where that sentence was supposed to go. Since I'm fairly sure you all are trying to accomplish the same thing, I really hope we can merge these options. On Jun 24, 2014, at 3:52 PM, Alan Chapell <achapell@chapellassociates.com> wrote: Hi Walter - This language doesn't seem to address a first party acting in a third party context. Was that by design? I strongly support re-inserting the language around first parties not being able to use data outside the Context in which it was collected. Alan On 6/24/14 3:29 PM, "Walter van Holst" <walter.van.holst@xs4all.nl> wrote: On 24/06/2014 17:57, Ninja Marnau wrote: Hi John, hi Mike, we wil probably start a Call for objections on the topic of context separation this wee. Could you take a look at Walter's proposal to see whether it does reflect your text for data append and first parties: "A Party MUST NOT use data gathered while a 1st Party when operating as a 3rd Party.² Here is the link to Walter's text: https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Limitations_on_use_i n_Third_Party_Context#Proposal_2:_Prohibit_use_of_data_collected_as_any_t ype_of_party Mike, John and I have had a fruitful discussion, which resulted in a more precise wording of what I wanted to achieve and I have updated the text accordingly to: "... the third party MUST NOT use data gathered in another context about the user, other than with their explicit consent or for permitted uses as defined within this recommendation." I feel this is a make-or-break issue for the compliance specification which on top of the privacy issue also has competition implications. A strong separation between 1st and 3rd party roles is a must for this compliance specification to be credible. Regards, Walter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/ Charset: utf-8 iQEcBAEBAgAGBQJTqpamAAoJEHMxUy4uXm2J+LoIAKaCJ3BV+ze2iBWCpZBYq5iS qYmkM8ZhPbANW18a0vQR3hDP0tsTjJg1l0eGGWU7EhWpEXe1USB8H9SiicrLmRhJ lbUgLovUk+SmbuUAEtlnTucLPeBVD5ZFl3mBeg2jcYY0svnCFbVovQjI2z6+vwQk beVP9iiYU+zH2H6vITtNJfIaKIsObmZO84XG9kO/7OJdgzma9nXb03ZjFwMDCtu9 qmE0Cz5IyWtQiDUs7cvhsN24SSB8PqOEHIgmV7Q6UU+ReB3eRGaczRtu5ZiycKBu lm5R5kVzmmDuqdgb+uU9zLI1n/aw/EJ8SXHHaeRJdBNgUlceQ7EMW3uAZdXKC4g= =AJ/y -----END PGP SIGNATURE-----
Attachments
- text/html attachment: PGPexch.htm
- application/octet-stream attachment: PGPexch.htm.sig
Received on Wednesday, 25 June 2014 09:30:52 UTC