- From: Rob van Eijk <rob@blaeu.com>
- Date: Tue, 19 Mar 2013 20:35:51 +0100
- To: David Singer <singer@apple.com>, Ronan Heffernan <ronansan@gmail.com>
- CC: Justin Brookman <jbrookman@cdt.org>, public-tracking@w3.org
- Message-ID: <be9caba7-35c6-413c-9a72-edb149f50ad1@email.android.com>
Ronan, Maybe DNT=1 dataflows should not be routed through realtime decision engines in the first place. Rob David Singer <singer@apple.com> wrote: > >On Mar 19, 2013, at 6:30 , Ronan Heffernan <ronansan@gmail.com> wrote: > >> I'm saying there would be no control link. > >Stop there. "I might be tracking you, I might not, and there's no >(online) way for you to determine which, or stop it if I am." Really? > >> If you want to break your contract (and refund the money that you >were paid to participate), then you have to contact your customer >service representative and follow the process that is spelled-out in >your contract. > >And if this is in error? > >> >> The client-side software reports things like a participant's IP >address and cookies, say, once per hour or once per day. That >information is ingested in a separate system (likely not even via >HTTP). So the two streams of data do not meet until downstream of the >public-facing webservers. Only downstream can the system figure out if >a hit comes from someone who has consented. So the front-end >webservers do not have the information that they would need to >determine in real-time who has consented. Even if the systems are >tightly integrated, the servers might not find out for an hour or a day >(when the agent software finally reports in) which IP address+cookie >combinations are tied to someone who has consented. >> >> Even without those roadblocks, even if the information could be >supplied to all of the distributed webservers, we would need to take >systems that are already working to service billions of requests per >day in less that 20ms each and have them start comparing every incoming >hit against the frequently-changing information for hundreds of >thousands of OOBC participants, without violating SLAs. In my opinion >that is an unacceptable technical burden, especially when the need is >driven solely by a desire for real-time feedback, not to prevent >inappropriate "tracking". >> >> >> --ronan >> >> >> >> On Tue, Mar 19, 2013 at 8:59 AM, Justin Brookman <jbrookman@cdt.org> >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 also don't understand why the presence of client-side software >makes this more challenging. Presumably that would make it easier for >you to either operate in-band, or otherwise configure browsers to send >DNT:0 signals to your servers. I understand that's a different flavor >of out-of-band consent, but at least it's detectable. >> > >David Singer >Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 19 March 2013 19:36:42 UTC