Re: when the Tk header is required

On Aug 27, 2012, at 3:08 AM, Nicholas Doty 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.

No, if the site responds "1" then there is no need for Tk headers.

WKL "1" or "3" doesn't mean *this* request is in a first or third-party
context -- it simply claims the minimum set of requirements in Compliance
adhered to for all resources on the site.  If one of those resources
would not adhere to that claim, then the response must either be
the "worst-case" of "3" (meaning all of my resources comply with the
requirements on third party tracking even though they might be used
in a first-party context) or "X" (meaning I determine compliance
dynamically based on the request and you'll have to check the headers).

Almost all sites would claim either "1" or "N" (if applicable)
for all of their resources.  "X" would be for complex sites like
maps.google.com or tracking sites that have different status object
fields per URI (e.g., different tracking policies per referring site).
"3" would be relatively rare (sites that are actually designed for
third-party contexts, perform whatever it is we define tracking to be,
and comply with our spec); such services tend to be on dedicated domains.

> I think the policy of "site-wide resource unless a Tk header is present which would override" would be more efficient for implementers.

It would also be useless for pre-flight checks. "1" or "3" without
a guarantee that it applies doesn't say anything more than "X".
Header fields are received after tracking occurs.

Only a very small part of the Web performs third party tracking.
Any solution that requires the entire Web to change, just to highlight
a small portion of requests for an even smaller set of user agents
that are actively verifying DNT compliance, would be an utter failure.
That's why the compliance status is relegated first to a separate
resource and then only elaborated in headers and request-specific
options if the complexity of the site demands it.

....Roy

Received on Monday, 27 August 2012 20:03:04 UTC