Re: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

Why do you think that it is OK that a user is tracked for one page?  If the
fact that you visited that one page gets shared with other sites, that can
create very obvious, very unwelcome, tracking behavior.  I think that
inter-site tracking is both more obvious and less welcome than intra-site
tracking, so allowing tracking on one page on every site severely limits the
usefulness and credibility of DNT.

That brings-up a wrinkle that I haven't seen discussed: in order to be
compliant with the DNT spec, no site should be allowed to do any tracking
for a hit to the well-known URI that indicates how the site is going to
honor your DNT request (even if the response is going to be: we are going to
track you anyway).

The well-known URI solution offers superior tracking prevention, as the user
agent can decide that the response from the well-known URI is incompatible
with the users' preferences, and abort the loading of the rest of the site.
However, that will really hurt performance since the fetch of the well-known
URI will have to happen before-and-not-in-parallel-with the fetching of any
other objects from a domain.  If the fetches happened in parallel, then the
fetching of some objects could trigger tracking behavior that the user (or
user agent) would reject, but it will have already happened by the time the
user agent examines the response from the well-known URI.  This places a new
round-trip to the well-known URI before any other requests (to each domain
with elements on a page), before the fetching of any other elements.

--Ronan Heffernan


On Wed, Oct 26, 2011 at 5:00 PM, Rigo Wenning <rigo@w3.org> wrote:

> Matthias,
>
> this makes it too complex (and complicated). I would really suggest we keep
> it
> very very simple by just having a header in the response saying whether the
> site honors DNT. This means the first interaction with the site, a user may
> set DNT=1 and still be tracked for one page. This is not really an issue.
> But
> it avoids going down the path of expanding beyond the HTTP request and
> running
> into the wild caching issues we had in P3P.
>
> Best,
>
> Rigo
>
> On Wednesday 26 October 2011 12:23:24 Matthias Schunter wrote:
> > Hi Karl,
> >
> >
> > thanks for your question.
> >
> > Two use cases as examples (one for headers and one for well-known uri):
> >
> >  A) A site (1st or 3rd party) accepts DNT and will follow
> >     the standards compliance document for all received DNT headers
> >
> > In this case, a well-known URI that says (machine-readable) "I accept
> > and follow DNT" for this site is sufficient.
> >
> >  B) A site accepts and follows DNT for requests to URIs at
> >        [site]/main/*
> >     but does not accept DNT for requests to URIs at
> >        [site]/beacons/*
> >
> > In this case, a well-known URI would not be easily able to provide the
> > right feedback. This may, e.g., be the case for sites that want to say
> > "if I am first party, I follow DNT" while also saying "for my beacons,
> > I do not".
> >
> >
> > Regards,
> >  matthias
> >
> > On 10/22/2011 12:05 AM, Karl Dubost wrote:
> > > Le 12 oct. 2011 � 18:03, Matthias Schunter a �crit :
> > >> In order to get there, I'd like you to give me
> > >>
> > >>  Use cases / scenarios where response headers are needed that
> > >>
> > >>    cannot easily be implemented with the well-known URI approach
> > >
> > > Could you clarify with a simple example?
>
>