Cookies can be stored in a couple of different places. In Netscape, there's a file named cookies.txt which contains all the cookies on your system. Internet Explorer maintains a folder named (predictably enough) "cookies." This is where you'll find all the information stored by the cookies you receive. You should never have to purge this file or touch it in any way - really. Your browser knows when it has more cookies than it can handle, and will silently begin to delete the older ones when the time comes.
But if you're the curious type, you may want to go poking through the cookie file anyhow, just to see what kinds of cookies you're receiving and why. In that case, a cursory knowledge of cookie properties will help you decode your cookie file:
A cookie is always associated with a specific domain. Let's use the domain digitalphenomena.me.uk for an example. If you visit Webmonkey, you may receive a cookie, which will be stored on your hard drive until the next time you visit Webmonkey. But your browser will only return this cookie information to the domain where the cookie originated (in this case, webmonkey.com). No other site can request it. This way, the Internet doesn't get clogged with cookies that are returned to "nowhere in particular."
Some cookies have expiration dates. When a cookie expires, your browser will simply erase it from your hard drive. Depending on where it came from, a cookie may expire tomorrow, next week, or the year 2000. Cookies with an expiration date are generally known as "persistent cookies," meaning they stick around for a while. A cookie that doesn't contain an expiration date will only last as long as your browser stays open. These are called "session cookies." When you close your browser, all session cookies silently disappear.
The real meat of cookie data is stored in a series of name=value pairs. The rest of the data just helps with delivery; the name=value pairs are where cookie-producing CGI scripts actually store information that will later be transferred when you return to a site. This information can be any number of things: items you have placed in your shopping cart at an online catalog, a username and password for a "members only" Web site, a unique tracking number, etc.
Every cookie has a directory path on the Web site that tells where it was set. A different path can tell your browser to send a different set of variables, even on the same site.
When to toss your cookies
In general, cookies are harmless. I recommend keeping them and turning off the "Always confirm before setting a cookie" feature in your browser. Cookies are so popular these days (some sites will set several cookies on each page!) that it's really annoying to confirm each and every cookie you receive. Many sites won't work properly without cookies.
There may be certain cases when you'll want to reject cookies, but these probably don't come up that often. Let's say you're visiting a site using a browser that isn't on your own personal machine - like a public terminal, or your boss's machine at work (you sneaky devil). In that case, you might not want a record of your shopping cart, or the sites that you visit, to be kept around where anyone can look at them. Since the browser saves a copy of the cookie's information to your local hard drive, it leaves a record that anyone can rifle through if they have the inclination.
Another thing to think about is the rare case when some secret or valuable piece of information is being transferred via a cookie. I'm not talking about that pair of shoes you bought at neimanmarcus.com. Some of the more advanced Web sites will actually do login authentication through HTTP cookies. In this case, you may want to make sure the cookies you are served encrypt your password before reflecting that information back across the Net to your personal browser.
For sensitive information, use the golden rule: If everyone can see what's being sent, then anyone can find that information by looking at your cookie file or by filtering through the traffic in your vicinity on the Net. However, if the information is encrypted (that is, you can't actually read your password by looking in your cookie file), then it's probably OK.
If, for some reason, your cookie file is lost or deleted, don't fret - not much is lost. The next time you visit your favorite CD retail site, however, you may notice that it no longer "knows" you've been there before.
Cookies can be set with any scripting language. The same thing can be accomplished with ASP, ColdFuion, Perl, and PHP.
