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


Maybe DNT=1 dataflows should not be routed through realtime decision engines in the first place.


David Singer <> wrote:

>On Mar 19, 2013, at 6:30 , Ronan Heffernan <> 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 <>
>> 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