- From: Nicholas Doty <npdoty@w3.org>
- Date: Mon, 27 Aug 2012 00:08:19 -0700
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
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. Thanks, Nick
Received on Monday, 27 August 2012 07:08:21 UTC