Re: ACTION-415 Provide text proposal regarding limitations on using a Potential Consent signal

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 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 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 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 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.
>>> 
>> 
>