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

Hi Justin,


IMHO the point here is what "real-time" means in the different scenarios.

If we assume that finding the out of band consent is a non-trivial 
database query and takes -say- 3 seconds.

Then these 3 seconds can be spend during batch cleanup overnight 
(discarding all data where you were unable to ensure that you have out 
of band consent). It is also fine for a user to wait some seconds while 
seeing a hour-glass "please wait until we have retrieved our data" at 
the "control" web-page. However, waiting for 3 seconds before responding 
to an http request will make the site very unresponsive.

Does this answer your question?

btw: I did not understand either what role the client-side UA plays (if 
any).


Regards,
matthias




On 19/03/2013 13:59, Justin Brookman 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.
>
>     ------------------------------------------------------------------------
>     *From:* Ronan Heffernan [mailto:ronansan@gmail.com]
>     *To:* David Singer [mailto:singer@apple.com]
>     *Cc:* public-tracking@w3.org (public-tracking@w3.org)
>     [mailto:public-tracking@w3.org]
>     *Sent:* Tue, 19 Mar 2013 05:59:39 -0500
>     *Subject:* Re: TPE Handling Out-of-Band Consent (including ISSUE-152)
>
>     David,
>
>        That is pretty much what I was proposing, though we could
>     certainly add some protective language to make it clear that the
>     data cannot be used (except under other fraud and
>     technical-operation permitted uses) until the determination of
>     OOBC is made.  Regarding "delete all the data we don't have
>     consent for", some servers might delete the data, others might be
>     just de-identify it to the same extent that one would have to
>     perform for other non-consented data.
>
>     --ronan
>
>
>     On Mon, Mar 18, 2013 at 8:47 PM, David Singer <singer@apple.com
>     <mailto:singer@apple.com>> wrote:
>
>         I share Justin's concerns, but I also understand where Ronan
>         is coming from.  I am not sure I see what to do here, but
>         let's try.  Let me see if I can summarize...
>
>         What Matthias wrote: the site that thinks it has consent has
>         to tell the user, and offer a URI where the user can review
>         and possibly update that consent ('control').
>
>         What Ronan wrote: we collect all the data ('short term raw
>         data permitted use') and then delete all the data we don't
>         have consent for.
>
>         What Justin asks:  How does the user know where they stand (a
>         pretty basic need)?
>
>
>         I hate to suggest even more status/qualifiers, but do we need
>         one for 'possible consent'?  That would flag to the user that
>         they could check by visiting the 'control' link...
>
>