W3C home > Mailing lists > Public > public-tracking@w3.org > March 2013

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

From: David Singer <singer@apple.com>
Date: Tue, 19 Mar 2013 12:22:48 -0700
Cc: public-tracking@w3.org
Message-id: <C5068430-E3BD-4D55-B736-0A6BD20CD6BC@apple.com>
To: Justin Brookman <jbrookman@cdt.org>

On Mar 19, 2013, at 5:59 , 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 think that it's possible the collection is happening e.g through a CDN, which doesn't easily know in real-time, , whereas the control link (which would probably not be often used) would go back to the sign-in site and know.  

That's the only way I can see it happening.  I am not even sure I like it.


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

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 19 March 2013 19:23:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:07 UTC