Re: TPE Handling Out-of-Band Consent (including ISSUE-152)

I share Justin's concerns, but I also understand where Ronan is coming from.  I am not sure I see what to do here, but let's try.  Let me see if I can summarize...

What Matthias wrote: the site that thinks it has consent has to tell the user, and offer a URI where the user can review and possibly update that consent ('control').

What Ronan wrote: we collect all the data ('short term raw data permitted use') and then delete all the data we don't have consent for.

What Justin asks:  How does the user know where they stand (a pretty basic need)?


I hate to suggest even more status/qualifiers, but do we need one for 'possible consent'?  That would flag to the user that they could check by visiting the 'control' link...


On Mar 18, 2013, at 14:39 , Justin Brookman <justin@cdt.org> wrote:

> How could a user or user agent audit out of band permissions using that model?  How could a user ever withdraw consent?
> 
> This is not a good actor/bad actor problem.  A convinces-themselves-they're-good-but-actually-a-teensy-bit-devious actor could get "consent" using a bad user flow, and there would be no way for a user or anyone else to hold them accountable for that without feedback.
> 
> I was not aware this discussion was actually an open issue --- I thought it had been settled a long time ago.  ISSUE-152 is merely about whether we need to mandate that the user agents have a UI that allows users to see and intermediate out of band consent assertions.
> 
> Justin Brookman
> Director, Consumer Privacy
> Center for Democracy & Technology
> tel 202.407.8812
> justin@cdt.org
> http://www.cdt.org
> @JustinBrookman
> @CenDemTech
> On 3/18/2013 2:15 PM, Ronan Heffernan wrote:
>> I propose that the server be able to respond that it will comply with the DNT standard and behave appropriately.  The eventual discovery as to whether or not there is an out-of-band consent on-file will then dictate the server's permitted retention and use of the data. Only a bad actor who is willing to lie to the user will indicate compliance and then store or use the data in ways that are not permitted.
>> 
>> Out-of-band systems may well communicate the fact that there is an out-of-band consent during a later communication with the server applications.  Attempting to force real-time disclosure of OOBC is not fully out-of-band; it is an attempt to force some of the consent detection and disclosure in-to-band. 
>> 
>> --ronan 
>> 
>> 
>> 
>> On Mon, Mar 18, 2013 at 1:33 PM, Justin Brookman <justin@cdt.org> wrote:
>> Can you propose an alternative?  Real-time indication of consent has always been a sine qua non of the out-of-band consent framework.  A user (or user agent on her behalf) needs some sort of actionable information about which companies claim permission to track; otherwise, there isn't any accountability for companies or control for users around alleged OOB permissions.  What are you proposing instead?  Solely server-side management of permissions with no visibility to the user is going to be a tough sell, but perhaps there is another option.
>> Justin Brookman
>> Director, Consumer Privacy
>> Center for Democracy & Technology
>> tel 202.407.8812
>> justin@cdt.org
>> http://www.cdt.org
>> @JustinBrookman
>> @CenDemTech
>> On 3/18/2013 1:16 PM, Ronan Heffernan wrote:
>>> Matthias,
>>> 
>>> We discussed real-time feedback of out-of-band consent, and that is not going to work in many applications.  To move the determination of OOBC into the real-time interaction with the User Agents would take a prohibitive amount of time with large panels and widely-distributed server infrastructure.  In some cases that relevant information has not even been collected from panel members to make the determination until some hours after the interaction.
>>> 
>>> --ronan
>>> 
>>> 
>>> 
>>> On Mon, Mar 18, 2013 at 10:49 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>>> Hi Team,
>>> 
>>> 
>>> my summary of our discussion at the face2face on "Out of Band Consent".
>>> 
>>> Loosely speaking, out of band consent is 
>>> - a state where a site believes that it has sufficient permissions that allow
>>>   it to track a user even if a user has sent a DNT;1 preference
>>> - this belief is caused by mechanisms that are not part of this spec
>>>   (e.g., obtaining a preference via the exception API is not considered out of band).
>>> 
>>> The current TPE spec handles out of band consent as follows:
>>> - The spec does not say how a site may or may not obtain out of band consent
>>> - The spec requires that a site who wants to act on out of band consent
>>>   sends a signal "C" that is defined in the TPE spec as follows:
>>>   "Consent: The designated resource 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."
>>> - The spec allows a site to publish an URL "control" via its well-known resource where a user is permitted to manage consent.
>>> - The user agents are free to use this information ("C" signal and URL) as they deem most appropriate for their user group.
>>>   We do not mandate specific UA behavior.
>>> 
>>> My impression from our discussion in the room was that everyone is OK with this approach. 
>>> I will re-confirm this using an "OK to close" email in order to move us towards closing ISSUE-152.
>>> 
>>> Feel free to provide feedback or corrections in case I overlooked anything.
>>> 
>>> 
>>> Regards,
>>> matthias
>>> 
>>> 
>>> 
>> 
>> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.