Re: when the Tk header is required

On Aug 27, 2012, at 0:08 , Nicholas Doty <npdoty@w3.org> wrote:

> On Aug 23, 2012, at 11:40 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> Begin forwarded message (with permission from Nick):
>> 
>> On Aug 18, 2012, at 6:07 PM, Nicholas Doty wrote:
>> 
>>> Hi Roy,
>>> 
>>> On reviewing the "Communicating a Tracking Status" section, I've come across an ambiguity, or perhaps a missing requirement. Namely, is it the case that if a request's tracking status differs from the site-wide tracking status then the response MUST include a Tk header that points to an alternative tracking status resource?
>>> 
>>> I think that's the intended outcome because otherwise the user agent could be misled about the tracking status of a resource because it had previously requested the site-wide tracking status and hadn't received a Tk header pointing it to a request-specific tracking status resource.
>> 
>> Hi Nick,
>> 
>> Thanks for the review.
>> 
>> I think the intention is that the site-wide tracking presents a
>> "worst case" answer for the entire site ("N", "1", "3", or "C"),
>> or "X" if the status is unspecified.  So, the WKL might say "3"
>> and then the header might have any of the above; if the WKL says "N",
>> then only "N" would be allowed for specific resources.
>> 
>> I agree that we need more text to define that.
> 
> If that's the intention, I agree we should clarify that in the spec. (We should also specify what the hierarchy of tracking up to "worst case" is.) 
> 
> Is that what we want, though? If a site has a single resource that is designed for and complies with the 1st-party tracking requirements, then the site-wide resource would have to list "1" and a "Tk" header would be needed on every response in a third-party context. That would seem to be an inefficient outcome for sites that mostly serve third-party resources but have a small site of their own for visitors to find out about their business and practices.
> 
> I think the policy of "site-wide resource unless a Tk header is present which would override" would be more efficient for implementers. Sites could then use the model of a site-wide tracking status resource being the default but any exceptions being documented in a request-specific resource or specific header. That was my understanding of the Google use case request, for example.


That makes sense.  

I also recall that the original motivation for the well-known resource was that replies of the kind "I respect your DNT:1 header" or "I currently behave to you as a 3rd party" were user-specific and hence not cachable.  However, many (most) of the responses are now of the form "I am designed to be used in a 1st party context", i.e. static statements of intent rather than user-specific statements of current state.

Given the concerns about caching, it seems it's worth asking whether it works better 'the other way up':  make general, cachable statements in the Tk header, and if that is missing (or, better, says "ask me"), then ask the UA to resort to the well-known resource (which can be a CGI) for personal/contextual answers.


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Monday, 27 August 2012 16:59:34 UTC