Cookies explained by InfoWorld's Help Desk

Rohit Khare (
Mon, 15 Jul 96 22:06:08 -0400

Again, a reprint of what the media is telling users. This is pretty balanced
stuff... kudos to Brett Glass's Help Desk column. no mention of this group's
work, to be sure, but it's not like we've put the W3C press machine in high
gear on this issue :-)



July 15, 1996

`Cookies' won't spoil your diet but might hurt Web security

Q: I understand that there's a browser feature called a "cookie" that will
let anyone with a Web site store information on our company's computers. I'm
concerned that this could compromise our employees' privacy and security when
they browse the Web. Is this feature dangerous? How do I turn it off?
Gilles Marceau

A: "Cookies" do allow a Web server to store information on your company's
computers. And, yes, they can be used for nefarious purposes. But if you
understand what they're for and how they work, you may feel more at ease with
the concept.

On the World Wide Web, each exchange of information between a browser and a
server (called a "hit") is independent of every other. The connection doesn't
remain open between hits, and there's no guarantee that another one will ever
be established. (For example, if your browser receives a Web page containing a
form, the server doesn't know if you will complete the form or jump to a
completely different Web site.)

However, it's often useful for the server to maintain state information
within a conversation that consists of a series of hits. (For example, if
you're filling out a questionnaire, subsequent questions might depend on your
answers to previous ones.) The server could keep track of every client, but
this isn't practical. If it's a popular machine, it could be getting dozens of
hits every second from all over the Web! Also, the server can't know how long
to retain information about each session. (You might walk away in the middle
to find a document or go to lunch expecting to finish later.) Therefore, the
best answer is to distribute the storage burden among the clients. This is
typically done in two ways. The most common, because it works with virtually
all browsers, is for the server to save information from previous hits in
"hidden" fields on forms it sends you. The information is returned when you
submit the next form, bringing some continuity to the conversation.

The other way -- which doesn't work with many browsers other than Netscape
and Internet Explorer -- is a cookie. A cookie isn't associated with a
specific form but with a client/server pair. The server can store as many as
20 cookies, which look like DOS environment variables as long as 4KB, on the
client. It gets its cookie(s) back whenever the client accesses part or all of
a given Web site.

Are cookies dangerous? That depends on how they're used. A browser limits the
number of cookies it will retain and stores them on a first-in/first-out
basis or until an expiration date, so there's no danger of overflowing your
hard disk. And unless you're running JavaScript, the cookie can contain only
information that the server already has about the client. But JavaScript does
have a limited capability to put information into cookies -- for instance, a
user's e-mail address. So, if you don't want such information propagated
without your knowledge, turn off JavaScript. And because cookies are passed in
HTTP headers, they can be used to identify individual users, even through a
proxy server or firewall. If this is a concern, use a browser without them.

Browser vendors should let users turn cookies off, view the cookie database,
and see the information that's being stored and retrieved in a dialog box as
it happens. Then cookies will be a fine way to deal with the "stateless"
architecture of the Web.

For more information, see _ To find out
which browsers support cookies, see