Other information on Cookies
More Information Below
Karl Note On Cookies
[Back to Cookie Central]
A Note from the Author
Whew! After a long delay, I am returning to the FAQ. A lot of information has been out-of-date for some time, so I felt I had to at least get us back in place.
I have noticed a growing number of sites out there that have copied all or part of my FAQ. While I should be angered at what is clearly a violation of copyright, I'll choose to be understanding and a little flattered. Honestly, people, you could at least mention that it's my work, you know. Or, you could at least link back to Cookie Central, who provides space for the FAQ free of charge.
It's things like this, and the waning interest in the cookie issue (which I feel I've done my part to help), that leads me to think that this will be the last update to the FAQ. I nearly pulled it down a year ago, but the owner of Cookie Central prevailed upon me to keep it live.
In the past five-and-a-half years, I've been able to watch cookies grow from a fledgling concept to the most important part of the internet experience. Cookies have brought personalization, commerce, and convenience to the internet, legitimizing it as a place for business, not just for science or personal home pages.
I've seen the FAQ grow as well over that time. The first draft of the FAQ was written to target developers who were trying to understand what cookies were and how they could use them. To this day, I see my examples put to use all over the internet. But the FAQ served better by informing everyday people about cookies and how they really work. I hope I've done my part to cure the hysteria.
So, I bid the FAQ good-bye. Thanks to all of you in the past who have contributed ideas, feedback, questions, and complaints. You all made a difference.
And thanks for stopping by!
[Back to Top]
Cookies are a very important method for
maintaining state on the Web. "State" in this case refers to an
application's ability to work interactively with a user,
remembering all data since the application started, and
differentiating between users and their individual data sets.
An analogy I like to use is a laundry cleaner's shop. You drop something off, and get a ticket. When you return with the ticket, you get your clothes back. If you don't have the ticket, then the laundry man doesn't know which clothes are yours. In fact, he won't be able to tell whether you are there to pick up clothes, or a brand new customer. As such, the ticket is critical to maintaining state between you and the laundry man.
Unfortunately, HTTP is a "stateless" protocol. This means that each visit to a site (or even clicks within a site) is seen by the server as the first visit by the user. In essence, the server "forgets" everything after each request, unless it can somehow mark a visitor (that is, hand him a "laundry ticket") to help it remember. Cookies can accomplish this.
What is a Cookie?
A cookie is a text-only string that gets entered into the memory of your browser. This value of a variable that a website sets. If the lifetime of this value is set to be longer than the time you spend at that site, then this string is saved to file for future reference.
Where did the term cookies come from?
According to an article written
by Paul Bonner for Builder.Com on 11/18/1997:
"Lou Montulli, currently the protocols manager in Netscape's client product division, wrote the cookies specification for Navigator 1.0, the first browser to use the technology. Montulli says there's nothing particularly amusing about the origin of the name: 'A cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary. The term fits the usage precisely; it's just not a well-known term outside of computer science circles.'"
Where Can I Get More Information?
Cookie Central is dedicated to answering questions about cookies. Feel free to look around.
There's a great article concerning cookies on Marshall Brain's "How Stuff Works". It goes even deeper than this FAQ does, especially in the realm of public opinion. Worth a look!
The World Wide Web Consortium has an excellent FAQ to answer the majority of Internet and Web-related questions. You can read their topic: "Do 'Cookies' Pose any Security Risks?"
In addition, there are an abundance of resources on the Internet that can help you find answers to your cookie questions. Conveniently, Yahoo has a great listing of them. I encourage you to stop by and check the list out!
This section is devoted to general questions on cookies and their usage. 2.2 Can I delete cookies?
Yes. Whether you use Internet Explorer or Netscape, your cookies are saved to a simple text file that you can delete as you please.
In order to do this properly, remember to close your browser first. This is because all your cookies are held in memory until you close your browser. So, if you delete the file with your browser open, it will make a new file when you close it, and your cookies will be back.
Remember that deleting your cookie file entirely will cause you to "start from scratch" with every web site you usually visit. So, it may be preferable to open the cookies.txt file (in the case of Netscape) and remove only the entries you don't like, or go to the cookies folder (in the case of IE) and delete the files matching servers you don't want. 2.3 How do I set my browser to reject cookies?
Both Internet Explorer and Netscape allow some level of cookie verification. They both have menu options that allow you to accept all, some, or none of your incoming cookies. In addition, the "warn before accepting" feature is present in both, if you want to screen your incoming cookies.
In Netscape, go to the Edit/Preferences/Advanced menu. Your cookie choices can be changed there.
Microsoft has changed their approach to cookies over the last 3 versions of their browser. This is a reflection of how cookies have been thrust into the limelight of privacy on the Internet:
Are Cookies Dangerous to My Computer?
NO. A cookie is a simple piece of text. It is not a program, or a plug-in. It cannot be used as a virus, and it cannot access your hard drive. Your browser (not a programmer) can save cookie values to your hard disk if it needs to, but that is the limit of the effect on your system.
Will cookies fill up my hard drive?
Both Netscape and Microsoft have measures in place that limit the number of cookies that will be saved on your hard drive at one time.
Both Internet Explorer and Netscape conform to the RFC 2109 limitations on your total cookie count to 300 (this includes a limit of 20 cookies per individual domain). If you exceed this, the browser will discard your least-used cookies to make room for the new ones.
Microsoft saves cookies into the "Temporary Internet Files" folder, a system folder that you can set the maximum size of (the default is 2% of your hard drive).
In any event, remember that most cookie files are 4KB or smaller, so you would need about a million cookies to fill up a 4GB drive. This is incredibly unlikely.
Are Cookies a Threat to My Privacy?
The sad truth is that revealing any kind of personal information opens the door for that information to be spread.
Consider the growing trend of technology conveniences in our lives. We use "frequent buyer" cards at supermarkets and gas stations. We place electronic tags on our cars to pay tolls faster and easier. We let banks pay our bills for us automatically each month without checks.
While each of these technologies (and others like them) have made our lives more convenient, each time we use them exposes us to a loss of privacy. Stores know what foods you eat. Gas stations know how much you spend on gas per fill-up. Turnpike operators know how fast you drive on their highways. Banks know how you spend your money each month.
It's the same with cookies. In fact, one may argue that cookies in the long-run will be less damaging to privacy efforts than those technologies described above. If you're going to single-out cookies as your sole vulnerability to personal privacy, you should re-examine how you live your daily life.
The never-ending ethical debate associated with these facts shall be left to other forums. However, it is wise to consider carefully the information you collect and share over the Internet.
Sites are telling me I need to turn on cookies, but they are on. What's wrong?
There are three likely possibilities for problems like this. Firstly, the site you are visiting may be detecting cookies improperly. As a result, it may appear to the site that you are rejecting cookies when in fact you are not.
Another possibility is that you may be running software that interferes with cookie usage. There are many filtering and blocking software packages available for Internet users these days, and many of them also filter cookies. If you are running software like this, then your computer may not receive or send cookies. This will cause sites you visit to assume you are not accepting cookies.
Finally, your machine may be behind a firewall or proxy server that prevents cookie transmission. This is most likely in a corporate environment. So, regardless of how your browser is set, cookies won't be sent or received by your browser. Since the cookies aren't making it through to your browser, the Web Site will assume you personally aren't accepting them.
deleted my cookies, and I can't log-on to my favorite site
anymore. What can I do?
Many sites use a cookie to keep track of your settings on their servers, and to help you log in to their site. If you lose your cookie, that site cannot recall your settings for you to use.
If this happens to you, the best thing you can do is contact that site's webmaster or customer service department.
How did I get a cookie from doubleclick? I've never been there!
In section 3.3, we'll see that a server cannot set a cookie for a domain that it isn't a member of. However, almost every Web user has gotten a cookie from "ad.doubleclick.net" at one time or another, without ever visiting there. DoubleClick and other advertisers have employed a clever solution that enables them to track users and serve media content without violating this rule.
Most sites on the Internet do not keep their advertisements locally. Rather, they subscribe to a media service that places those ads for them. This is accomplished via a simple HTML call to the media service. When a page is requested, it is assembled through many HTTP requests by the browser. First, there is a request for the HTML itself. Then, everything the HTML needs is requested, including images, sounds, and plug-ins.
The call to the media service is an HTTP request for an image. Once the request is made to the media service, it can return more than just an ad. It can also return a cookie. Or, if is has given the user a cookie previously, it can read that first, and check to see what ad to send. The net result is that the user gets a cookie from the media service without ever having visited it.
This usage of cookies is the most controversial, and has led to the polarized opinions on cookies, privacy, and the Internet.
I looked at my Internet Explorer cookies, and they had my username on them! Can servers see my username?
Because Windows systems allow more than one user to login and use programs, Microsoft had to come up with a way to keep each user's cookies separate on a given machine. This can be common in workplaces, where a single machine is shared by many employees.
This is accomplished by appending the username to the cookie file name. This way, both Jane Doe and Joe Smith can get cookies from coolsite.com and they don't get over-written. Also, this stop's Jane from using Joe's cookies while she's surfing, since the browser will only use her cookies when she is logged in. That is, the cookie file:
Doe's cookie for coolsite.com. If anyone else logs-in, then this
cookie is not used.
This is the only reason that the username is part of the cookie file name. The username does not get sent to the server with the cookie data.
There are two extra files in my Cookies folder called Mm256.dat
and Mm2048.dat. What are they?
You can read more about this on Microsoft's Knowledge Base.
Whether you're a programmer or just a web user looking for answers, a big part of understanding cookies is to go into the gory details. This section does just that.
How does a cookie really work?
Understanding how cookies really work requires an understanding of how HTTP works. Cookies transport from Server to Client and back as an HTTP header. The specifications for this header are explicitly laid out in RFC 2109.
When a cookie is sent from the server to the browser, an additional line is added to the HTTP headers (example):
Content-type: text/html Set-Cookie: foo=bar; path=/;
expires Mon, 09-Dec-2002 13:46:00 GMT
entry would result in a cookie named foo. The value of foo is
bar. In addition, this cookie has a path of /, meaning that it
is valid for the entire site, and it has an expiration date of
Dec 9, 2002 at 1:46pm Greenwich Mean Time (or Universal Time).
Provided the browser can understand this header, the cookie will
When a cookie is sent from the browser to the server, the cookie header is changed slightly:
Content-type: text/html Cookie: foo=bar
Here, the server is made aware of a cookie called foo, whose value is bar.
Breakdown of Cookie Parameters
As we have just seen, a cookie contains more than simply a name and a value. In fact, a cookie has 6 parameters that can be passed to it:
Two of these are mandatory (its name and
its value). The other four can be set manually or automatically.
Each parameter is separated by a semicolon when set explicitly.
Here is a detailed description of each.
The name of a cookie and its value are set simply by pairing them together:
... foo=bar ...The value of a cookie can also be null, for the purpose of clearing the cookie value:
... foo= ...
The expires parameter lets you determine the lifetime of the cookie.
... expires=Mon, 01-Jan-2001 00:00:00 GMT ...
If Expires is not set explicitly, then it defaults to end-of-session. The
length of a session can vary depending on browsers and servers,
but generally a session is the length of time that the browser
is open for (even if the user is no longer at that site).
The path parameter is potentially the most useful of the 4 optional cookie settings. It sets the URL path the cookie is valid within. Pages outside of that path cannot read or use the cookie.
... path=/promo ...
If Path is not set explicitly, then it defaults to the URL path of the
document creating the cookie.
Netscape has identified a bug for VERY old versions of Navigator where the path must be specified if an expiration is specified. Furthermore, this path must be set to "/". For more information, browse Netscape's Cookie Spec at:
The domain parameter takes the flexibility of the path parameter one step further. If a site uses multiple servers within a domain the it is important to make the cookie accessible to pages on any of these servers.
... domain=www.myserver.com ...
Cookies can be
assigned to individual machines, or to an entire Internet
domain. The only restrictions on this value is that it must
contain at least two dots (.myserver.com, not myserver.com) for
the normal top-level domains, or three dots for the "extended"
domains (.myserver.ny.us, not myserver.ny.us)
IMPORTANT: The server issuing the cookie must be a member of the domain that it tries to set in the cookie. That is, a server called www.myserver.com cannot set a cookie for the domain www.yourserver.com. The security implications should be obvious.
If Domain is not set explicitly, then it defaults to the full domain of the document creating the cookie.
The secure parameter is a flag indicating that a cookie should only be used under a secure server condition, such as SSL. Since most sites do not require secure connections, this defaults to FALSE.
How do cookies end up on my hard drive?
After a cookie is transmitted through an HTTP header, it is stored in the memory of your browser. This way the information is quickly and readily available without re-transmission. As we have seen, however, it is possible for the lifetime of a cookie to greatly exceed the amount of time the browser will be open.
In such cases, the browser must have a way of saving the cookie when you are not browsing, or when your computer is shut off. The only way the browser can do this is to move the cookies from memory into the hard drive. This way, when you start your browser a few days later, you still have the cookies you had previously.
The browser is constantly performing maintenance on its cookies. Every time you open your browser, your cookies are read in from disk, and every time you close your browser, your cookies are re-saved to disk. As a cookie expires, it is discarded from memory and it is no longer saved to the hard drive.
What are all those entries in my cookies.txt file?
The layout of Netscape's cookies.txt file is such that each line contains one name-value pair. An example cookies.txt file may have an entry that looks like this:
.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID 100103
represents a single piece of stored information. A tab is
inserted between each of the fields.
From left-to-right, here is what each field represents:
domain - The domain that created AND that can read the variable.
flag - A TRUE/FALSE value indicating if all machines within a given domain can access the variable. This value is set automatically by the browser, depending on the value you set for domain.
path - The path within the domain that the variable is valid for.
secure - A TRUE/FALSE value indicating if a secure connection with the domain is needed to access the variable.
expiration - The UNIX time that the variable will expire on. UNIX time is defined as the number of seconds since Jan 1, 1970 00:00:00 GMT.
name - The name of the variable.
value - The value of the variable.
Where does MSIE keep its cookies?
Microsoft keeps its cookies in different locations, depending on the version of explorer and Windows you are using. The best way to find it is to use the Windows "Search" feature an look for the "Cookies" folder. More information can be found here.
Although the location may be different, the format is the same. Each individual domain's cookies are stored in their own file, along with the username that accessed the site. For example, if I went to Yahoo.com, I would get a cookie that is stored in the file email@example.com.
Note that the username is not sent with the cookie.
See Section 2.10 for more information.
Are cookies Year 2000 Compliant?
There is no date-specific restriction on the HTTP header used to transmit cookies. In fact, the only determining factor in whether a cookie will be accepted is the programming of the client receiving the cookie.
The major browsers do not have an issue with this. Cookies with expiration dates set with 2-digit or 4-digit years are understood properly. Naturally, it's always advisable to use 4-digit years when setting cookies.
This section covers topics beyond those discussed above.
Creating a Cookie Value
Creating a cookie generally involves duplicating the HTTP cookie header in some fashion so that the browser will store the name-value pair in memory. Some languages expect an exact HTTP header to be sent, while others will use built-in functions to help you speed the process along.
Cookies can be set from the browser-side or from the server-side. The determining factor will be the language you use to create the cookie. Once the cookie is created, it should flow easily from server to client and back via the HTTP headers.
There are limits on the contents of both the cookie string and the cookie file. These limits are partially imposed by HTTP and partially by arbitrary choice. They are as follows:
Note that this applies to cookies while
they are in memory or stored in the cookies.txt file. 4.3
Retrieving a Cookie Value
For the most part, retrieving cookies does not require reading the HTTP Cookie: header. Most languages read this header for you and make it accessible through a variable or object.
Cookies can be read on the browser side or the server side. Again, the determining factor is the language used.
The main limit on retrieving a cookie is that you can only retrieve cookies that are valid for the document your script resides in. That is, a script on www.myserver.com cannot read cookies from www.yourserver.com. This is also true for subdirectories within your site. A cookie valid for /dirOne cannot be read by a script in /dirTwo. This is mainly governed on the browser side, as browsers know the URL that they are accessing, and only transmit cookies for that server across the connection. 4.4 Clearing a Cookie Value
When programming a Web site, there are many reasons that you may need to erase a cookie you have created. Often it is because the cookie is no longer needed, or the scheme of your cookie has been altered, and requires resetting.
The two main steps to clearing a cookie you have created are:
The reason you must do both is that simply
setting the expiration to a past time will not change it's value
until the browser is closed. That is, all cookie names, values,
expirations, etc are resolved once the browser program has been
closed. Setting the cookie to null allows you to properly test
for the cookie until that resolution. 4.5
Detecting if cookies are accepted
To properly detect if a cookie is being accepted via the server, the cookie needs to be set on one HTTP request and read back in another. This cannot be accomplished within 1 request. When using PERL or ASP, try to funnel your visitors through a common page where you can set a test cookie. Then, when the time comes to detect, check for that cookie.
In 1998, the W3C started drafting a proposal for a Platform for Privacy Preferences (P3P). P3P has 3 main goals (courtesy of the W3C):
Now an official specification, P3Ps use an
XML file to describe in as much detail as possible how a web
site uses personal data during and after a user's session. This
can include the intended usage of cookies to hold or refer to
Alternatively, a site can create a P3P policy that refers solely to its cookie use. These Compact Privacy Policies are a focal point in Microsoft's new strategy in addressing the cookie "problem."
P3P may have a broad impact on cookies and their future use. Especially in the context of advertising and commerce. Even though compact policies are essentially straightforward to create, users still stand to regain a great deal of control over their browser's communications.
About the Author
David holds a Masters Degree in Astrophysics. His personal interests include traveling, photography, gaming, animation, and sports. When not programming, he can be found either playing Quake or out on the golf course.
Copyright ©1997-2002 David Whalen. This document is provided
"as is" without any guarantees or warranty. Although the author
has attempted to find and correct any errors or mistakes he, and
everyone who contributed to it, are not responsible for any
damage or losses of any kind caused by the use or misuse of
information in this FAQ. The author is under no obligation to
provide service, corrections, or upgrades to this FAQ.
The following is legal information and refers to all the information in this document. This information pertains to all use of the FAQ worldwide. All specific names included in the package are registered trademarks and are hereby acknowledged. Any other trademarks not mentioned in the FAQ are still hypothetically acknowledged.
By: Viktor Mayer-Schönberger
The WWW is built on a very simple, but powerful premise. All material on the Web is formatted in a general, uniform format called HTML (Hypertext Markup Language), and all information requests and responses conform to a similarly standard protocol. When someone accesses a server on the Web, such as the Library of Congress, the user's Web browser will send an information request to the Library of Congress' computer. This computer is called a Web server. The Web server will respond to the request by transmitting the desired information to the user's computer. There, the user's browser will display the received information on the user's screen.
Cookies are pieces of information generated by a Web server and stored in the user's computer, ready for future access. Cookies are embedded in the HTML information flowing back and forth between the user's computer and the servers. Cookies were implemented to allow user-side customization of Web information. For example, cookies are used to personalize Web search engines, to allow users to participate in WWW-wide contests (but only once!), and to store shopping lists of items a user has selected while browsing through a virtual shopping mall.
Essentially, cookies make use of user-specific information transmitted by the Web server onto the user's computer so that the information might be available for later access by itself or other servers. In most cases, not only does the storage of personal information into a cookie go unnoticed, so does access to it. Web servers automatically gain access to relevant cookies whenever the user establishes a connection to them, usually in the form of Web requests.
Cookies are based on a two-stage process. First the cookie is stored in the user's computer without their consent or knowledge. For example, with customizable Web search engines like My Yahoo!, a user selects categories of interest from the Web page. The Web server then creates a specific cookie, which is essentially a tagged string of text containing the user's preferences, and it transmits this cookie to the user's computer. The user's Web browser, if cookie-savvy, receives the cookie and stores it in a special file called a cookie list. This happens without any notification or user consent. As a result, personal information (in this case the user's category preferences) is formatted by the Web server, transmitted, and saved by the user's computer.
During the second stage, the cookie is clandestinely and automatically transferred from the user's machine to a Web server. Whenever a user directs her Web browser to display a certain Web page from the server, the browser will, without the user's knowledge, transmit the cookie containing personal information to the Web server.
[Karl Note: Realize that the "personal information" being transmitted here does not include the user's name or that type of personal information unless the user has volunteered it during some web process. So, for instance, filling in a name and address on a form COULD generate that information into a cookie, but the much more efficient way is still to have the cookie ONLY contain some non-descript code number that identifies that computer/browser with a record in a server-based database -- the "personal information" would then be stored in that database, not in the cookie itself.
It is almost the same thing, however. The computer carries along with it some "text string" such as "395j3iridfjeiier" which means nothing to anyone except the "395J" people who are constantly inspecting the disks of their visitors, looking for the "cookie list" and then looking for any cookie that starts with "395j."
When they find THAT cookie, they then read the remainder of the cookie, "3iridfjeiiier" and match that text with the same exact text in a field of a record in their server-based database. That database could have thousands of more pieces of information about that cookie ID, including a log of all the times that person has visited the web site (the visit logs, which, themselves, could contain hundreds of pieces of data for each visit, such as time, page, date, etc.).
The example given here contains a "cookie" with about 16 characters, but a cookie could contain 100 or even 1000 characters and still be so small as to have no "presence" on the browser -- it could be seen in the cookie list, but would be so small that it would never affect the speed or storage capacity of the machine. Also, cookies can not contain "executable code" and therefore cause any damage -- ever. They do "invade your privacy" by allowing someone to keep track of your actions on a web, or on a family of related webs.
So, the guy who visits a porn sight will undoubtedly get a cookie, and that cookie will allow that porn site to identify you as a previous visitor -- even refer to a database on their server where any personal information may have been stored -- such as a credit card.
Different webs, far apart physically, could even share the same cookie information, so there is an invasion of privacy here that you may not know about. There could even be that "vast right/left wing conspiracy to gather and use your private information -- given "innocently" at one innocuous-looking web site, but passed along to the "bad guys." "
This "invasion" is why cookies have such a bad name and why you can find so many programs and browser features that allow you to prevent cookie installation, or allow you to find and delete them.
No matter how bad a cookie might seem, they also greatly enrich the web browsing experience by allowing "intelligent personalized interactivity" on a page, particularly on a shopping cart page.