Authors

• Dan Witte <dwitte@mozilla.com>

Overview

Problem

Privacy on the web is not well controlled by the user. There are cases where the user has explicit and desired relationships with sites (or, in the broader sense, entities), and also expects and understands that those entities may have relationships with other entities. A good example of this is Facebook Connect, where establishing a relationship between the user, a site such as Digg, and Facebook is an explicit and desired action; in these cases, the user has given informed consent.

However, there are cases where this is not true. This may be due to implicit consent, where a legitimate relationship exists but the user is not aware of it, or does not understand its extent; in other cases, unintended consent, where a relationship exists that, were the user aware of its existence and scope, would not agree to it. Examples of the former could be the Facebook "Like" button, which can allow Facebook to determine what sites a user is visiting without their knowledge; or credit unions, where the exchange of information (via the browser) with a third party domain to implement various banking functions is common. An example of the latter could be online advertising companies building behavioral databases of user behavior, consisting of their actions across many sites over time. Such databases, if expansive enough in scope, can be used to gather personally identifiable information (PII) without user expectation or consent.

Goals

• Improve user awareness of what they're consenting to, be it informed, implicit or unintended. There are two broad approaches to this: improving awareness in general, such as by education efforts; and in specific cases, by making it clearer within the browser what relationships exist between entities on the web.

• Make it easier for the user to specify and control the relationships to which they consent, and those to which they do not, in as seamless a way possible. For the cases where the user does not explicitly consent, or explicitly rejects a specific relationship, honor that decision.

• With the above in mind, ensure that popular and useful services on the web -- such as Facebook Connect, OpenID, and banking -- continue to work as seamlessly as possible.

• Contingent on user experience and quality of implementation, enable these policies and controls by default for Firefox 4.

Use cases

To frame the following proposal and discussion, these are some simple examples of behavior on the web:

1. User visits multiple shopping sites, which have resources from ad sites embedded in iframes, images, or requests made directly from script. They are unaware the advertiser can track their movements across those sites.
2. User visits a site that embeds the Facebook "Like" button, but does not want their Facebook login cookies automatically sent.
3. User visits their credit union, which uses third party resources for banking functions, and wants those functions to work.
4. User visits a site that uses OpenID, Facebook Connect, or other federated login service, and wants to be able to log in to those services and use them with the site. Todo: OpenID may actually not require cookies on the first party site at all -- information is passed in a backchannel. Need to confirm. What about other authentication-related services?

Proposal Overview

Currently, cookies are keyed (i.e. set for and sent back to) by the domain that set them. Instead, double-key the cookies by (first party base domain, setting domain). Cookies are first party if the second key is derived from the first key, e.g. (google.com, mail.google.com); third party otherwise, e.g. (huffingtonpost.com, doubleclick.net).

Cookies are only sent back in situations where the double-keys are the same. For instance, when browsing buy.com, cookies set by an image hosted on ads.google.com would only be sent back when browsing buy.com; not when browsing another site.

In addition, third party cookies are discarded after the session (i.e. on browser close). This may be going too far -- it does not necessarily strike a good balance wrt UX/privacy. We might not want this as default behavior.

Definitions:

first party domain: the domain of the site that the user is browsing; specifically, what appears in the urlbar.

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 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. 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 (case 3), 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, and what determines what we will break, is defining what actions result in a first party vs third party context. 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 a federated login)? A popup window? Facebook Connect uses a combination of popup windows (for the Facebook login itself), and iframes on the first party page (to display relevant Facebook information), to deliver its experience. All these elements need to exist within the same context -- whether it be a first party or third party one -- for the service to work as intended.

What this logic really comes down to is separating actions related to the current site vs. actions that are completely unrelated. For instance, an OpenID login process is conceptually related to whatever site the user is on. Clicking a link to browse to another site, at the discretion of the user, is not.

With that, some terminology: there will be actions that reset (i.e. result in a new) first party domain, and actions that carry over the existing first party domain. We should decide on, and the browser should implement, the logic for each case. Note that this only applies to toplevel actions (changing the URL of the current page, or opening a popup or new tab) -- any actions embedded inside the page always have a very well-defined first party domain.

Proposal Details

1. Typing in the urlbar, loading bookmarks, other totally toplevel actions -- resets first party domain.

2. Link clicks (href tags) -- resets.

3. Setting the toplevel document.location -- resets.

4. Toplevel redirects -- resets.

5. Popup windows (window.open) -- carries over.

Rationale

Again, let me reiterate -- what matters here is not how the user thinks of a particular action, but whether the action is related, in an integral way, with the current site. This may seem counterintuitive, but: assume we have per-site cookie sandboxes; the problem now comes down to which sandbox to put each cookie into. This is less related to user perception than to how tightly coupled a given transaction is with a given sandbox.

We have some hard data points here, but more is always better, and will allow us to make a more informed decision on how these changes will affect the web.

1. Typing in the urlbar is clearly not something that can be considered as integral to the functioning of a particular site.

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. I'll posit that the right thing to do is consider it unrelated.

4. This can be divided into two cases. Many services, such as bit.ly, immediately and permanently redirect to a target (an open redirect sequence). Sites that redirect from original to target and back to original (a closed redirect sequence) 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.

OpenID providers can implement login via redirects (although there's conjecture that this is deprecated behavior), and I believe that OpenID itself does not rely on third party cookies -- authentication is done via backchannel. So maintaining the sandbox may not matter here.

There may be ways we can figure out whether a redirect sequence is open or closed -- after the fact. Perhaps create a special sandbox for cookies during redirect, until we can determine whether it's open or closed. Needs more thought.

Is the assertion really correct that open redirects should be first party? Counterexamples?

Random thought: we could introduce the concept of per-tab sandboxes (i.e. per docshell). A toplevel redirect could switch mode from double-keying by URIs to keying by docshell. This way, the concept of first party vs. third party disappears -- all cookies for that particular tab get their own sandbox. Complicates things a bit, but might solve the problem of deciding which sandbox a redirect goes into.

5. Consider two cases: ad popups, and login popups. Both need to be considered as having a first party domain of window.opener. By way of example -- Facebook Connect uses a popup window for the Facebook login; this login cookie then needs to be accessible from within an iframe on the original site. Otherwise, the Facebook content will not appear, and in fact the login process will entirely fail. The only way to fix this, with the predicate that iframe is third party, is to keep the popup window within the same sandbox. Conceptually, it makes some sense that popups be considered related to window.opener.

What about using window.open to a site that should be considered first party -- think bit.ly but with popups instead of redirects. Do such cases exist? How prevalent are they? Can we do something smarter here?

Random Notes

Facebook Connect can use 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, and there's conjecture that this is the recommended behavior. My testing on digg.com and huffingtonpost.com indicates that popups are used in both cases.

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.

Opera does something interesting with redirects: 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.

Implementation

Relevant bugs:

• bug 565965: Double-key cookies by (first party domain, setting domain). Work is in progress.

• bug 565475: Make third party cookies persist for the session only. This is controlled by a hidden pref, network.cookie.thirdparty.sessionOnly. Landed on trunk.

• Develop a more intuitive way for the user to indicate that they trust a certain site to interact with other sites.

• Implement the first party carry-over rules described above, probably as a separate service such that localstorage etc. can use it.

• Apply the rules developed here to localstorage and such.

Further Steps

Other services such as localstorage should use a set of policies consistent with the above.

Make the browser fingerprint more anonymous, by reducing the uniqueness of queryable information other than cookies. See Fingerprinting for details.