12.3 Cookies

The customization of Web-based applications and services requires the availability of state information related to users and their browsing habits and behaviors. Unfortunately, HTTP is stateless and neither provides support for sessions, nor it knows what HTTP request and response messages actually ˜ ˜belong to the same user. Consequently, one approach to make state information available to a Web-based application or service would be to authenticate the user for each request and to store information for this particular user on the server side (e.g., in a database). Note, however, that there are at least two disadvantages related to this approach:

User must authenticate himself or herself for every request.
The Web server must store a lot of information and host a huge database accordingly .

Alternatively, one can download state information to the browser and have the browser resubmit the information when it returns to the same Web server. In this case, the state information is stored and managed in a highly decentralized way. This is basically the way the HTTP state management mechanism specified in RFC 2965 [8] works. The mechanism has a long history (in Internet time) and has gone through numerous discussions related to privacy. The interested reader is referred to [9] for a corresponding overview and discussion.

In short, the HTTP state management mechanism uses cookies that are sent forth and back between the Web server and the browser. In fact, the Web server provides cookies and the browser stores and resubmits these cookies. More specifically , RFC 2965 [8] introduces two new HTTP headers (i.e., the Cookie and the Set-Cookie header) that can be used to carry cookies and corresponding state information from one session to another. In fact, the Set-Cookie header is used by the Web server to send a cookie to the browser, and the Cookie header is used by the browser to return the cookie to the Web server when it reconnects to it. The syntax and semantics of the headers are fully specified in [8]. For example, a simple Set-Cookie response header may look as follows :

Set-Cookie: USER_NAME=Rolf; path =/; expires =Saturday, 18-May-02 23:12

The Web server sets a cookie that holds a user name in a corresponding variable (i.e., USER_NAME), and the browser stores the cookie locally. If the browser requested a resource in path ˜ ˜/ on the same server (before May 18, 2002), it would send the following Cookie request header to the Web server:

Cookie: USER_NAME=Rolf

At this point in time, the Web server knows that the requesting user has been previously assigned the name Rolf. If there were other attributes stored in the cookie, the server could customize its behavior for this particular user accordingly. Consequently, cookies can be long and encode a lot of information. Furthermore, cookies can be encrypted. In this case, the key needed to encrypt and decrypt the cookies must be known only be the Web server. This simplifies key management considerably.

In either case, cookies can be used to track the path of a user when he or she browses through a Web site (they have been designed for this purpose) or a collection of Web sites. ^[9] Users may object to this behavior as an intrusive accumulation of private information, even if their identities may not be evident. ^[10] Consequently, a user should be able to enable or disable the HTTP state management mechanism, and to either reject or refuse the use of cookies accordingly. This is possible in all major browsers in use today. For example, Figure 12.2 illustrates the Microsoft Internet Explorer s Security Settings menu that can be used to enable or disable cookies. There is made a distinction between persistent cookies (i.e., cookies that are stored in a specific file) and transient cookies (i.e., cookies that only live for the ongoing session and that are not stored in a file). This distinction is not necessarily made by all browsers. In Figure 12.2, both types of cookies are enabled by the current user. Similarly, Figure 12.3 illustrates the Preferences menu of the Opera browser. In the Privacy section of this menu, there is a Cookies panel that can be used to customize the use of cookies.

Figure 12.2: Microsoft Internet Explorer s Security Settings menu to enable or disable cookies. ( 2002 Microsoft Corporation.)

Figure 12.3: Opera s Preferences menu to configure the use of cookies. ( 2002 Opera Software).

If a browser does not allow a user to disable cookies, it is always possible to periodically delete the file in which the cookies are stored. For example, on a UNIX system, the browser can be prevented from storing and saving cookies by replacing the cookies file with a link to /dev/null. Similarly, on Windows and Macintosh systems, there are commercial programs that promise to sweep cookie files clear.

Note that the HTTP state management mechanism and the corresponding cookies are designed to maintain state information between two endpoints of an HTTP session (i.e., a browser and a Web server). They cannot be used for storing state information between the browser and a proxy server, or between different proxy servers in a proxy chain. ^[11]

Also note that there are other technologies that may compromise the privacy of users (in addition to cookies). For example, Web bugs ^[12] are very small images placed on Web pages or e-mail messages to facilitate third-party tracking of users and collection of statistics. In fact, a typical Web bug consists of a 1-pixel-by-1-pixel transparent GIF image. To detect it, one must view the source of the Web page or e-mail message. Note what happens if the following HTML statement is included in a Web page or e-mail message:

< img src="http://www.esecurity.ch/tracking.gif" width=1 height=1 border=0 >

If a browser renders the Web page or an HTML-enabled user agent displays the e-mail message, the image tracking.gif is retrieved from http://www.esecurity.ch and is displayed in a pixel. As such, the image is invisible to the unassisted eye and it usually goes unnoticed (unless one looks at the source). Because the browser or user agent retrieves the image from http://www.esecurity.ch, the Web server writes a corresponding entry in its log file. Consequently, the Web server s log file reveals who and from where the image file was retrieved.

^[9] In the second case, a third-party tracking service must be used. Such services are provides by companies like DoubleClick, Inc. ( http://www.doubleclick.com).

^[10] Identities may be evident if users fill out forms that contain identifying information.

^[11] Note that a common way to use (or misuse) cookies is to store authentication information so that a reauthentication does not have to occur every time in future requests , but the appropriate authentication information is directly available in a corresponding cookie. To prevent spoofing attacks in this setting, it is common practice to encode, not just the username into the cookie, but also the IP address where the first request came from. Now consider the case in which the route to the server is dynamically changing in a way that a request is not guaranteed to come from the same IP address (of the proxy server) as the earlier request. In this case, the cookie may be rendered invalid. In this situation, a feature to support proxy cookies would be useful [10]. Such a feature will hopefully emerge at some later point in time (obviously, the more secure approach is not to store any static authentication information in a cache in the first place).

^[12] The term Web bugs was coined by the Privacy Foundation ( http://www.privacyfoundation.org ) that released a corresponding report in September 2000.