Thirdparty: Difference between revisions

:2. There are two cases when clicking on a link: a) the link is targeted at the same domain; b) it is not. For the former, what we do is irrelevant. For the latter, by and large, it means the link is not integrally related -- I strongly doubt, for instance, that any federated login processes use <href> tags pointing at their domain. ''Is this really true? Are there other relevant use cases?''

:3. The answer to this really depends on what use cases exist on the web. Someone out there undoubtedly uses document.location to implement an authentication scheme. Need more hard data here. However, I suspect that the right thing to do is consider it unrelated.

:4. This case is clearer. Many services, such as bit.ly, immediately and permanently redirect to a target. Sites that redirect from ''original'' to ''target'' and back to ''original'' probably mean the two are related, and could easily be an implementation of federated login. It could also be an implementation of an auto-redirect ad. What we do here is important to get right.

:The key is [TBD...]

Since it's an obvious hole, we have to track first party context through redirects. (So going to digg.com --> redirect to clickthrough ad on ads.google.com --> click back to digg.com would maintain a first party context of digg.com throughout.) If we didn't, those clickthrough ads would be first parties, and could track the user across sites.

Facebook Connect uses a JS lightbox to throw the login dialog (http://wiki.developers.facebook.com/index.php/Authenticating_Users_with_Facebook_Connect). This counts as part of the page, rather than a popup window, and thus would be considered a third party. So double-keying would work fine here. Note that the embedder can specify they want to use a popup dialog instead, but let's say

that's not the common case.

OpenID probably uses redirects in general (http://www.merchantos.com/makebeta/php/single-sign-on-with-openid-and-google-part-1/), though I'm not sure about provider specifics. If we track redirects and consider them third parties -- which would require some extra mechanics -- then this would work just fine. (So going to digg.com --> redirect to clickthrough ad on ads.google.com --> click back to digg.com would maintain a first party context of digg.com throughout. If we didn't, those clickthrough ads would be first parties, and could track the user across sites. So doing this is good all around.)

Note that Opera does something interesting here: by default, they consider redirects to be "unverified transactions", which are considered third party. Link clicks are verified transactions -- first party. This is actually part of RFC2965 (http://www.faqs.org/rfcs/rfc2965.html) section 3.3.6: "A transaction is verifiable if the user, or a user-designated agent, has the option to review the request-URI prior to its use in the transaction." In Opera, with "automatic redirection" turned off, I believe this means that redirects throw a page which says "this is a redirect to http://foo.com, continue?" or somesuch. Clicking that link then makes the transaction verified, and the cookies are first party.

With that, I propose (where it is implied that the first party domain carries over, until reset):

We might want to make link clicks carry over the first party. Rationale: a site that relies on an href click (to a third party) to perform a login operation, rather than using a redirect or document.location, needs that load to carry over the first party such that things work when redirected back. The downside is that long browsing sessions in a single tab, across multiple sites, will result in them all being considered third party. (And thus allow behavioral tracking during that tab lifetime.) Having it reset is probably a good tradeoff, since it's less surprising. But it would allow holes, e.g. where a site has a link targeted at ads.google.com which then redirects back to some content.