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

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

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Sat, 23 Mar 2013 15:17:30 -0000
To: "'Grimmelmann, James'" <James.Grimmelmann@nyls.edu>, <public-tracking@w3.org>
Message-ID: <03bc01ce27d9$8a008740$9e0195c0$@baycloud.com>
Hi James.

I think public decency is still intact but it might interfere with Occam's
razor. We already have a signal for tracking consent - DNT:0, and they
should just use it.


-----Original Message-----
From: Grimmelmann, James [mailto:James.Grimmelmann@nyls.edu] 
Sent: 23 March 2013 15:06
To: public-tracking@w3.org wg
Subject: Re: TPE Handling Out-of-Band Consent (including ISSUE-152)

A naive question:

Would it help if user-agents could send, with the initial request, a header
that contains a short list of explicit named out-of-band exceptions?  E.g,
DNT-OOB: NIELSEN.  The expectation would be that these exceptions would be
used for cases that involve (1) out-of-band consent, to (2) third-party
tracking across a wide variety of sites, by (3) a specific party, that (4)
has consent from a relatively small fraction of users, and that (5) is
difficult to confirm in real-time.  That is, since real-time lookup is hard
to do on the server side, perhaps it makes more sense to have user-agents
send a simple, unambiguous signal that is easy to implement.  The names
would be much easier, indeed trivial to check than figuring out whether a
specific user is in the panel who have consented.  The header is added to
every request, yes, but presumably by a relatively small number of users.
And user agents wouldn't need to have a more complicated real-time
interactive UI, since the preference to send an exception via this header
could be set-and-forget.  It also seems easier to investigate and audit than
other suggestions on the table.

In this model, Nielsen would be responsible for making sure that users in
the panel configure their user-agents to send this exception header; if they
don't, they can't be tracked.  Other unaffiliated servers would be
prohibited from relying on this exception.  It would be prohibited to set
such an exception header without explicit, specific user consent.  And there
would need to be some kind of namespace control to determine who gets to use
which tokens as named exceptions.

Much of this is far from ideal, but it seems like some approach along these
lines could provide users with immediate feedback on their tracking status
while enabling the desired form tracking by a party who has explicit
out-of-band consent against a general DNT:1 backdrop.

I am happy to have explained the multiple ways in which this suggestion
violates other core commitments of the protocol, fails to satisfy the
expressed tracking goal, is unimplementable by user-agents, will lead to
horrific privacy violations, and is otherwise contrary to common sense,
public order and decency, and the laws of physics.  But please be gentle.


James Grimmelmann              Professor of Law
New York Law School                 (212) 431-2864
185 West Broadway
New York, NY 10013    http://james.grimmelmann.net

On 2013-03-23, at 10:45 AM, Ronan Heffernan
<ronansan@gmail.com<mailto:ronansan@gmail.com>> wrote:

We also use JavaScript tags, not just pixel tags, though which one we use is
up to the publisher, not up to us.  Using JavaScript tags does not help us
with real-time OOBC determination; the limitations are server-side, and if
we could do real-time JS-tag lookup, we could do real-time pixel-tag lookup;
neither lookup is possible.

Any kind of interaction with the user will most likely not be allowed to
occur, since few publishers will want their user experience turned to crap
by having the user interact with either User Agent pop-ups or custom pages
from third parties.  Even if all of that were not an issue, using the
in-band exception mechanism would skew research horribly, and the balanced
and tuned panels constructed by our Measurement Science department would be
replaced by biased and un-measurable crowds.  None of those mechanisms or
outcomes are acceptable.

I don't understand why you think that non-real-time determination of OOBC
undermines the standard, as long as only permitted uses are followed.  How
is there "tracking" if users for whom there is no consent have their data
de-identified to the same level that is required for DNT:1 users, before any


On Sat, Mar 23, 2013 at 7:02 AM, Mike O'Neill
<michael.oneill@baycloud.com<mailto:michael.oneill@baycloud.com>> wrote:
It would be very easy to set up a page (that includes JS) with a document
origin the same as the 1x1 gif hostname., then execute the API to get
consent. A panel member just needs to visit the page and click a "I agree I
am a member of the panel" button. If they must run with JS disabled they
just need to set the DNT general pref. to 0.

We do not need to change the TPE for this and we are undermining the core
reason for the standard if we allow an exemption for it.

Received on Saturday, 23 March 2013 15:18:06 UTC

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