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

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