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

Re: Sitecom adds Do Not Track to its routers

From: イアンフェッティ <ifette@google.com>
Date: Sat, 1 Dec 2012 11:13:09 -0800
Message-ID: <CAF4kx8chK95oxcwgjN=O5BxRqkoYLEvLbu0jTDKXthvxLpDJzg@mail.gmail.com>
To: Walter van Holst <walter.van.holst@xs4all.nl>
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Given that the majority of requests coming with DNT:1 to servers today are
from a user agent many parties have said sets a signal that does not align
with what you would call "good faith", and given that we see more and more
developments along these lines (AV software setting DNT, routers with
incomplete DNT implementations that don't provide for exceptions and make
no attempt to ensure things like the header and DOM property are
consistent), your assertion that servers should "assume that a DNT:1 signal
has been set in good faith" is a bit odd IMO.


On Sat, Dec 1, 2012 at 5:32 AM, Walter van Holst <walter.van.holst@xs4all.nl
> wrote:

> On 12/1/12 4:25 AM, Ian Fette (イアンフェッティ) wrote:
> > With respect to this or any other hardware device attempting to mitm
> > traffic, there seems to be no provision for how to handle exceptions.
> > Much less to ensure the header and dom property are consistent. That
> > seems quite problematic to me.
> Regardless of how problematic these issues are, it is not quite obvious
> to me how much relevance they bear towards this standard. We're talking
> about a change (to the HTTP-request) whose provenance will be hard to
> detect for servers.
> Since devices such as this typically operate between the endpoints of an
> HTTP session, the logical course of action would be to switch to HTTPS
> instead.
> It all comes back to the fundamentally trust-based approach we've taken.
> If we assume DNT only to be used by good actors on the server side, we
> likewise must assume that a DNT:1 signal has been set in good faith.
> Regards,
>  Walter
Received on Saturday, 1 December 2012 19:13:37 UTC

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