Written by Ramón Saquete
What are cookies and how do the work?
A cookie –an Internet cookie– is a small file with information that is stored in a user’s Internet browser when they visit a website. It usually stores user configuration and preferences, as well as navigation session status, for example, whether someone is logged in or not, products they’ve placed in their shopping cart, etc.
Lately everybody is talking about cookies because of the anti-cookie law in the European Union. However, there aren’t many people who really understand what they are and how they work. Let’s remedy this:
Websites are constituted by files. These files travel through networks, encapsulated in information packages that use the HTTP protocol (Hypertext Transfer Protocol). This protocol is said to have no status, because it’s unable to store it in between different requests. Some examples of statuses can be: an open session, when we aren’t visiting a website for the first time; having an item saved in the shopping cart of an online store, etc. To store this status, and to allow content located on the same URL to change depending on a user’s actions, we use cookies.
A cookie is comprised of a key that gives it a name and associates a value to it, and it can be created, modified or deleted both on the client and the server. Once created, it is sent on every HTTP request, of every file, as a parameter of this protocol. The name ‘cookies” derives from the computer term magic cookie, to define information that is sent and returned in the same way on every request.
For example, we can have a cookie with a ‘shopping cart’ key and ‘12345’ value, which indicates that a website has to show the shopping cart with the ID number ‘12345’. This shopping cart will contain those products, which a user has placed there for a later purchase.
How do cookies work?
Cookies can be persistent, or non-persistent. They are persistent if they have an expiration date, and if they don’t, they are deleted once the Internet browser has been closed. Non-persistent cookies are used for keeping a user session open, because the server recognises from the cookie identifier to which user each open session belongs.
In order to prevent any page from being able to retrieve a user’s status on another website, cookies are always associated to a domain, and can only be created, modified or deleted if they belong to the same domain or to a top-level subdomain. For example, if we’re visiting a.b.c.com, the code will be able to store cookies on a.b.c.com and b.c.com, but not on c.com. Another security restriction is that we cannot create cookies belonging to a top-level domain (for example, .com). This type of cookies is called supercookies. As an additional security measure, we can create cookies, which can be read only from a specific URL address.
Let’s see the following graphic example of what happens when cookies are created on the client and on the server:
In the previous example, all cookies belong to www.humanlevel.com, but what happens if we include a JavaScript file that is linked from another domain (for example, googleads.g.doubleclick.net) on www.humanlevel.com?
What happens is that when executed on the browser, JavaScript can create, modify and read example1 and example2 cookies, and it can forward them to its server by means of an AJAX cross request. For that reason, to improve session cookies security, it is recommended to mark them as Httponly, so as to prevent them from being read by an external JavaScript file. Moreover, if we mark them as Secure and if we use HTTPS, they will travel encrypted.
Nevertheless, when a script is generated on the googleads.g.doubleclick.net server, we are not on our domain, but on googleads.g.doubleclick.net, and thus cookies can only be created for this domain. They still get to our browser and are stored on it. This is what we call “third-party cookies“, because they are stored when someone is visiting our website, but they do not belong to our domain. This way, if we visit another page that uses the same JavaScript, or another JavaScript from a different domain belonging to the same company that send AJAX cross requests to googleads.g.doubleclick.net, it will be able to retrieve the googleads.g.doubleclick.net cookie from the server. This cookie will carry an identifier that will retrieve the information about the user, and maintain in this manner the status between different domains. This technique is most-frequently used for displaying ads of pages we’ve previously visited.
Let’s see another graphic example of how this works:
At the moment of making the first request, the server can read the URL of origin of the HTTP_REFERER parameter from the HTTP header, or, once JavaScript has been executed on the client, send to itself this information. This way, with each website visited by a user, Adsense’s server stores the history associated to the NID cookie. For that reason, if a previously visited website runs AdWords campaigns, its ads will appear on the website a user’s visiting during that exact moment.
As if this wasn’t already complicated enough, there also exist the so-called “zombie cookies“, which are created again after being deleted, because certain scripts regenerate them from time to time.
All these factors have made the anti-cookie law implementation all the more difficult to carry out, and each website needs to develop a specific solution for it.
