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

Yes, we could detect that they were still someone for whom we had an OOBC
on-file.  I am suggesting that the spec should make it clear (perhaps
non-normatively?) that any attempt to use the in-band exception method to
withdraw an out-of-band consent may not have any effect.  This is a
legal/spec issue, more than a technical issue (though it is also a
technical issue since we won't be relying on the in-band exception
repository in the User Agent, so "withdrawing" in-band consent won't have
any mechanism to have an effect on the remote OOBC determination).

My concern about real-time OOBC determination is not a nefarious attempt to
increase "tracking".  It is the logical outcome of the limitations that I
have mentioned before, nothing more, nothing less.

For my concerns, limiting "L" to market research (with no OBA, no
targeting, no user-experience impact, etc.) is fine.  Just for general
clarity, are you suggesting that all OOBC would be limited to market
research, or that all non-real-time-determination-feedback OOBC would be
limited to market research?

--ronan


On Tue, Mar 26, 2013 at 5:36 PM, Justin Brookman <justin@cdt.org> wrote:

>
>    BTW, I am also suggesting that OOBC cannot always be withdrawn in-band.
>>  If a user signs a contract and gets paid to be a panelist, they need to
>> follow the legal steps to break their contract, including (possibly)
>> returning the money that they were paid.  I don't think that we should
>> expect an in-band exception-withdrawing mechanism to be able to withdraw a
>> consent that was granted out-of-band.
>>
>>  Is this your core concern with staying in-band?  That users will be able
> to less transparently avoid tracking by Nielsen after opting in?  I don't
> think anyone is suggesting that people should be able to break their
> Nielsen contracts by merely reconfiguring their exceptions.  If someone
> were to do that, wouldn't you be able to detect it, using whatever methods
> you use today to figure out when a panel member deletes their cookies or
> otherwise makes keeping state harder?  Wouldn't it be *easier* for you to
> track this, as you do have client-side software that could keep state on
> the user's browser exceptions?
>
> Again, I find this far preferable to a L signal.  If that were to be
> countenanced, we would need to be very clear that the availability of the L
> signal was cabined to market research (collection that doesn't change any
> individual's experience) and there were some automated way to get
> information later about whether consent was eventually found.  Not
> convinced that's possible but willing to consider.
>
>
>