RE: technical issues with multiple first parties: TPE and compliance

I owe a technical response to the group (next Monday).  The simplest response is that the TPE and C&S documents have always considered more than a single domain name for 1st party consideration and the appropriate elements are already mostly in place to support this concept.  The one add'l item needed is possibly a flag to denote the delta between a "same party" vs. a "co-1st party".  More to come...

- Shane

From: Peter Swire [mailto:peter@peterswire.net]
Sent: Sunday, March 17, 2013 11:09 PM
To: Edward W. Felten; <public-tracking@w3.org>
Subject: Re: technical issues with multiple first parties: TPE and compliance

Before I saw Ed at a conference this week, I had not really been aware of the technical concern that he expresses in this email.

This technical concern apparently raises issues that implicate both the TPE and compliance specs.

I am curious whether anyone in the group has a technical response to Ed's post.

Thank you,

Peter



Professor Peter P. Swire
C. William O'Neill Professor of Law
    Ohio State University
240.994.4142
www.peterswire.net<http://www.peterswire.net>

From: Ed Felten <felten@CS.Princeton.EDU<mailto:felten@CS.Princeton.EDU>>
Date: Sunday, March 17, 2013 8:58 PM
To: "<public-tracking@w3.org<mailto:public-tracking@w3.org>>" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: technical issues with multiple first parties
Resent-From: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Sunday, March 17, 2013 8:59 PM

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<http://examplesite.com>.  Should the browser send DNT:0 with the request?   If examplesite.com<http://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<http://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<http://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