I’ve been on the Internet for a while, so it didn’t surprise me when I retrieved email for the webmaster address of one of my clients and had a message waiting with shouting, capital letters.
"STOP ALL THE COOKIES!!! Email me when you take out some of them, and then I and everyone else I told not to got to this site might come back."
If you’re not familiar with the term, a "cookie" or "magic cookie" is a short stream of text that a Web server can send to your Web browser. Once the text is received, your browser stores that information in a special file called "MagicCookie" or "Cookie" or "cookie.txt" (depending on your computer and software configuration – Microsoft Internet Explorer 4.0 for Windows, for example, stores cookie information as individual files in the "\Windows\Temporary Internet Files\" directory.
Exciting, isn’t it? Isn’t your anger just boiling from the knowledge that hundreds of other sites are sending and receiving information via your Web browser? The nerve! How dare they?
The Path to Web Nirvana Is Paved with… Cookies? If you’ve been to a site that gives you the ability to customize the information on its main pages, most likely you’ve run across one or more cookies. Yahoo’s personal news service My Yahoo is a good example: after choosing to create a new account by supplying a user name and a password, Yahoo’s Web server adds some information to your cookie file that assigns an identification number representing your Web browser.
Here’s how cookies work. During every Web transaction, your Web browser sends a small number of HTTP (HyperText Transfer Protocol) headers, identifying what kind of software it is, the version number of HTTP it understands (most know version 1.1), and what page or file it wants. The Web server to which you’re connecting responds by sending back a number of headers, including one that defines what kind of document is being returned – an image in GIF format or text in HTML, for instance. The server then follows those headers with the actual data of the Web page.
To change the data in your cookie file, the Web server sends a Set-Cookie header as part of its transaction with the Web browser. When you set up a My Yahoo account, the page that is retrieved contains a line that might look something like this fabricated example.
Set-Cookie: id="343a432h"; expires="01-Dec-98 GMT"; path="/"; domain="my.yahoo.com"
The first part is the cookie name ("id") and its value ("343a542h"). The expires attribute defines when the cookie should be deleted from your cookie file. The path and domain indicate that the Web browser should retrieve only this cookie when the browser is accessing "my.yahoo.com," but it doesn’t matter where on the site. If the cookie should be retrieved only when you’re in the "/antimatter/" subdirectory, the Set-Cookie header would also include path="/antimatter/" in it. Alternately, if the domain was set to just ".yahoo.com", visiting any machine in the Yahoo domain would trigger the cookie being sent.
The next time you go to My Yahoo, your browser automatically sends a Cookie header to the server that contains your ID code. The Cookie header might look like this:
There can be as many of these cookie headers as there are cookies for the site. The server checks for your id number, retrieves your record, and then sends the customized page to your browser.
It’s important to note that cookies are kept with a specific Web browser on a specific machine. If you use several different browsers on more than one machine, as I do, My Yahoo will not recognize you when you switch browsers or machines, because each browser uses its own cookie file. There’s currently no built-in or simple way either to share your cookies among all the machines and browsers you work with, or to limit access to your cookies if multiple people use the same machine. (I’ll mention some add-on solutions later, though.)
You’re a "Unique Visitor" Here — Many tracking software packages, such as Microsoft Usage Analyst (part of Microsoft BackOffice), have a server-side module that causes the server to try to set a unique visitor ID when a user visits any page on a site – unless they already have one set on that visit or a previous one. (Some servers come with this ability built in, like the Apache Web server). Most Web servers can also be configured to record the cookies sent by a browser for a specific request to the site.
This means that the log for the server contains the page request, the datestamp, and the unique visitor identity for each hit on the site. The logs grow huge, but they also enable site owners to identify the number of individual Web browsers – and by extension, the approximate number of different people – that have visited a site in a given period of time.
If the server can’t set a unique visitor cookie – or the user rejects it through one of the methods described below – the tracking and analysis software must rely on visitors’ IP addresses to determine uniqueness, which isn’t as accurate in cases of multiple users sharing the same IP address (such as dynamic addressing and AOL gateways).
If I were to stop here, your impression of cookies would most likely be favorable: cookies add functionality, both for site producers (tracking) and visitors (personalized environments). But that still doesn’t explain why I received the SCREAMING EMAIL!!!
Following the Crumbs Straight to Hell? People have problems with cookie use primarily in regard to privacy. It’s already fairly easy to find someone’s email address using address-grabbing robots in Usenet groups or even some free white-pages directories on the Web. What happens if any Web site you visit can grab your personal information?
Fortunately, there are ways to prevent such unauthorized intrusions. If a site’s cookie behaves correctly, it won’t write any personal information to your cookie file (such as a name or password to the site), or it will encrypt such information so that it can only be read by the server. Because a site is limited to 20 cookies each, which individually can use no more than 4,096 characters, there isn’t room to store much sensitive information. (Netscape’s cookie specification says that browsers should store a maximum of 300 cookies, then start deleting the oldest ones.)
In most cases, a cookie entry will contain nothing more than an ID number and a time stamp. To view the contents of your cookie file, open it with any text editor or word processor. You can often open it in your Web browser, which will display it as a text file. In the case of Microsoft Internet Explorer, the only way you can easily view cookies and their contents through the Preferences dialog box by selecting "Cookies."
Another method of ensuring privacy is that a cookie always specifies its originating domain name; if it’s omitted, the machine that sent it is dropped in by default. If you’ve visited nefariouscookies.com, your browser will only reply to a request for that information from nefariouscookies.com. As noted above, a cookie can be set for an entire domain (like any machine that has yahoo.com at the end of it) or for just one machine (like my.yahoo.com).
What seems to make most people uncomfortable, however, is the capability of having their movements on the Web tracked using cookies. I’ve heard analogies made that being tracked by cookies is like having an employee of your favorite bookstore (for example) walk around and note everything that you’ve picked up or grabbed for purchase.
What Can You Do? In my opinion, the biggest problem with cookies right now is that they work in the shadows. Netscape Navigator and Microsoft Internet Explorer default to accept all cookies automatically, so you may not even realize all this is happening. The most recent versions of these browsers offer several configuration options, such as rejecting all cookies, or prompting to accept or decline each cookie. Microsoft added an option in just the Macintosh 4.0 preview release that allows you to approve all cookies for a given site when you receive the first cookie from that location.
At first, I configured my browser to ask me before accepting any cookie. This was good for curiosity’s sake, but I quickly tired of sifting through the number of requests being made to my browser and shut off the option.
On my ever-expanding list of wishes for Web browsers (such as smaller RAM footprints and universal compatibility of HTML tags, for example), I’ve added the capability to be able to tell quickly and easily what a given cookie plans to do. In the meantime, you can choose among several different ways to block access to your cookie file entirely. You can delete your cookie file each time you use your computer. Or, you can lock your cookie file so that nothing can write to it. You can also use any of a dozen-plus freeware and shareware applications for Windows and Macintosh. (I’ve referenced the comprehensive pages at Cookie Central for these files. The first is for PCs; the second for Macs.)
[Jeff Carlson is the managing editor of NetBITS and TidBITS. This article is adapted from "The Cookie Monster," which originally appeared under his byline in the 15-Feb-97 issue of adobe.mag. Adapted with permission from Adobe Systems, Inc. NetBITS editor in chief Glenn Fleishman also contributed substantially to this article.]