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

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

From: Justin Brookman <justin@cdt.org>
Date: Fri, 22 Mar 2013 16:39:20 -0400
Message-ID: <514CC178.30005@cdt.org>
To: public-tracking@w3.org
On 3/22/2013 3:42 PM, Ronan Heffernan wrote:
> 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.
I just don't understand why these concerns hadn't been raised in the 
previous two years of discussions (it is possible they have and I was 
paying less attention to TPE, but if they were, they were resolved to 
the editors' and chairs' satisfaction).  The mandatory response signal 
has been in the TPE for some time now.  I would like to hear from others 
if feedback is effectively impossible for OOB. In which case, that's an 
argument that we need should get rid of OOB and require implementation 
of the exception mechanism by user agents (something I had previously 
been reluctant to do).
> 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.
I am thinking out loud trying to find a way past this impasse.  I do 
think that for DNT to work, you need to be able to figure out who thinks 
they have an exception to track.  I do not know that out-of-out-of-band 
consent is envisioned in the TPE, but conceptually, if you have a user's 
opt-in permission to override browser settings via your own software, 
there's nothing in the compliance standard that would or should stop you 
from doing that. And it would be discoverable by at least a 
sophisticated end user that he was sending out DNT:0 signals to Nielsen 
domains.  Not saying this is optimal, but it may be better than no 
visibility whatsoever into who asserts consent to track.  And less 
subject to abuse precisely because of this visibility.
>
> --ronan
>
>
> On Fri, Mar 22, 2013 at 3:29 PM, Justin Brookman <justin@cdt.org 
> <mailto:justin@cdt.org>> 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
>     tel202.407.8812  <tel:202.407.8812>
>     justin@cdt.org  <mailto:justin@cdt.org>
>     http://www.cdt.org
>     @JustinBrookman
>     @CenDemTech
>
>
Received on Friday, 22 March 2013 20:39:49 UTC

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