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.
- 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
- 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)
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>
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:
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:
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.
- gibson research corporation
- what is the difference between localstorage, sessionstorage, session and cookies