requirements on consistency of "1" response with actual use

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