- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 23 Aug 2012 12:27:54 -0700
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Regarding ISSUE-60 and the TPE "1" response. I had a discussion on private email within the TPE editors group which I forgot was on private email and hadn't been exposed to group review, so here it is ... The "1" response says that: The designated resource is designed for use within a first-party context and conforms to the requirements on a first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party. As written in TPE, a site's claims of compliance can't be altered by other sites choosing to use the resource in a third-party context. It is not BigCo's responsibility to ensure that its own first-party tracking pixels are not found on other sites, assuming that it never advocated such usage; any other choice would leave BigCo open to lawsuits whenever some fool HTML designer decides to cut and paste. Neither browser nor origin server can reliably distinguish between first-party and third-party requests. For the protocol, however, it is sufficient to know what is being claimed in terms of compliance. It is the origin server's responsibility to ensure that its claims are consistent with how it advocates use of its own resources and how those resources are used in most cases; it is not the origin server's responsibility to ensure that its resources will always be used, in every single corner case, the way they have been designed and documented. It is possible that we need more requirements in the TPE or Compliance specs regarding what it means to be consistent with resource docs and advocated use. Clearly, an API published for third-party use must have a final answer of "3" when used from a third-party site. Likewise, there needs to be something like a preponderance of use, where an origin server cannot claim "1" if it knows that most of the accesses are from third party sites even if the resource was not designed for that purpose. These kinds of requirements are feasible to implement, as opposed to the general claim of *being* the first party (which is not implementable in general). What matters for the tracking status is the set of requirements that the resource claims to adhere to. If an actively verifying browser does not think it is the right set of requirements given the request context (which only it knows), then the browser can flag that to the user as a potential compliance failure (I say potential only because it is a manual process to verify the scope of a first party). Hence, transparency is accomplished without requiring that the server dynamically determine the cause of the browser's request (except for the "X" case where the server is saying it is capable of dynamically determining that and will tell you the answer in the header or request-specific TSR). The end result is that the UA gets the answer it needs regarding tracking behavior and tracking status remains cacheable for resources that are designed for same-site use. It is the only solution that I have been able to find that satisfies the WG's current constraints. ....Roy
Received on Thursday, 23 August 2012 19:28:06 UTC