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