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

Hi David,


Thanks for this input. I see these goals once a user has set DNT:
 - Find out to what extent a request to [someURL] will be tracked
 - In a machine-readable (=actionable) way

I see two (main) alternatives to implementation:
 - Response headers with some machine-readable result code
 - Well-known URL for all sites with a machine-readable
   representation (this may actually also be a result code).

Since simplicity is one of our goals, I'd prefer the latter if it
achieves our goals:

Imagine a well-known URL http://[site]/dnt where a file with two lines
is stored:
 Tracking: [code] //* similar to the codes discussed for the headers
 MoreInfo: [URL]  //* Explanations, privacy policy, opt-in, ...

A user-agent can then check [firstparty]/dnt for information and may
also check [iframes/3rdparty]/dnt for this information. The point is
that this requires 1 request per site and not 2 lines per http request.

My question is:
 -  Why (= in what cases) does such a 'site-wide promise to
    follow DNT' via a well-known location not satisfy your/our needs?

Regards,
 matthias

The codes may be similar to the codes proposed by you:
> 100 = I understand DNT and respect it always
> 102 = I never track anyone anyway
> 
> 200 = I understand DNT and will not respect it.
> 201 = I understand DNT but I am exempted as a 1st party
> 202 = Will not respect because you have explicitly opted in to my tracking
> 203 = [more exemptions]


On 10/20/2011 12:56 AM, 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.
> 
> 
> 
> 
> 

-- 
Dr. Matthias Schunter, MBA
IBM Research - Zurich, Switzerland
Ph. +41 (44) 724-8329,  schunter(at)acm.org
PGP 989A A3ED 21A1 9EF2 B005 8374 BE0E E10D
VCard: http://www.schunter.org/schunter.vcf

Received on Wednesday, 26 October 2011 11:03:24 UTC