Re: when the Tk header is required

On Aug 27, 2012, at 8:58 PM, Nicholas Doty wrote:
> 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".)

Yes, sorry I was being unclear -- if we were to take the union of the
tracking behavior for all resources and then intersect that with the
set of requirements for each status value, then a site would presumably
want to send the status value corresponding to the most restrictive
set of requirements in compliance still honored by that union.

By worst case, I just meant "what is the worst thing the client would
expect that might come true after accessing the site", or
"don't promise more than what the worst of your resources does".
...

> 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

Not that I am aware of.  Consent would be tested on access to the WKL.
It would only differ if the browser sent different cookies. A request-specific
consent would require a first response of X.

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

It really depends on how we define tracking.

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

Yep, it's a problem, but I don't think there is a solution as long as
folks insist on detailed status.  If the response is limited to simply
"I comply" or "I don't comply", then the solution would be much easier.

....Roy

Received on Tuesday, 28 August 2012 11:20:20 UTC