Re: Supporting TPE on sites/subdomains where a user does not have control of the server (ISSUE 15, ISSUE 10)

> On Jan 31, 2017, at 4:51 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> Hi Roy,
>  
> On the hosting issue, it is not trivial on some hosting sites and in any case it needs to be dynamic.

I said it is trivial for the hosting provider, and yes it is also trivial
to make it dynamic based on the presence of a request cookie, though you
are apparently confused about the content of Tk.  The value in the header
field is generally not going to be C from a first-party site; it will be
N or T or "?".  C would be sent from a third-party resource that believes
it already has consent to perform tracking as we have defined it in our
specification (retaining identifiable data across multiple sites).

A site owner is unlikely to change the Tk response per user. That's too late.
Instead, what they would do is selectively disable (or not include) content
that causes tracking requests to occur until the consent is received [aside
from the security-related tracking that is permitted without consent].
IOW, unless they have implemented it foolishly, the Tk header field will
normally be a static value per resource (such as "Tk: ?;fRx42") and a
user's requests would only result in being tracked if the site believes it
has already obtained their informed and specific consent (or doesn't need it).

For hosting providers that support multiple owners per origin server, the
primary TSR is going to have a status of "?" (dynamic) and each resource
is going to have a fixed status-id.  Any "C" response would have to be
fixed per resource as "C" for all users (provided in both the Tk header
field and the request-specific TSR) or provided only in the request-specific
header field after responding with "?" again in the Tk header field.

A dynamic response of "Tk: C" or "Tk: N", selectively chosen per user, is
not allowed by TPE.

For sites that do not track, their response is N at the primary tracking
status resource. They never send Tk at all.

As usual, these mechanisms are not affected by EU regulations. The regulations
don't limit consent mechanisms to the one defined in TPE, and a C response
in TPE does not imply that the TPE exceptions API is being used to maintain
that consent.

Almost all hosting providers currently track users, based on our definitions,
just to maintain operations and provide the owner with referral data. AFAICT,
they are permitted to do so even under EU regulations.  Hence, aside from
first party sites that are specifically configured to exclude normal tracking
(like Duck Duck Go), most sites will be responding with T or ? for their
HTML pages.  In any case, the Tk header field is only required when the
site-wide response is ? or G.

> If a site has consent for tracking (presumably the state is encoded in a cookie) it must respond to that user with Tk: C. There would have to be an API not just a static config setting, and maybe this is supported on some hosting sites, but by no means all.

No, that's not even remotely true.  The TSV of "C" is communicated in either
the site-wide TSR or the request-specific TSR, both of which are separate
resources that don't need any response header fields.  The only time that
"C" would be in a Tk header field is if that response is the same for all
users (i.e., if access implies consent) and the site chooses to send that
in the field-value instead of sending "?".

> I know for a fact that this is difficult for many first-party sites, and not just Wordpress ones. Major multi-brand companies find this logistically difficult now, as I have explained many times. As DNT becomes more supported this will be less so, but for now we have a transition issue.

I have no doubt that they find it difficult now, given the absence of
useful examples in the spec and written user guides.  Much of that has
been waiting on evidence of browser implementations.  Neither one is 
a protocol issue.

> It is also wrong to assume users are only concerned with the “tracking policies of embedded third-party resources linked to by [first-party]” sites.
>  
> Most users do not understand the vagaries of HTTP or HTML embedded resources, they simply do not want be tracked across the web. We know that most tracking is enabled by embedded sub-resources but not all. Some first-party sites share cross-domain identifiers e.g. derived from browser fingerprinting, mediacapture device ids, first-party cookies with universally managed UIDs, and a host of other ways.  

Tracking is defined in the spec. That is the only tracking denoted by Tk,
and the mechanism used for tracking is irrelevant.

>  In any case it is the responsibility of first-party sites in Europe to act if consent has not been established. It is the first-party sites that insert the iframes, images and externally supplied javascript. If they cannot rely on third-parties to respect DNT (which is the case at present) then they must enforce it for their users with tag management or other procedures, and if the API is not there they have to use the response header to indicate OOBC.

The Tk response does not have any relevance to adherence to the EU regulations.
When they apply to a given site, adherence is legally required regardless of the
protocol or mechanisms used, even if the site doesn't implement TPE and doesn't
respond at all.  Our specs do not change that.

What we are providing is a standard that enables clients and servers to choose a
means of communication that can more easily be automated and preserved by
both sides, specifically because of the shared vocabulary being used and helpful
links provided in each TSR.  This standardization will eventually make it possible
to have common configurations provided out of the box for software like
multi-owner hosting environments, and hopefully simplify the implementation
of the more complex, multi-brand sites that use WCMs (like Adobe Experience Manager).

> I agree the response header is the preferred mechanism, but if it not available to many sites it would be wrong of us to refuse them the capability to comply with DNT.

This is not an issue with the protocol as defined.  It may perhaps be an
issue with the way you chose to implement the protocol, but that is
certainly not how it is specified in TPE.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

Received on Friday, 3 February 2017 01:31:45 UTC