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

Rigo,

I agree that the risk would be on our side.  If we were to use data in
non-permitted ways, for users for whom we do not have consent, that would
make us a bad actor, risking whatever sanctions are applied to bad actors.
We would have to accept that risk, or abandon this method of research
(perhaps a decision made on a project-by-project basis).  Fortunately,
since we are routinely audited by the MRC and other bodies, the risk would
be low since any unacceptable practices would not be likely to escape
detection.

I do not agree that "C" is a good response, since it will not be accurate
for the majority of web users.  We can introduce another response flag that
specifically means that the determination of OOBC will be made later.
Since "L" is no longer being used for "not Listening", we could use "L" for
"Later", signaling to the users that we will figure out later whether or
not we have OOBC, and we will comply with the DNT spec accordingly and not
use their data in any non-permitted ways.

--ronan




On Fri, Mar 22, 2013 at 6:19 AM, Rigo Wenning <rigo@w3.org> wrote:

> David,
>
> what I see is the question who bears the risk of error. Ronan says: we
> activate our data-vacuum-cleaner and expect the browser not to interfere
> because 24 hours later we may be able to show out-of-band consent. If we
> are unable, we will de-identify in some way.
>
> This basically raises the question how one can opt-out of an unknown
> state. I think there are two ways depending on who takes the higher
> risk:
>
> 1/ Ronan's vacuum-cleaner makes sure they have the consent they need and
> indicate that by storing an exception and getting DNT:0 behavior. If
> they have stored exceptions where they had no consent, the watchdogs
> will go after them. Risk is on their side.
>
> 2/ The browser basically allows for all collection and tracking
> technologies even under DNT:1 and at some point someone may go to some
> URI to find out whether there was consent. Or perhaps not even that.
> Risk is on the user's side.
>
> I think in Ronan's scenario, they should signal "C" and take the risk of
> overstating while cleaning out their base ASAP. On the long run, they
> will have to think about how to handle DNT:1 users and whether they want
> to leverage the DNT signal for their system which would remove the
> uncertainty. Because they could determine at any moment in time whether
> they have consent or not. They could just look it up in the browser in
> real time via the API.
>
>  --Rigo
>
> On Tuesday 19 March 2013 12:22:48 David Singer wrote:
> > > Walk me through how this works in practice.  TrackerCo's servers are
> > > configured to send back a "possible consent" flag to everyone, and
> > > then TrackerCo figures out later how to differentiate among users
> > > who have consented and those who have not.  How would the "control"
> > > link be able to give the user information on request if TrackerCo
> > > is incapable in real time of figuring it out for itself?
> > I think that it's possible the collection is happening e.g through a
> > CDN, which doesn't easily know in real-time, , whereas the control
> > link (which would probably not be often used) would go back to the
> > sign-in site and know.
> >
> > That's the only way I can see it happening.  I am not even sure I like
> > it.
>
>
>
>