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