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

On Mar 22, 2013, at 10:25 , John Simpson <> wrote:

> I thought after discussion on the call "D" was to be sent, not "L" if a site was not listening, i.e., disregarding DNT

D - I am disregarding your signals.

added to:

N - not tracking at all
1 - first party
3 - third party
C - prior consent

X - dynamic
U - updated

(It's beginning to sound like Maritime signal flags, which are letters that also have meanings, see <>.  Perhaps we need D "Keep clear of me; I am maneuvering with difficulty." in the working group :-) )

> On Mar 22, 2013, at 6:42 AM, Shane Wiley <> wrote:
>> 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 [] 
>> Sent: Friday, March 22, 2013 6:34 AM
>> To: Rigo Wenning
>> Cc:; 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 <> 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.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Saturday, 23 March 2013 21:04:15 UTC