W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

Re: when the Tk header is required

From: Nicholas Doty <npdoty@w3.org>
Date: Mon, 27 Aug 2012 17:58:20 -0700
Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <AA2EF66E-09DC-469E-A4DD-CAB5AC60AB4F@w3.org>
To: Roy T. Fielding <fielding@gbiv.com>
On Aug 27, 2012, at 1:02 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 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).

To be clear, it sounds like you mean by "worst case", "the context with the greatest restriction on tracking defined in the Compliance spec for which all resources on this site are designed to comply, or X to indicate that compliance varies by context". (I thought "1" would be possible because I was interpreting "worst case" as "the least restrictive level of tracking defined in the Compliance spec for a resource on this site".)

> 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.

Understood, if checking type of tracking compliance before loading a resource is essential, then we wouldn't want a Tk-header-overrides-any-WKL policy. Of course, the Tk header does still override for cases of out-of-band consent and still must be checked after the fact for all sites that list "X" in their site-wide tracking status resource. My concern about efficiency was just that there might be a large number of sites that need to list "X" for their site-wide status and then be required to send a Tk header on every response.

> 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.

I don't think my suggestion implies anything different for Web sites that don't perform third-party tracking, or that it requires the entire Web to change. We agree that for those sites, a site-wide status of "1" or "N" suffices. I was just noting the case where most requests to a domain would be in a third-party context but a few might be in a first-party context (and be tracked as such).

Received on Tuesday, 28 August 2012 00:58:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC