Lecture on Cookies

State
The Request-Reply Model
Cookies
Cookies live on the Client
A Schematic of the Request-Reply Model, with Cookies
Using JavaScript with Cookies
Noticing First-Time Visitors
Saving a User's Name
Saving User Preferences

State

HTTP is like Ms. Short Term Memory; every request is new and exciting.
Information that persists from one connection to the next is called state.

The Request-Reply Model

In the HTTP protocol (the P in HTTP), the browser and the server talk to each other to get/send web pages. A typical request (from browser to server) looks like this:

GET /index.html HTTP/1.0
Accept: text/html, image/gif, image/jpeg
Accept-Language: en

Typical reply (from server to browser):

HTTP/1.0 200 OK
Date: Fri, 20 Apr 2005 16:20:00 GMT
Server: Apache/1.3.9 (Linux)
Content-Length: 141
Content-Type: text/html

<html>
<body>
The web page stuff.
</body>
</html>

Headers contain information about supported formats and languages, and information about the content.
Once the request is sent, http closes the connection and "forgets" about it.
The server might keep a log of the transaction, but it does not use the logged info to track users.

Cookies

Cookies are the primary means for maintaining state (remembering stuff) from one request to the next.

Along with a reply, server sends some additional information in the header.

HTTP/1.0 200 OK
Content-Length: 141
Content-Type: text/html
Set-Cookie: user_id=12345; domain=.wellesley.edu;
            expires=Mon, 23-Apr-2005

... content follows

The first name-value pair determines the name of the cookie and a special value, often used to identify the user.
The domain value determines what sites can access this cookie (usually only the site that issued it).
Other values determine when the cookie expires, which URLs require this cookies, etc.
Clients have the option of refusing cookies (meaning that they do not store them or do not submit them with requests).
Most browsers will refuse a cookie if it directs them to submit information to a third party (not the site that issued the cookie). You can usually configure this. In Firefox 3.5.5 (Mac OS X), it's under Preferences / Privacy, and in Firefox 3.5.5 (Windows), it's under Tools / Options / Privacy. Hunt around in your browser and you'll find it.

Cookies live on the client

For all page requests (in other words, every time you visit a web page), your browser (the client) compares the web page's URL to the cookies in the "cookie jar" and sends all the unexpired cookies that match the domain and path.
```
GET /index.html HTTP/1.0
Accept: text/html, image/gif, image/jpeg
Accept-Language: en
Cookie: user_id=12345
```
The total size of a cookie must be less than 4KB. In practice, it's usually only a few bytes.
The client may hold up to 20 cookies for a given domain, and up to 300 cookies total.
A request might carry more than one cookie.
Your browser can also add cookies to the cookie jar; it doesn't have to come from the server.

A Schematic of the Request-Reply Model, with Cookies

cookies are sent to the browser along with the web page

Browser sends a request to the server. Since the user has never visited that site before, there are no cookies, so none are sent.
The server notices that there are no cookies, so it assumes that this a new visitor, and it generates a new ID for the user and includes that ID as a cookie in the reply. The reply might even be tailored for new visitors.
The browser later (minutes or months later) makes another request at that site and sends back the cookie it got in step 2.
The server gets the request with the cookie, realizes this is a returning visitor, and can generate a customized reply.

Using JavaScript with Cookies

The document returned by the server might have some JavaScript in it, and the JavaScript code can also look at the cookie and customize things. The JavaScript code can also set cookies.

Here are some things we might remember in a cooke:

A user's name
A user id to identify repeat visitors
A user's preferences
...

Let's look at some of these options. All of them will be based on the following JS functions:

Noticing First-Time Visitors

Suppose we want to do something special for a first-time visitor, but not for return visits. Maybe a special introduction or greeting, as we did at the top of this section. How can we tell whether someone has visited the page before? We could set a cookie. We might set a cookie like first_time=no. Remember that cookies have both a name and a value. Also, we have to consider that for a first-time visitor, no cookie will be set, so we have to notice the absence of the cookie.

The code is here:

Saving a User's Name

At the top of this section is a personalized greeting. (We should make it less obnoxious by using forms instead of prompt(), but the code is simpler this way.) The page remembers the user's name for a full year, unless they choose to forget it.

The basic idea is to set a cookie with the user's name. When the page loads, see if there is a cookie set. If so, generate some personalized text, including the forget me option. If not, generate some text to encourage the person to login.

Websites like Amazon.com, Facebook, and many others work like this, only instead of saving your name as a cookie, they also (or instead) save some unique identifier, which is usually a very long number, and they use the unique identifier to look up your name in a database.

The code is here:

Some details:

We can delete the cookie by setting its expiration date to yesterday.
We use location.reload() to reload the page, so that you can see the effects of setting the username. We could omit that and ask you to reload the page yourself.

Saving User Preferences

We can also save user preference settings as a cookie. For example, the top of this section has a variant of the accessibility bar we looked at earlier in the semester. This version saves the user's preferred font size as a cookie, and so the user doesn't have to re-choose the font-size each time he or she visits.

Here is a link that will report the current font size

Even better, because of the path part of the cookie, we can allow the cookie to be retrieved by other parts of our website, so that the pages can use a common set of cookies, and even communicate with them. For example, the font size you choose for this page also applies to this other page.

The code is here:

We could improve this in several ways. For example, once you've chosen your font size, the accessibility bar could be hidden. If you needed it back, you chould just clear your cookies. Try it!

In all our examples, the server always returns the same page, whether there is a cookie or not. In general, the server might do different things depending on the cookie. For example, Amazon.com returns a special page that includes your wish-list and such. Facebook returns an entirely customized page.

Legitimate uses

Provide new user information once, or skip an introduction on subsequent visits. Here is a nice example using music.
Users can avoid typing information every time they revisit. For example, tvguide.com
A user_id allows the server to accumulate information during a visit; for example, a shopping cart.

Less legitimate uses

Violations of privacy: clickstream (possibly with embedded query information), software configuration (OS and browser), contents of any JavaScript variable.
Sites track users, analyze access patterns (within their own sites).
A site can instruct your browser to provide information to a third party (many browsers refuse).

DoubleClick

DoubleClick was a company founded in 1995 that managed to use cookies to track individuals' behavior across websites. Websites that used DoubleClick's ads included absolute links to DoubleClick's ad server, which could then set a cookie as it responded to the image request. The cookie for ad.doubleclick.net could then track which websites the user visited, and this allowed the ads to change based on users' browser behavior. Google eventually acquired DoubleClick in 2008.

From the W3C Security FAQ, some more information about cookies and their security risks.