148
edits
Thirdparty: Difference between revisions
→Analysis
| Line 34: | Line 34: | ||
:'''base domain:''' ''the toplevel domain for a given site, e.g. for mail.google.com the base domain would be google.com.'' | :'''base domain:''' ''the toplevel domain for a given site, e.g. for mail.google.com the base domain would be google.com.'' | ||
= | = Discussion = | ||
This prevents tracking by third parties across different sites ( | This prevents automatic tracking by third parties across different sites (cases 1 and 2), since there's effectively a separate third party store per first party site. It also prevents automatic sending of session information in a third party context, even when the user has logged into that site as a first party, since the third party store is separate from the first party store for a given site. | ||
It allows cases where temporary third party cookies are required on a given first party site (case 4), since those situations will have the same (first party, third party) key | It allows cases where temporary third party cookies are required on a given first party site (case 4), since those situations will have the same (first party, third party) key. Whether we limit third party cookie lifetime to session only will have no effect here. | ||
It can also allow OpenID and Facebook Connect to work, with some additional user interaction. The (first party, third party) context will prevent an existing Facebook login (via facebook.com) from automatically carrying over to another site (huffingtonpost.com). However, the user can log in to Facebook from Huffington Post, and separately for each site that embeds Facebook, and things can work as usual. If we optionally limit third party lifetime to session, this login will persist for the session only. If the user trusts Facebook, they can whitelist facebook.com (via the usual mechanism) to circumvent the double keying restrictions, resulting in their Facebook login to carry over to all other sites. | |||
The tricky part is defining in what cases the first party context should carry over. For instance, an iframe within a page has an obvious first party domain (the urlbar). What about a redirect (such as a clickthrough ad, or an OpenID login)? 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. | The tricky part is defining in what cases the first party context should carry over. For instance, an iframe within a page has an obvious first party domain (the urlbar). What about a redirect (such as a clickthrough ad, or an OpenID login)? 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. | ||