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

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.8812justin@cdt.orghttp://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
>>
>>
>>
>
>