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

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.