Re: technical issues with multiple first parties

Mike,

What you are suggesting is one way of trying to deal with the problem I
proposed, which is to say that if there is an additional first party, that
additional party must always act as if the user had sent it DNT:1.   The
logic is that because the UA's choice of which DNT value, if any, to send
was intended for the actual first party, that decision cannot imply
anything about what would have been sent to the additional party.  So the
additional party must assume that the user has sent DNT:1, because
otherwise DNT:1 is no longer a universal opt-out---contradicting one of the
central principles underlying the standard.

And that approach still leaves the problem of how the disclosure aspects of
the standard would work for the additional party.  Our approach to
disclosure has been to use the URI of the primary page to compute the URI
of the Tracking Status Resource, but that doesn't work here because the
computed URI is not controlled by the additional party, and because we
cannot assume that the UA is even aware that there is an additional party
(because the UA is not required to access the primary TSR, and some UAs
will be unable to access it).



On Mon, Mar 18, 2013 at 10:32 AM, Mike O'Neill
<michael.oneill@baycloud.com>wrote:

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



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