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

Responding to a DNT:1 signal with an acknowledgement that a company follows
DNT, and will abide by the restrictions (and permitted uses) therein, is
easy.  Responding with real-time lookups of whether OOBC exists is quite
difficult (in many cases impossible), especially for large-scale systems
that use CDNs and other distributed processing, and systems that do not
receive technical information required to perform OOBC lookups until after
some browsing has already happened.

If I understand the part of your proposal about the client-side software
overriding the user's DNT:1 with a DNT:0, I find that to be a troubling and
dangerous suggestion, far more open to abuse and less transparent to users
than non-real-time OOBC determination.


On Fri, Mar 22, 2013 at 3:29 PM, Justin Brookman <> wrote:

>  The 48 hours doesn't really matter if a consumer doesn't have visibility
> into the answer.  And anyway, in either case, you are seeking to hold and
> use the data for up to 53 weeks pursuant to the proposed market research
> exception.
> I still do not understand why you cannot operate in-band or otherwise
> configure the user agent to send DNT:0 signals using your client-side
> software.  I'm sure there are engineering costs and challenges to all
> parties represented in the working group, but I had not heard before that
> responding to DNT:1 and DNT:0 signals would be technologically unfeasible
> (which would seemingly be more so for third parties without client-side
> software).
> I also don't see how a conditional "C" signal helps.  Without definitive,
> machine-readable signals, it's hard to see how this system is accountable.
> There is currently no general auditing requirement in the standard, and I
> would be reluctant to put one in as an unnecessary burden and expense.
> Justin Brookman
> Director, Consumer Privacy
> Center for Democracy & Technology
> tel 202.407.8812justin@cdt.org
> @JustinBrookman
> @CenDemTech

Received on Friday, 22 March 2013 19:43:38 UTC