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

Hi Ronan,

I'm unclear as to why you can't periodically push the OOBC users to the
front-end servers, enabling a fast lookup. How many OOBC users do you
have? Can you discuss details of how the front-end server and logging
pipelines each work? We certainly don't want to ask something that's
impossible, but on the flip side, it is reasonable to expect some amount
of re-engineering to comply with DNT. To figure out which situation we
are in, providing more details would be necessary. I also agree with
others that using in-band mechanisms seems like a good solution.


On 03/24/2013 03:53 PM, Ronan Heffernan wrote:
> Mike,
> I'm sorry if I wasn't clear.  I was proposing that whatever level of
> de-identification, unlinkability, "munging", etc., that would apply to
> any other DNT:1 data would apply to this data (for those users for
> whom an out-of-band consent cannot be found) after the OOBC
> determination is made or as soon as the window (48-hours?) for making
> that determination expires, whichever comes first.  I do not intend
> for any other permitted retention or permitted use, from other
> provisions in the spec to be made any more or any less stringent by
> the non-real-time OOBC-detection mechanism.
> --ronan
> On Sat, Mar 23, 2013 at 11:42 AM, Mike O'Neill
> < <>> wrote:
>     Hi Ronan,
>     If you said that the collected data would be de-identified and
>     also made unlinkable i.e. the identifiers were transparently
>     deleted immediately after collection (or maybe after a short time
>     to filter out multiple visits and detect unique visitors), then
>     that would work in my opinion (if you cannot get explicit
>     consent). But the unlinkability is important because that goes to
>     the essence of Do Not Track.
>     Mike

Dan Auerbach
Staff Technologist
Electronic Frontier Foundation
415 436 9333 x134

Received on Monday, 25 March 2013 17:55:53 UTC