How ‘allow all cookies’ became the default

Cookies enable sites to remember your login, what you’ve put in your shopping cart, and allow a site to remember language or currency preferences. These features enable the sites you’re visiting (‘first parties’) to improve your user experience and provide some content behind authentication, only accessible to you.

Browsers also, by default, send cookies to any third-parties embedded by the site operators. In some cases, these can be used to allow third-party widgets, such as Disqus comments, to automatically log you in to embedded content in the page. However, it also enables these third-parties to track your browsing across the web.

Allowing cookies to third-parties opens up a privacy hole in your browser. On many sites, just visiting a page will set cookies for over 50 different third-party domains. Each of these are setting cookies so they can correlate requests coming from your browser over days, months, or even years. For example, when you visit any page with a Facebook widget (or visit Facebook itself), they will set a cookie which will only expire in 2 years time. Some google.com cookies expire in 20 years!

The facebook.com and google.com (tracking) domains are present as a third-party to 24% and 30% of page loads on the web respectively, allowing these services to track this proportion of the average user’s web browsing history.

Third-party cookies not only pose a threat to your privacy, they also represent a serious security risk to you. Cross-site request forgery (CSRF) attacks are based on the idea that I can make a third-party request to a site that the browser has previously authenticated with, and the browser will send the credentials with the request. If browsers did not allow third-party cookies these attacks would be much harder to exploit than they currently are. These kinds of attacks have been around for over 15 years, and methods to mitigate them are still being proposed, while browser-side protection, such as first-party isolation, have very limited distribution.

Furthermore, the use-cases which legitimately use third-party cookies, like Single-Sign-On portals, or third-party authentication mechanisms, have alternatives which do not require cookies. Sites using a centralized authentication domain can obtain authentication tokens via first-party redirects, and OAuth can be used to log in to sites using third-party credentials. These mechanisms have the added bonus of transparency and implied consent: When a user logs in with Facebook on a site, the user is actively allowing this connection between the site and Facebook to proceed. (Note that both methods also have some privacy issues that can be exploited for user tracking and permission escalation.)

So why do we have third-party cookies? Actually, when the idea of cookies was first proposed in the original 1997 RFC Specification, the standard writers were concerned about the privacy implications of allow third-party cookies, and specified that browser vendors should disable them by default. However, these recommendations were not implemented by browser developers at that time, and the default of ‘allow all cookies’ has remained since then.

Currently, almost all major browsers have a default to allow all cookies. The effect that this default has had over the last 20 years, is that developers now assume that cookies are allowed in all contexts. This causes many workflows to break once this assumption is broken. This leads to a vicious cycle, where attempts to limit third-party cookies are foiled because they break too many sites.

This even applies to several major sites and services, including those from Microsoft and Google, which fail badly when third-party cookies are blocked. We will discuss this in more detail in the second part of our blog series.

This article was first published in full on WhoTracks.me.