Cookies are small pieces of data send by an HTTP server to an user agent (generally a browser) and sent back from the client to the server. In general, cookies are used for authentication, user tracking, maintaining user preferences, shopping carts. etc.

Cookies consist of a name/value pair set by a server by adding an extra header to an HTTP frame:

HTTP/1.1 200 OK
Content–Type: text/html; charset=ISO–8859–1
Location: blah:foo
Set–Cookie: PREF=bogus; domain=google.com

Consider a successful response received by a server. The domain** www.google.com** asks the user browser to set cookie PREF on save it for later use. All cookies previously set by a server, are sent back on subsequent requests.

Cookies were firstly thought as a mechanism for implementing persistence over HTTP communications. Since HTTP is a stateless protocol, there is no way to keep track of user interactions between different requests. HTTP protocol simply allows a browser to request a single document from a web server, without remembering who this client was. Cookies can be used to identify previous client connections, serving as the basics for implementing HTTP sessions.

There are two types of cookies:

  • Session cookies, a temporary cookie stored in the user agent memory.
  • Permanent cookies, used to store user’s preferences. Permanent cookies are stored in files and last for more than a session.

In Firefox, cookies are stored in ~/.mozilla/firefox/???.default/cookies.txt. Different browsers set a different limits for the amount of cookies a host can store. Firefox lets a domain to store up to 50 cookies per user, each up to 3-4Kbytes. You can view your cookies in Firefox by clicking on Edit->Preferences->Privacy->Show Cookies…

Netscape, and later Firefox till version 2.0, store permanent cookies in a file named cookies.txt. This file has the following file format:

.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 100103

Each line represents a cookie, composed by different fields separated by a TAB. From left-to-right this is what each field represents:

</p>
  • domain, The domain that created AND that can read the variable
  • flag, A TRUE/FALSE value indicating if all machines within a given domain can access the variable. This value is set automatically by the browser, depending on the value you set for domain
  • path, the path within the domain the variable is valid for
  • secure, A TRUE/FALSE boolean value indicating an https connection with the domain is valid to access the variable
  • expiration, The UNIX time that the variable will expire on. UNIX time is defined as the number of seconds since Jan 1, 1970 00:00:00 GMT
  • name, name of the variable
  • value, value of the the variable

    • </font></ul>

    Imagine for a moment you log in Gmail by accessing to http://www.google.com. From there you are redirected to http://www.google.com/gmail, which set the following cookie in your browser.

    .google.com TRUE /gmail TRUE 0 SID DXV9AAAA0G…

    URL was split in two parts: domain and path, setting host to .google.com and path to /gmail, respectively. SID is in this case the name of this cookie, and very long string, DXV9AAAA0G…, its value. What’s more, flag is set to TRUE which means this cookie, SID, can be shared between different applications within the .google.com domain. The highest value a UNIX timestamp can represent is sometime in year 2038. Originally, Google cookies were set to this value, though to last more than 30 years from now. Privacy advocators complains have recently led Google to dramatically reduce theirs cookies’ lifespan to just 2 years [1] .Lastly, secure field is set to TRUE which means an https connection is required.

    Firefox 3 features a SQLite3 database engine for storing permanent data such as user preferences, bookmarks, cookies, and many more. More specifically, cookies are stored in {profile_folder}/cookies.sqlite.

    A quick glimpse to this database reveals a single table, named moz_cookies, with the following data structure:

    CREATE TABLE moz_cookies (id INTEGER PRIMARY KEY, name TEXT, value TEXT, host TEXT, path TEXT,expiry INTEGER, lastAccessed INTEGER, isSecure INTEGER, isHttpOnly INTEGER);

    Since cookies are now stored in a database, field order no longer is relevant.

      </p>
    • isHttpOnly, true if the cookie should only be sent to, and can only be modified by, an http connection.
    • lastAccessed, is a new field indicating when was the last time this variable was accessed.

      • </font></ul>

      Conversely, session cookies are saved in a different file. Both Firefox 2 and Firefox 3 come with a built-in Session Store feature that saves your session data including open windows and tabs, window size and position, and text typed in forms. Session data is stored in the sessionstore.js file, located in your profile folder. So, in the example given above, SID (session id) cookie will be stored in sessionstore.js, rather than in cookies.txt or cookies.sqlite database.

      In general, every web server sets a SID cookie whenever an user logs in successfully. Google, for instance, set a SID cookie in the user’s browser once he or she logs in, or programmatically by using some of Google’s authentication mechanism: AuthSub or ClientLogin (check my previous post: “Authenticating against Google services” to see how a successful ClientLogin response looks like.) Now it seems not difficult to figure out what that SID cookie actually meant, right?

      References:
      [1] The official Google Blog, Cookies: Expiring sooner to improve privacy, 2007
      Marty Stepp, Cookies and Sessions, Web programming, University of Washington, 2007
      David Whalen, The Unofficial Cookie Guide