- 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