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

I think there are 3 reasons for response headers:

* they are temporally proximate; associated with the request and possible tracking, or not, of it;
* they are contextual, and allow for precision as to which 'fork' of the policy this transaction is being viewed under (e.g. "you have given me permission")
* they are actionable by the user-agent in a way that the privacy policy is not (i.e. the UA can interact with the user and say "this page is loading content from a site that appears not to respond to DNT requests; what would you like to do?")

The alternative seems rather unpalatable to all concerned; the UA forms a list of all the 3rd parties involved on a page, and tries to work out, maybe with the user's assistance, using tracking protection lists, and so on, which ones to ignore.

I am not a fan of sending of a "please don't track me" into the void and having no idea which sites, if any, are at the moment tracking me.

If the policy is static (e.g. sites that do no tracking) it's trivial to add a DNT response to every transaction.  And no, I don't think the extra bytes are very much compared to typical web interactions; "DNT: 200" is vastly shorter than most URLs, for example.

I fear that going to the well-known location gets us back into P3P, or worse, only human-readable documents describing what's going on.  (And I use the phrase "human readable" rather loosely for most privacy policy documents :-().


On Oct 18, 2011, at 18:25 , Roy T. Fielding wrote:

> 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
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 19 October 2011 22:57:08 UTC