Most of the things that people do not actually see during their time in Internet usually stay uncovered forever. Of course, I am not referring to the experienced users.

Thus, I have decided to write this article about the HTTP Cookies or the Internet Cookies in a more non-technical way because there are a lot of technical literature regarding this topic, however, it might be “too technical” for a big part of the people who use Internet.

A short definition of Cookies

This is a collection of information, usually including a username and the current date and time, stored on the local computer of a person using the Internet. It is used by websites to identify users who have previously registered or visited the site.

The actual meaning of the words above

As most of the short definitions this one also is not explaining the whole idea of the HTTP cookies. To put the meaning of the text above in more words we can say that the HTTP cookies, sometimes known as web cookies or just cookies, are parcels of text sent by a server to a web browser and then sent back unchanged by the browser each time it accesses that server. Cookies (as we will call them in this article) are used for authenticating, tracking visitor behavior, and maintaining certain information about users, such as site preferences. The term “cookie” is derived from “magic cookie,” a well-known concept in UNIX computing which inspired both the idea and the name of HTTP cookies.

Without cookies, each visit, access, retrieval or a click on a Web page or component of a Web page is an isolated event, mostly unrelated to all other views of the pages of the same site. As you can probably imagine, this will be a huge inconvenience if the page is not a static one and you need to adjust the changes you have done every time you perform any action on the site.

By involving the cookies into this process Web site authenticated users are able to set their own preferences on the website functionality and appearance such as skin, menus or how many results to be displayed by the search form for example.

Another possible understanding of the cookies can be as a state (memory of previous events) into otherwise stateless HTTP transactions.

Cookies history

As we have already mentioned the term “HTTP cookie” derives from “magic cookie”, a packet of data a program receives but only uses for sending it again, possibly to its origin, unchanged. Lou Montulli was the man who came to the idea to implement the UNIX concept of the magic cookies into the web communications. This happened in June 1994. At that time, he was an employee of Netscape Communications. They have been developing an e-commerce application for a customer and they needed a solution of the problem with the “shopping cart” or known as “shopping basket”. A possible way to keep the information of the products which have been already selected by a customer and collect them into a list called shopping basket even if the visitor decide to navigate to another page of the site or close the it and return again after some time. Cookies provided a solution and a possible way to implement this idea into a dynamic e-commerce website.

Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies. The first actual use of cookies (out of the labs) was made for checking whether visitors to the Netscape Web site had already visited the site. Montulli applied for a patent for the cookie technology in 1995; it was granted in 1998. Support for cookies was integrated in Internet Explorer in version 2, released in October 1995.

Still, during this period the idea of the web cookies and the particular use were not widely known and they were accepted by default without any user notification. General public learned about them after the Financial Times published an article about them on February 12, 1996. In the same year, cookies received lot of media attention, especially because of potential privacy implications.

Putting into practice and specifications

The Shopping Cart Basket

Many shopping carts (e-commerce websites) nowadays allow a user to store a number of products that have selected into a virtual basket even if he/she is not logged in. This virtual basket is called Shopping basket. The user starts navigating the site with an empty basket, and can add items to the basket while visiting the site. The list of items the user has chosen can be stored using cookies. For example, the server sends an empty cookie to the browser when the user visits the first page; whenever the user adds an item to the basket, the server adds the name of the item to the cookie.

In this way, the visitor can checkout even if he/she is not registered user of the website. Additionally, it is possible to close the page and return latter to continue with the shopping process without adding all the products into his/her basket all over again. This is achieved by keeping the cookie that has been sent by the website the last time he/she has visited the website.

However, this method is criticized as a very insecure mechanism, because a malicious user can alter the cookie; a much more secure mechanism is to generate a random cookie as under “tracking”, and using that as a lookup key in a database stored on the server.

By having the cookies, nowadays, shopping applications can store information about the currently selected items, can send back registration information and free the client from retyping a user-id on next connection; sites can store per-user preferences on the client, and have the client supply those preferences every time that site is connected to.

Allowing users to log in to a website is another use of cookies. Users typically log in by inserting their credentials into a login page; cookies allow the server to know that the user is already authenticated, and therefore is allowed to access services or perform operations that are restricted to logged-in users.


By the official RFCT documentations 2109 and 2965 Cookie names are case insensitive.

Furthermore, there are limitations on the number of cookies that a client can store at one time. Below is a list of the minimum number of cookies that a client should be prepared to receive and store.

  1. 300 total cookies
  2. 4 kilobytes per cookie, where the name and the OPAQUE_STRING combine to form the 4 kilobyte limit.
  3. 20 cookies per server or domain. (note that completely specified hosts and domains are treated as separate entities and have a 20 cookie limitation for each, not combined)

Servers should not expect clients to be able to exceed these limits. When the 300 cookie limit or the 20 cookie per server limit is exceeded, clients should delete the least recently used cookie. When a cookie larger than 4 kilobytes is encountered the cookie should be trimmed to fit, but the name should remain intact as long as it is less than 4 kilobytes.


A web server that sends cookies to a visitor browser can set a certain expiration date on the cookies after which the information (the cookies file) will be removed. If an expiration date is not specified the cookies will be available until the visitor clear his/her browser cookies data.

As a result, setting a date specifications is a way for making a cookie survive across sessions. For this reason, cookies with an expiration date are called persistent. As an example application, a shopping site can use persistent cookies to store the items users have placed in their basket. This way, if users quit their browser without making a purchase and return later, they still find the same items in the basket so they do not have to look for these items again. However, after the expiration date of the cookies the items into the shopping cart will not present if the user visit the site again.

If the user logout the browser may clear the cookies for the particular domain name and your stored order will be no longer available next time when you login even if the expiration date of the cookies has been set to a future date.

This explains to some extend why your webmail provided may recommend to logout every time you would like to close your webmail client. By logging out instead of just closing the window your server session will be terminated and even if an intruder tries to access your mail with your own cookie file the system will require username and password once again.

Cookie Hijacking and Drawbacks

There are many topics on which the cookies are criticized, however, in this article I would like to concentrate only on their purpose. Still, I think that it will be appropriate to mention some facts that answer a couple of questions.

Why we need our Wi-Fi networks secured?

Cookies can be stolen via packet sniffing in an attack called session hijacking. Traffic on a network can be intercepted and read by computers on the network other than its sender and its receiver, (particularly on unencrypted public Wi-Fi networks.) This traffic includes cookies sent on ordinary unencrypted http sessions. Where network traffic is not encrypted, malicious users can therefore read the communications of other users on the network, including their cookies, using programs called packet sniffers.

Possible solutions

A possible solution of this issue is to have your communication between the users` computers and the server secured. This can be achieved by employing Transport Layer Security (https protocol) to encrypt the connection. A server can specify the secure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.As you have probably noticed most of the online stores change the connection over https during the check out process in order to secure the data transaction while your personal and credit card information is sent.

However a large number of websites, although using secure https communication for user authentication (i.e. the login page), subsequently send session cookies and other data over ordinary unencrypted http connections for performance reasons.

Cross-site scripting

Another possible way to have your cookies stolen is by cross-site scripting. This method makes your browser itself send cookies to third party servers that should not receive them.

This type of cross-site scripting is typically exploited by attackers on sites that allow users to post HTML content. By embedding a suitable piece of code in an HTML post, an attacker may receive cookies of other users

Possible solutions

A way for preventing such attacks is by using the HttpOnly flag this is a Microsoft option that makes a cookie inaccessible to client side script. However, website designers should consider designing their websites so that they are immune to cross-site scripting.

There are some other additional security issues with the cookies because of which users are advised to use the more recent versions of web browsers in which most of the security flaws are resolved by default.

Some certain facts

It is not true that:

* Cookies are like worms and viruses in that they can erase data from the user’s hard disks

* Cookies are a form of spyware in that they can read personal information stored on the user’s computer

* Cookies generate popups

* Cookies are used for spamming

* Cookies are only used for advertising

Cookies are in fact only data, not program code: they cannot erase or read information from the user’s computer. However, cookies allow for detecting the Web pages viewed by a user on a given site or set of sites. This information can be collected in a profile of the user. Such profiles are often anonymous, that is, they do not contain personal information of the user (name, address, etc.) More precisely, they cannot contain personal information unless the user has made it available to some sites. Even if anonymous, these profiles have been the subject of some privacy concerns.

Most modern browsers allow users to decide whether to accept cookies, but rejection makes some websites unusable. For example, shopping baskets implemented using cookies do not work if cookies are rejected.

  • Stuart

    Every time i come back here I’m reminded why I added your site to my favorites:)