Get notifications!

Lately there's been great hysteria and mania on what seems like every tech news site about the hidden dangers and scariness of the evil menacing cookies. As you might expect, these people almost alway get it wrong and people get their panties in a bunch over the misinformation spread by the media and other ill-informed, self-proclaimed experts.

What it is

It's quite easy to state what a cookie is: it is a piece of information that a web server (eg, "morons.org") requests your web browser to retain and transmit it back the next time it makes a request. It's a convenient way to handle variables that can make a site more interactive or easy to implement; one can store a customer ID, for example, or a session ID, or a list of things in a shopping cart, etc. Morons.org uses a cookie to store a user's style sheet preference so the next time the user comes to the site, the preference is recalled.

Cookies have a number of attributes, but not all of them have to be specified. You have to at least store name=value. For example, you can set a cookie that contains simple "FirstName=Gorthak". This simple case is a cookie that will get sent back only to the requesting server for any page on that server until the web browser is closed.

Sometimes it is desirable to keep a cookie longer than that, however, so it is possible to also save an expiration time. This is done by setting "expires=DATE" and giving DATE in the format Wdy, DD-Mon-YYYY HH:MM:SS GMT. For example, Thu, 17-Dec-2009 21:30:00 GMT. Setting an expire date will cause the browser to keep sending this cookie until the expire date is reached. You can force a cookie to delete sooner than that by sending an expire date in the past; for example, Thu, 1-Jan-1970 00:00:00 GMT.

In many cases, it is desired to limit the number of cookies that have to be sent back to a certain part of the site, or to set the same cookie to different values depending on the part of the site. For this, the "path" variable may be set. By default, the path is usually set to "/", which means the cookie will be sent back for every page on the web server (since everything falls under the "/" directory). If one wants to restrict a cookie to be sent back only for something in the /images hirerarchy, the path can be set as "path=/images". Then /images/foo.gif, /images/naked/bar.gif, etc will cause the cookie to be sent back.

It can also be handy to share cookies among domains. For example, morons.org can be accessed as "morons.org" or "www.morons.org". Although we're too lazy to implement this now, we could set our domain in our cookies to "morons.org" and share the same set of cookies to both names. The reason is that cookies are matched from the tail; with a domain of morons.org, anything ending in the domain morons.org matches. This is especially handy if you want to share a cookie among several web servers if you spread your images, text, multimedia, and so-on across several hosts.

Finally, one can set the "secure" attribute of a cookie, which means the cookie will only be sent back if it is sent across a secure, encrypted channel.

How it can be abused

I've mentioned a few ways that cookies can be used. As with most things on the Internet and in the real world, tools can be used or abused. A chisel can be used to create a beautiful sculpture or stab someone through the heart. Cookies are no exception.

It is not reasonable or necessary to be afraid of all cookies. All cookies are not doing the devil's work on your hard-drive and tracking your spending habits to be reported to the CIA. In general, cookies sent to your machine from the site you're browsing that will be sent back to the site you're browsing are totally harmless. The site operator can't tell anything more about you than he could from his web logs. This is because he only gets back information that he stored in the first place. Let me say this again, because it is important to remember: cookies being sent from the site you're browsing that will only be sent back to the domain of the site you're browsing are generally harmless because the operator only gets back information he stored himself. This is the technique used on morons.org.

Slightly more hazardous are cookies with a different domain set. You might be thinking, "why would anyone ever want to send a cookie to a domain other than that of the web site I'm browsing?" There are legitimate uses of this technique. For example, a family of web sites may want to have a single logon served by another domain. In this example, say mail.morons.org uses a logon server called login.morons.org. When I go to mail.morons.org and I'm not logged in, it redirects me to login.morons.org. login.morons.org then sets a cookie when I've logged in that will be sent back to mail.morons.org and sends me back. Now mail.morons.org sees that cookie is there and lets me on. This is just one example. There are a number of legitimate uses for this capability.

Note that you cannot set a cookie for a domain other than the one you belong to; that is, www.morons.org may set a cookie in the morons.org domain, but not the spatula.net domain. Similarly, you can't set a cookie for a path you don't belong to; something in /images may set a cookie for /images, /, or /images/naked, but not for /sheep or /sheep/wooly.

The legitimate privacy concern with respect to cookies is mostly related to ad banners. Since ad banners are served out with HTTP, the server sending the banner may set cookies on your browser as well. So say you're browsing on morons.org, and there's an image tag telling the browser to go grab a banner from ads.spatula.net. Your browser likely has automatic image loading turned on, so it connects to ads.spatula.net and downloads the image. Loading images from other sites is a common practice, especially with ad banners.

Now suppose we run an ad banner company, and we have contracts with Foo Industries, a company that home delivers groceries, Bar Incorporated, who sells home lobotomy kits, and Baz Ltd, a porn site. Somewhere on each of these sites, they have an IMG tag pointing to our server to include a random ad banner of our choosing.

Rev. Milhouse V Farquar fires up his browser, and 10 minutes later comes back to see that it's finally loaded up so he can go buy one of those great lobotomy kits for himself. His browser downloads the web page that contains our banner ad, so it connects to our server to get the ad. We set a cookie that says "Bar-Incorporated". Farquar decides the prices on lobotomies are really too high, and wonders if he can't get the same effect by listening to the Carpenters... or maybe looking at some Live Nude Girls...

After looking over his shoulder to make sure his wife isn't looking, the Reverend loads up the Baz Ltd porn site, hoping to see some Cum Guzzling Lesbians. Instead, he gets a page full of banner ads, and one of them is ours. His browser sees that it has a cookie for us! It sends back, "Bar-Incorporated" when it asks for an ad banner. We make a note of this in our statistics, set a cookie that says "Baz-Ltd" and send him the GIF of a hot young man with a large zucchini in his nether-region. Now we know that the good Reverend was looking at Bar Incorporated before he went to see the nekkidness.

The zucchini really got Milhouse hungry, so he clicks over to Foo Industries. Of course, since he was on a porn site, about 30 browser windows pop up that he can't get rid of easily. Eventually he gets them to go away and loads up the Foo Industries page, which has one of our ad banners on it! Once again, his browser auto-loads the image, notices it has cookies for us, and tells our server it has a cookie that says "Bar-Incorporated" and one that says "Baz-Ltd". We note this in our statistics and set a cookie that says "Foo-Industries".

Of course, this is a really simple example. In reality, we could keep a running count of how many times a person had been to a site, how much time they spent there (by storing timestamps and subtracting them), and so-on. We still can't get back any information that we didn't store though; we don't know Rev. Farquar's name, address, penis length, etc. We can track his progress through sites that get advertising from us only.

To many people, this is obnoxious, and we don't want people correlating our trip to a porn site with our quest for groceries, whether or not they know our names. This is not a reason to declare cookies to be pure evil and break out in hysterics. Sure it's easier, especially considering how long it can take to explain cookies in a calm, level-headed manner in such a way that people can understand what's going on.

Perhaps the best compromise, and the one I use myself, is to allow cookies that will be sent back to the originating site that came from the originating site only. In Netscape 4, select "Preferences" from the Edit menu, click on "Advanced" and select "Only accept cookies originating from the same server as the page being viewed". In Mozilla, select "Preferences" from the Edit menu, open the "Privacy and Security" menu, click on "Cookies" and select "Enable cookies for the originating web site only". Internet Explorer does not offer this option at all, but you can get it to prompt you to allow a cookie or not.

For more information about cookies, see RFC 2109.