RE: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

Roy,

I like the simplicity of the known location approach (suggest we do this no matter what - need to think through DBCS/non-English URLs which are now supported) but question if it would allow automated testing/scanning for audit & enforcement purposes - as it appears this approach would require a manual review process. One of the goals in suggesting a header response was to provide a real-time check-point to the browser/app/user that their signal was received and honored (or not) -- this would be on a per user basis versus a DNT URI that would describe an organizations general support (or not) of DNT.  Could you explain the caching issues in more detail that plagued P3P?  I'm interested to understand if these are corner case situations or have broad (high %) implications.

Thank you,
Shane

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Thursday, October 27, 2011 3:17 PM
To: Rigo Wenning
Cc: public-tracking@w3.org; Matthias Schunter
Subject: Re: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

On Oct 26, 2011, at 2:00 PM, Rigo Wenning wrote:

> Matthias, 
> 
> this makes it too complex (and complicated). I would really suggest we keep it 
> very very simple by just having a header in the response saying whether the 
> site honors DNT. This means the first interaction with the site, a user may 
> set DNT=1 and still be tracked for one page. This is not really an issue. But 
> it avoids going down the path of expanding beyond the HTTP request and running 
> into the wild caching issues we had in P3P.

A well-known location is always simpler than a header field due to the
way that intermediary and browser security policies interfere (rightly so)
with the ability to process new header fields.  Header fields on all
responses are also a problem for shared-hosting sites that do not have
access to the half-dozen different ways that one can configure the
server to send a header field, and it is far easier to teach a content
owner how to place content at a well-known location than it is to teach
them how to configure the Apache server [personal experience].

In all respects, the well-known location solution is simpler,
particularly if (one of) the required format(s) is JSON and the
required content is no more than what we would have required for
the header.  Likewise, optional content (e.g., links to a tracking
policy, opt-in location, same-brand groupings, etc.) can only be
efficiently implemented by a well-known location.

....Roy

Received on Thursday, 27 October 2011 22:46:08 UTC