- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Fri, 22 Mar 2013 17:36:23 +0000
- To: John Simpson <john@consumerwatchdog.org>
- CC: Ronan Heffernan <ronansan@gmail.com>, Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>, David Singer <singer@apple.com>, Justin Brookman <jbrookman@cdt.org>
- Message-ID: <DCCF036E573F0142BD90964789F720E314022D4D@GQ1-MB01-02.y.corp.yahoo.com>
Sorry if I missed that point - so "D" it is then. - Shane From: John Simpson [mailto:john@consumerwatchdog.org] Sent: Friday, March 22, 2013 10:26 AM To: Shane Wiley Cc: Ronan Heffernan; Rigo Wenning; public-tracking@w3.org; David Singer; Justin Brookman Subject: Re: TPE Handling Out-of-Band Consent (including ISSUE-152) I thought after discussion on the call "D" was to be sent, not "L" if a site was not listening, i.e., disregarding DNT On Mar 22, 2013, at 6:42 AM, Shane Wiley <wileys@yahoo-inc.com<mailto:wileys@yahoo-inc.com>> 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 [mailto:ronansan@gmail.com<http://gmail.com>] Sent: Friday, March 22, 2013 6:34 AM To: Rigo Wenning Cc: public-tracking@w3.org<mailto: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.
Received on Friday, 22 March 2013 17:37:29 UTC