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

I'm saying there would be no control link.  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.

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.
>