- From: Justin Brookman <justin@cdt.org>
- Date: Mon, 18 Mar 2013 17:39:20 -0400
- To: public-tracking@w3.org
- Message-ID: <51478988.3070606@cdt.org>
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
> <mailto: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
> tel202.407.8812 <tel:202.407.8812>
> justin@cdt.org <mailto: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 <mailto: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
>>
>>
>>
>
>
Received on Monday, 18 March 2013 21:39:52 UTC