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

Roy,

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

The TPE does not say this. DNT is sent to all parties, who must respect it
if compliance means anything. Why would first-parties not use the same
mechanism to signal OOBC?

>A site owner is unlikely to change the Tk response per user. That's too
late.

No its not. Servers already commonly dynamically change content depending on
request headers, e.g. accept-language, accept. The cookie header can signal
different response for authenticated users etc.
They can use the vary response header to tell browsers when to send a
request etc. (except often for the cookie header which as you have pointed
out, makes OOBC problematic anyway).
Anyway you expect request-specific TSRs to change immediately no? A hosted
site has to determine user consent itself anyway, and convey that using the
status-id if it cannot do it in a Tk response header. 

>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 C response for all users makes no sense. How can a site declare that all
users have given consent? 

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

Nowhere does it say this, in fact the TCS says a C MUST be sent when data is
shared with third-parties (transitive permissions).

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

They might, the TPE does not say they cannot.

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

EU law requires transparency and prior user consent (except for a limited
number of exceptions). It will have a bearing on DNT when the JS API is not
available and consent has been acquired the old fashioned way. How else
would they be able to communicate that?

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

They are only  permitted to if the user has given consent, or the purpose
for storage or processing is for one of the defined exceptions.

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

So it is required in those circumstances. I would claim It is also required
for OOBC i.e. Tk: C. By its nature this has to be dynamic (it depends on the
cookie header).

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

How would a server communicate a request-specific TSR without a response
header (that includes a status-id)?

If the only option was a dynamically determined TSR (based on an incoming
cookie header to the .well-known location) then this would mean an extra
roundtrip for every request for the user agent to determine it. A Tk: C
response is far more efficient.

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

The problem already exists with Internet Explorer, Bouncer and
PrivacyBadger. The EFF policy assumes consent is signalled with Tk: C, and
there has been discussion about using Tk: D as a signal to request
PrivacyBadger to block subresources.


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

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

European law has a different take on tracking, as I explained when we were
debating the definition. User consent is necessary for both access to user
agent storage as well as for processing of personal data, and Do Not Track
has been widely recognised as a means to communicate it (in the ePrivacy
directive in recital 66 and A5(3), the proposed ePrivacy Regulation in
A8,A9, A10,R22-24 and the GDPR in A6 and A21.5)


The rules about the Tk header and dynamic TSRs are far too complex and will
probably never be properly implemented. The only realistic use for it is
signal OOBC which will not be relevant when browsers support the API, IMO
the sooner the better.


Mike

Received on Friday, 3 February 2017 12:54:24 UTC