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

Ronan,

The working group appeared to agree to use the "L" for not listening based on this week's call ("!" will be used to signal something different).  How about stick with "C" but name it "Conditional" with a resource link to explain what that means in your context?

- Shane

From: Ronan Heffernan [mailto:ronansan@gmail.com]
Sent: Friday, March 22, 2013 6:34 AM
To: Rigo Wenning
Cc: public-tracking@w3.org; David Singer; Justin Brookman
Subject: 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<mailto: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.