W3C home > Mailing lists > Public > public-tracking@w3.org > December 2012

RE: RE: Request for comments on priorities for DNT

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Wed, 12 Dec 2012 15:46:11 -0000
To: "'Rigo Wenning'" <rigo@w3.org>, <public-tracking@w3.org>
Cc: "'Peter Swire'" <peter@peterswire.net>
Message-ID: <084201cdd87f$cf911350$6eb339f0$@baycloud.com>

I think you misunderstood my point, it probably needs clarifying.

As well as defining what we are trying to achieve in plain language we
should also define what specific technical things should NOT happen if a
user sets the signal (or is assumed to have in Europe), i.e. the use of
persistent identifiers,  fingerprinting or anything designed to collect
users' web history. There would be a requirement for servers not to do these
things, but also the user indication can guide "privacy enhanced"
user-agents to detect or inhibit them.

For instance future user-agents could hold persisted data - like cookies,
cached resources, ETag values , randomised (as per RFC4941) IPv6 addresses
etc. - in a database keyed to top-level domains rather than globally, and
this could be purged after a short interval if DNT=1 (Cached resources that
were identical across domains could still be held in global storage). This
would ensure that these identifiers were only scoped to top-level origins
and would be hard to link together, because of their short life. This
database would logically be the same as where UGE grants are stored.

The "control" for this capability should be with servers, as the exception
UI will be, because it is the web site's responsibility to protect privacy
and determine how they manage third-party content. If they obtain a user's
consent they can set up an exception for themselves and some of their
third-parties, but if not they may need to ensure that their third-parties
are also honouring the DNT=1 signal. Rather than have to re-engineer their
site to contingently remove elements it would be useful to have an API that
allows them easily to tell the user-agent to block them. If they have
contractual arrangements or trust them for some other reason, then they
would not need to use the (blocking) API. By blocking I mean at least
limiting the scope and duration of identifiers. User-agents should not be
required to enforce DNT, this should be orchestrated by first-party servers.

I have been working on more detailed description of an API spec that does
this, I hope to get it finished in the next few days.


-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: 11 December 2012 20:43
To: public-tracking@w3.org
Cc: Mike O'Neill; 'Peter Swire'
Subject: Re: RE: Request for comments on priorities for DNT


for the moment, this is set to "everything but permitted uses and the
necessary data collection that comes with it". Again, the DNT:0 definition
will give you meat of what specifically to avoid. 


On Wednesday 05 December 2012 15:18:59 Mike O'Neill wrote:
> We should agree on a set of specific things that servers should not do 
> if DNT is set. This is important so that there is a way to check for 
> compliance, either by the UA if users want that, or regulators.
Received on Wednesday, 12 December 2012 15:46:44 UTC

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