- From: Tom Lowenthal <tom@mozilla.com>
- Date: Wed, 19 Oct 2011 17:06:44 -0700
- To: public-tracking@w3.org
- Message-ID: <4E9F6614.90903@mozilla.com>
+1, completely. On 10/19/2011 03:56 PM, David Singer wrote: > 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 Thursday, 20 October 2011 00:07:31 UTC