Re: [ISSUE-81, ACTION-13] Response Header Format

I think this thread is getting back to the confusion over what we
are trying to control in DNT.  A response of "I will not track you
cross-site" is not something a single resource can decide on its own.
The entire organization has to agree, including the folks who manage
the IP-layer routing, process the web server logfiles, pay the
bounties for referrals, etc.  Compliance is a policy issue for the
entire organization, not just the web application.

That's why I suggested that a well-known location would be just as
effective, far more expressive, and would remove the issue of caching.
It simply isn't the case that you can visit portions of a site
that says "we won't track you" and other portions of the site that
says "we have an exception for you" and still others that say
"we will track you regardless".  That makes sense for tracking as
a first-party clickstream. It does not make sense for cross-site
tracking, which is either being performed via the use of third-party
mechanisms (i.e., the responses to which will not be made by *this*
site) or by cross-site logfile correlation (something which could
be initiated long after the response was sent).

If we really need a response header field for the sake of eye candy,
then let's make it specific to resources that perform the actual
cross-site tracking -- the tracking pixels, XHR functions, and
other dynamic devices that might exist in the future for that purpose.
All other resources would have no response header field, and instead
rely on the well-known location for providing the tracking policy
that the entire brand obeys.

A browser that wants to operate in paranoid mode can retrieve and
cache the well-known location before it makes any other request to
the site, or can selectively retrieve only for those sites that
do not include a response header field, and we don't slow down the
99% of the Internet browsers that won't have that option selected.

....Roy

Received on Wednesday, 19 October 2011 01:26:26 UTC