- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Sat, 15 Jun 2013 11:23:02 +0100
- To: "'Rob van Eijk'" <rob@blaeu.com>, "'Nicholas Doty'" <npdoty@w3.org>, "'Jonathan Mayer'" <jmayer@stanford.edu>
- Cc: "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>, <public-tracking@w3.org>
- Message-ID: <003601ce69b2$519c8370$f4d58a50$@baycloud.com>
Given the endless attempts we have seen in Europe to qualify the consent term (e.g. consent need not be “prior”, consent can be “implied” etc.), I think the chance that a “P” flag would be misused, i.e. used to avoid getting consent, is very high. I see no need for it because implementing a DNT exception should be easy, given a clear indication from a user. If it is not we should make it so. Mike From: Rob van Eijk [mailto:rob@blaeu.com] Sent: 15 June 2013 09:01 To: Nicholas Doty; Jonathan Mayer Cc: Matthias Schunter (Intel Corporation); public-tracking@w3.org Subject: Re: ACTION-415 Provide text proposal regarding limitations on using a Potential Consent signal I remain very reserved on the P-flag as well. No new text on audience measurement has been presented to the group yet. In addition to that, and maybe even more important, the restriction to audience measurement must be normative in my view. There is only little negotiation room here, and creating a generic P-flag for possibly other uses than audience measurement is beyond that space for me. Rob Nicholas Doty <npdoty@w3.org> wrote: Hi Jonathan, Just a couple quick follow-ups to make sure we're on the same page on this: 1) I thought after a series of conversations we had established the use case. In particular, on the April 24th teleconference: http://www.w3.org/2013/04/24-dnt-minutes#item04 ... and email threads: http://www.w3.org/mid/953B0F42-BF14-4BDA-817E-4A72E03B4223@cdt.org http://www.w3.org/mid/51784697.1070804@eff.org I think the use case is not the common situation (where out-of-band consent can be determined at the time of loading the tracking status resource), but would apply to those situations where consent is previously received (through an out-of-band contract, for example) but not determined until later. 2) Is your concern of abuse about extra retention/use of data? As Matthias has tried to outline below, the "P" flag would not give extra rights to collecting and analyzing data (it does not add a permitted use), it would just change the transparency requirements for those services that may have already obtained consent but do not currently know it. Personally, I think we could go forward with the "P" flag / transparency option in our drafts, note that it is only for use in the exceptional case where a service regularly obtains consent in a way that cannot be evaluated at the time, and then review during implementation whether it is made use of or whether it is abused (in the blocking transparency sense only, of course). I think this might be a feature we would mark "at risk" to note that we would need to see interoperable implementations before continuing with it. Thanks, Nick On Jun 12, 2013, at 4:32 PM, Jonathan Mayer <jmayer@stanford.edu> wrote: Just to remain clear from today's call, I'm not sold on the "P" flag. The technical need appears limited (especially if ID cookies aren't allowed for DNT: 1 and no consent), and the risk of abuse seems not insignificant. Jonathan On Wednesday, June 12, 2013 at 1:54 PM, Matthias Schunter (Intel Corporation) wrote: Hi Team, as expressed in the call, I would like to ensure that (a) The "P" flag only relaxes the requirements on transparency/notification. (b) The "P" flag does not give you any extra leeway/permisson to collect or track As a consequence, I suggest to split this text into two orthogonal pieces: (A) A "P" flag that allows delayed notification (without any additional permitted use) (B) A permitted use for keeping data for "48h" (or some other short-term retention). Text proposals for (A): Normative: "A tracking status value of P indicates that a site is following third party rules ("3"), except for users who have given prior consent. Unlike C, the origin server does not know, in real-time, whether it has received prior consent for tracking this user, user agent, or device. Since this status value does not itself indicate whether consent has been received for a specific user, an origin server that sends a P tracking status value must provide an <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#dfn-edit> edit member in the corresponding tracking status representation that links to a resource for obtaining consent status." Non-Normative: The P tracking status value is specifically meant to address audience survey systems for which determining consent at the time of a request is either impractical, due to legacy systems not being able to keep up with Web traffic, or potentially "gamed" by first party sites if they can determine which of their users have consented. The data cannot be used for the sake of personalization. If consent can be determined at the time of a request, the <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#dfn-c> C tracking status should be used. If an origin server subsequently determines that it does not have prior consent to track a user, the origin server may not then disregard the user's DNT:1 signal; rejections of DNT:1 signals must be made in real-time, using the tracking status value of D defined in 5.2.8. Text proposal for (B): (SOME FLAG) This permitted use allows third parties to temporarily keep data for 48h. After this time (unless consent has been obtained), the third party compliance rules must be satisfied. Opinions/Feedback? Matthias On 12/06/2013 17:02, Justin Brookman wrote: I propose to add the bolded sentence to 5.2.7 of the TPE on Potential Consent. 5.2.7 Potential Consent (P) A tracking status value of P means that the origin server does not know, in real-time, whether it has received prior consent for tracking this user, user agent, or device, but promises not to use or share any DNT:1 data until such consent has been determined, and further promises to delete or de-identify within forty-eight hours any DNT:1 data received for which such consent has not been received. Since this status value does not itself indicate whether a specific request is tracked, an origin server that sends a P tracking status value must provide an <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#dfn-edit> edit member in the corresponding tracking status representation that links to a resource for obtaining consent status. The P tracking status value is specifically meant to address audience survey systems for which determining consent at the time of a request is either impractical, due to legacy systems not being able to keep up with Web traffic, or potentially "gamed" by first party sites if they can determine which of their users have consented. The data cannot be used for the sake of personalization. If consent can be determined at the time of a request, the <http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#dfn-c> Ctracking status is preferred. If an origin server subsequently determines that it does not have prior consent to track a user, the origin server may not then disregard the user's DNT:1 signal; rejections of DNT:1 signals must be made in real-time, using the tracking status value of D defined in 5.2.8.
Received on Saturday, 15 June 2013 10:23:35 UTC