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

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.