blog

Cookies, Third-Party Cookies, and Local/Session Storage

In this post I will make a brief introduction to cookies, but more importantly, I want to talk about third-party cookies: What are they? Where do they live? How are they born? What do they eat? And what are the alternatives?

Due to the nature of HTTP (based request and response), we don't really have a good way to store sessions (have a fixed, persistent memory between visits in a webpage), this is solved by using cookies: the website creates a text file on the client's computer, and this cookie can be accessed again by the same website. This solves the problem of having to ask the client's username and password for every single page, for instance, or storing information about his "shopping cart" (when not using databases). There is also a security feature: a website cannot access cookies that it didn't create, in other words, the cookie is only available to the domain that created it.

Cookie monster

According to scientists, this is how a cookie looks like

HTTP Cookies first appeared in the Mosaic Netscape navigator (the first version of Netscape), being followed by Internet Explorer 2. They can both be set on the server-side (with PHP, for instance) or on the client-side, using JavaScript. There are several types of cookies:

  • Session cookies are deleted when the browser is closed
  • Persistent cookies are not deleted when the browser is closed, but expire after a specific time
  • Secure cookies can only be transmitted over HTTPS
  • HttpOnly cookies cannot be accessed on the client side (JavaScript)
  • SameSite cookies can only be sent when originating from the same domain as the target domain
  • Supercookie is a cookie with a "top level" domain, such as .com and are accessible to all websites within that domain
  • Zombie cookie gets automatically recreated after being deleted Third-party cookies (I will talk about them now)

Third-party cookies

Cookies are a lot more powerful than they seem, despite the obvious limitation of only being available to the domain: let's suppose I have a website called foo.com and I decide to put some ads in other websites: bar.com, baz.com and qux.com. Instead of simply offering these websites a static image with my advertisement, I could pass a PHP file that generates an image:

<a href="..."><img src="https://www.foo.com/banner.php" /></a>

This PHP file would just generate an image dynamically, but it could do more: it could send JavaScript to the clients and set cookies in the websites that I announced. When someone access the website baz.com, my script could detect the website address (baz.com) using JavaScript (window.location), and record this information in a cookie. When the user navigates to other websites with my ads, such as baz.com or qux.com, my script would repeat the process. This information would be accessible to me: I would know exactly which websites the user visited.

Third party cookies

Courtesy from Wikipedia

Problems with privacy and blocking

Needless to say, people who are slightly concerned with privacy do not like cookies; especially for non-techie people, this is a very convenient witch to hunt - I am surprised that magazines and newspapers are not abusing it. Most modern web browsers can block third-party cookies, which is a concern if you are planning a service that relies entirely on this feature.

It's not easy to find statistics about cookie usage, but I got one from Gibson Research Corporation:

Browser usage Browser usage

Cookie configuration by browser

Cookie configuration by browser, where: FP = First-Party cookie and TP = Third-Party cookie.

It seems that Third-Party cookies are disabled on Safari by default, while other web browsers are also getting more strict about them. Despite still being used, it seems that this practice is reaching a dead-end. On top of that, cookies are also not being able of tracking users across different devices.

Alternative: Local/Session Storage

Apparently, cookies are dying. It may be a little too early to say this, but we don't want to create something that will be obsolete in 5 years, so it is a good idea to plan ahead. What is the future, then?

Probably, the most promising tool is called Local and Session Storage, it also seems to be supported in the newest browsers:

Compatibility for Local and Session storage

Compatibility for Local and Session storage

The way Local and Session storage work is very simple: they behave as a little database in the browser, storing key-value pairs of plain text. While Local Storage is persistent (does not get deleted), Session storage lasts only while the browser is open (it is deleted when the browser is closed, but not when the page is refreshed). It is great for storing persistent and non-sensitive data, but they are not accessible from the server: the storage is only accessible from the client-side - if the server must have access to it, it must be sent manually.

Using the local storage, it is possible to build a similar system to Third-Party cookies, with methods similar to the ones I explained. Here is an article on how to do this: Cross Domain Localstorage.

Sources