W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

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

From: Justin Brookman <justin@cdt.org>
Date: Mon, 18 Mar 2013 17:39:20 -0400
Message-ID: <51478988.3070606@cdt.org>
To: public-tracking@w3.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

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC