RE: technical issues with multiple first parties

Hi Ed,

 

The UA does not need to check if there is another first-party on a page, it
just sets the DNT:0 header if tracking consent has been registered, i.e.  to
a resource where it has previously registered an exception (aka tracking
consent). Tracking consent (site-specific or web-wide) can only be
registered with the JavaScript API, unless the general preference for all
transactions has been set to DNT:0.

 

If a site has defined itself as having multiple first-parties then one of
the first parties will be represented in the address bar URI i.e. a resource
sharing the top-level domain name, and others will technically be embedded
third-parties, i.e. an external server is sent an HTTP request to access a
resource addressed by a rendered HTML element or via a redirect chain.

 

Under the current definition of the API only resources sharing the top-level
domain origin or named external resources accessed as a result of rendering
a top-level domain resource, can be registered with tracking consent. The
API does not specify the top-level domain name that is to receive tracking
consent, it is implicitly assumed to be the domain origin of the executing
context i.e. the domain origin of the document containing the executing
script. It can specify what external resources will receive tracking
consent, but this consent only applies to accesses in the context of the
top-level domain (unless the API registered a web-wide exception.

 

The problem with the concept of multiple first parties is with DNT:1. In
this situation a third-party server (i.e. a server handling an external
resource) can arbitrarily decide it is a first party and either ignore the
absence of tracking consent, or use the API and cross-domain signalling to
give its own domain tracking consent. This directly arises from the decision
to give  first-parties a free pass which means that even if a resource
receives  DNT:1, then it can reply with Tk: 1 if it considers itself to fall
under the definition of "first-party", and track the visitor regardless
(though with no sharing). As has been said many times , this is not a
problem in the EU because there is no free pass, and in my opinion a Tk: 1
response carries no meaning in the EU. 

 

There is an associated problem, how to communicate a user's tracking consent
to other top-level domains, either when they are controlled by joint data
controllers or because they are domains controlled by the same entity that
controls the top-level domain i.e. multiple domains belonging to a single
data controller. A user could be informed that multiple controllers are
involved and asked to give consent to all of them under the same basis. We
have talked about ways to do this for instance using an array element in the
TSR or a new parameter to the API listing the other parties, but that breaks
the well-established same-origin rule. Fortunately there are others ways to
communicate tracking consent in these situations such as the way I described
in Boston of using an embedded frame and cross-domain signalling.

 

Mike

 

 

From: Edward W. Felten [mailto:felten@CS.Princeton.EDU] 
Sent: 18 March 2013 00:59
To: <public-tracking@w3.org>
Subject: technical issues with multiple first parties

 

On the last call, I expressed technical reservations about the proposal to
allow multiple first parties on a page.  Peter asked me to elaborate on my
concerns in an email to the group.

 

The core issue is that we would be invalidating some basic technical
assumptions that we have been making since very early in the process.   My
concern is that those assumptions are "baked in" to the system's design so
deeply that undoing them would cause technical problems to pop up.

 

One example of an assumption we would be undoing is the assumption that the
User Agent (UA) knows who the first party is before it sends an HTTP
request.  The exception system says the UA is supposed to send DNT:0 when
the user has granted an exception for the first party.  This works fine when
the identity of the first party is evident from the URI, because the UA
always knows the URI before sending a request.

 

Suppose the user clicks a link to http://www.examplesite.com, and the user
has previously granted an exception for examplesite.com.  Should the browser
send DNT:0 with the request?   If examplesite.com is the only first party,
then DNT:0 should be sent.  But if there might be an additional first party,
then the UA shouldn't send DNT:0 because it doesn't know who the additional
first party might be (and therefore can't know whether the user has granted
an exception to the additional first party).   The only way for the UA to
figure out whether there is an additional first party is to load the
Tracking Status Resource (TSR) from a well-known URI on examplesite.com, and
look in the TSR to see if there is another first party, before it can access
the URI that the user actually wants.  

 

Because any page *might* have an additional first party, this would appear
to require the UA to pre-load the TSR before accessing any URI for which it
would otherwise be willing to send DNT:0.  This makes access to sites with
exceptions much slower.  (Note that caching the TSR would have limited value
here because examplesite.com would have to use a page-specific TSR for the
page that has an additional first party, in order to convey the first-party
information specific to that page.)

 

The need for the UA to load the TSR in order to behave correctly undoes
another significant early design decision, which is that loading the TSR
would always be optional, in the sense that a UA could comply with the
standard even if it never loaded a TSR.   Loading the TSR lets the UA
implement useful features, but whether and when to do so has been up to the
UA developer.  (This is important for resource-constrained UAs such as some
mobile browsers.   It also provides valuable engineering flexibility even
for UAs that want to use the TSR, because it lets the UA developers make a
case-by-case decision about the cost vs. benefit of accessing the TSR in
each specific instance.)  

 

I haven't done a comprehensive review of how adding extra third parties
affects the implementability of the standard, but I fear that a more
detailed review would discover more problems.  

 

(Of course, these issues are not a problem in the case we have long
discussed in which a third-party element on a page acquires first-party
status when the user interacts with it.)

 



-- 
Edward W. Felten
Professor of Computer Science and Public Affairs
Director, Center for Information Technology Policy
Princeton University                
609-258-5906           http://www.cs.princeton.edu/~felten