| Overview Responding to the legitimate concerns of Internet consumers, a diverse group of web developers voluntarily formed an ad-hoc team and prepared the following technical paper. This paper is not intended to "defend" the use of cookies: rather it is offered as a developers view of the role of cookies in supporting interactive and increasingly knowledge-oriented web sites. A related article and FAQ listing focus on the issue of privacy and offers quick tips on protecting your right to privacy. This technical paper includes explanations of the underlying technologies, the role of cookies, discussions of the positive and negative ramifications of this technology, and selected references on this and related topics. The ultimate goal of this effort is the presentation of a balanced view of this emerging Internet technology for use by Internet consumers. The Concept of State To understand the application of cookies as they are currently applied on the Internet in web applications, one must first understand the concept of state. State is the characteristic, which identifies successive web transactions initiated by the same person between a browser and a specific web server from all other web transactions occurring on that server at that time. Simply put, capturing state allows the web browser and web server to exchange information during successive requests with the full knowledge of the history of that set of transactions. Compare this with a basic set of web transactions: each transaction is a separate entity with no knowledge of the prior or subsequent transaction. State information allows the application designer to identify a particular browser, and to associate successive web requests with that browser: put another way, state information allows the application designer to differentiate between different users as they progress through a web application. Through state information, a user may express a preference in an introductory section of a web application, which is then used to select and create content in subsequent sections of that application. Expressing an interest in History while creating a customer profile enables the application to highlight items of interest to History buffs later on. Establishing and Maintaining State In order to establish state-in other words, to identify two seemingly unrelated transactions as actually originating as a successive, related set of transactions, it is necessary to somehow mark the transactions as requests originating from the same client, or web browser. If you were the only person using a particular web server, establishing state would be trivial: the first request received at the server would be your first request, the second would be your second, and so on. However, if a second web viewer were introduced it would be necessary to label your requests-perhaps with a blue mark and to similarly label those from the other browser, in this case with a green mark. The trail of blue marks and green marks would then identify the successive requests of each user, and state could be inferred. Now, let's introduce a slight complication: let's allow the viewer to hop around within the application. Our simple chronological trail is no longer sufficient since the user can hop around, we cannot be sure that the last green marker received represents the most advanced point in the application the viewer associated with the green marker has visited. No problem we can just number the markers according the various sections of the application and keep track of the highest marker number. Now we know who has done what: referring to our gaming example, we can confidently allow the blue player to advance when the blue player has met the requirements of the first level. The numbered markers are in actuality a very accurate example of the tokens that are passed between a client and server to maintain state. These tokens can take a variety of forms: some of the leading forms include hidden variables, additions to the URL, and cookies. Each of these has merits and caveats. For example, it is possible to pass a TYPE=HIDDEN variable (not really hidden at all, since you can look at it through the View Source feature of your browser) to the server using the standard HTTP FORM request. However, this requires that each such request be initiated with a SUBMIT or similar action, a requirement that may impose an unrealistic interactive constraint on an immersive application. Similarly, the token may be attached to the end of the URL and passed on to the server as a part of the address. While this technique has been a part of many standard web applications since the web was introduced in 1992, it is not particularly well suited to applications requiring a secure environment since the token is passed is plain view of anyone who can look at your screen and read the address line! Cookies tokens much like our numbered green and blue markers overcome the shortcomings of both of the previously described methods. Unlike HIDDEN variables, cookies do not need to be passed through the HHTP FORM process and so do not require an explicit SUBMIT action; unlike URL additions, cookies are not plainly visible unless of course to choose to look at them. However, cookies do require that the web server write a small, coded piece of information onto your hard disk and it is partly this behavior that is at the center of the current concern. There are many types of applications that benefit from or even require knowledge of state information. Financial applications, games, interactive learning tools and many other web applications require that the progress of a viewer or information related to preferences or individual choices be maintained in the context of the application. By attaching a marker to each transaction, it possible to create just such a state-aware environment, and in so doing support these advanced applications. Techniques such as those described, and especially the use of cookies, are increasingly in demand as web applications become more sophisticated. Contemporary applications rival what has been possible for over 10 years in a CD-ROM or desktop environment while adding the element of multi-user and distributed interactivity and information sharing, the core elements of the ongoing knowledge transformation in our contemporary, global society. Extending State across Web Visits In the preceding sections the need for state and several techniques for maintaining state have been described. In this section, the concepts are extended to cover not only successive requests at a single sitting, but successive sessions between a particular web visitor and a favorite web site over a period of days, weeks or even months. As an example, consider a travel services web site: you supply your name, your favorite vacation spots, and your budget guidelines. The web application offers a series of vacation options: Sadly, you realize that your day planner is at the office, and you can't make your choices until you look at it. Now what? Without state information, after you disconnect from the Internet, visit the office, return with your day planner and then re-establish your connection, you would have to re-enter your preferences. In a simple example, this may take just a minute, but in a real-world application, you may have spent 10-15 minutes defining your particular preferences, just as you may spend a considerable amount of time building a relationship between you and your travel agent. If you move, you have to re-build that relationship. By using state information, your preferences can be stored and retrieved automatically; as soon as you return to the travel web site, the site "recognizes" you, just as your travel agent recognizes you when you walk into his or her office. This is accomplished using a cookie: a cookie that was stored on your computer by the web application and then examined when you returned to the site. This could have been accomplished using a user name and password just as easily: but seriously, who really wants to remember another one of those? Note that the cookie did not store your actual preferences: that would be use more than the minimum required space on your disk, something no one seems to have enough of. Instead, the cookie contains an identifier a nick name if you will that can be used to look up the information that you provided about yourself which was stored on the web server. Included in the cookie standard is a limit to the overall size of each cookie (4 Kbytes) and to combined number and size of all cookies stored on your hard drive at any one time (300 cookies; 1.2Mbytes). These limits have been imposed to prevent the take-over of precious disk space and/or extended download times of extraordinarily large cookies. Additionally, cookies are often coded with an "expiration date" if you visit a site that adds its cookie to your system and then never return to the site, that cookie will eventually either expire or be pushed off of your system by a newer or more recently used cookie. Privacy Concerns: You Have a Right to Know So what else is stored in a cookie? A better question is "what else is stored in a database that may be linked to that cookie?" The answer is "whatever information you willingly provide." Note the word "willingly" it is an important word. In a recent news story, the person being interviewed stated "if you visit the Playboy site, and then the CNN site, that information can be tracked." True? Sort of. The key here is to understand what information can be tracked, and perhaps more importantly, what cannot be tracked. As with the state concept, a quick technical digression is in order: it is important to understand how you are identified on the Internet. Most people connect to the Internet using an Internet Service Provider (ISP) or an online service. These firms have large pools of Internet addresses called IP addresses which are randomly assigned and re-assigned as people need them. During the time you are connected, you are assigned a specific, unique address; when you disconnect, the next person who calls may be assigned the address that you just gave up. It is this address that is tracked by most web servers, and as you can see, it does not identify you, but rather identifies you as a subscriber to a particular service. So how can you be tracked? Well, unless you willingly provide some additional information, you really can't be. Your Internet address identifies you as a customer of your ISP, not as an individual. Web servers are typically able to read your IP address, the type of browser you are using, the time of day and similar items related to your specific request for data. This generally does not include personal data, nor does it typically include data that identifies you specifically. However, if you sign a guestbook, or register with an online mall, you are truly identifying yourself, and it is at this point that you should exercise caution. Look through the web site, read the policies about the re-selling of information (if provided) and ask questions via e-mail before you subscribe if these policies are not provided. A quick note about combined web browser/ e-mail tools is in order It is possible for some servers to read the e-mail address of web browsers that include e-mail functionality. This means that along with your IP address, your e-mail address can be discerned. If this is not something that you are comfortable with, use a separate e-mail application and do not include your e-mail information in your browser setup. While all of this may seem scary at first, think back about your travel agent: he or she knows quite a lot about you. In fact, it is unlikely that you would do business with any professional that did not take the time to understand, or who could not remember, your specific likes and dislikes. Just as you trust the people with whom you chose to do business, you are being asked to trust the application more correctly the motives of the people responsible for that application. Before you divulge any personal data, think about how it might be used. If the web application does not clearly articulate its policy on reselling information, you may wish to look elsewhere for similar services. Generally, an e-mail to the web site administrator or Customer Service contact is sufficient to establish the answers to these types of questions. An excellent discussion of cookies and potential issues can be found at the Whitehead Institute for Biomedical Research/MIT Center for Genome Research "The World Wide Web Security FAQ" web site, located at http://www.genome.wi.mit.edu/WWW/faqs/www-security-faq.html; the cookie discussion is located at http://www.genome.wi.mit.edu/WWW/faqs/wwwsf7.html#Q64. Summary: It's About You, and it's About Technology That the Internet provides an increasingly rich set of applications and an increasingly sophisticated set of less-well-intentioned applications is old news. Like any new technology, there are new opportunities for beneficial progress along with new traps for the unwary. The vast majority of web developers are building new applications in an attempt to deliver new services, new value and new products; also, to bring existing products to people who lacked prior access. It is essential that you take the time to learn about the technologies that you use, and that you take the time to learn to learn about the organizations that you will hire or use to deliver them. Avoiding any specific technology, as a general rule, is about as effective in a technology-based society in ensuring that you are not harmed as is staying home alone all day. People get taken at home on the phone all the time. Understanding the beneficial aspects of a particular technology along with the risks that it carries and then using that information to make an informed choice is a far better strategy, a strategy that will increase your enjoyment of these newer technologies and decrease your likelihood of disaster. By taking the time to read this paper, and to visit the reference sites contained herein, you have gone a long way to educating yourself and creating your framework for an informed, rational choice. On behalf of all web developers, we thank you for the opportunity to share this information, and for your time spent reading it. Hypertext Transmission Protocol HTTP, the protocol of the web, is an inherently stateless protocol. According to Tim Berners-Lee, who conceptualized and defined the HTTP protocol in 1992: "HTTP is a protocol with the lightness and speed necessary for a distributed collaborative hypermedia information system. It is a generic stateless object-oriented protocol " Source: http://www.w3.org/pub/WWW/Protocols/HTTP/HTTP2.html Because HTTP is stateless, applications that benefit from state-aware transactions require an additional technology in order to capture and preserve state. In order to support an interactive application in client/server environment such as the Web, it is necessary for both the browser and the web server to understand where they are with regard to an overall application path or plan. For example, in a typical game, prior to proceeding to a more difficult level it is necessary to complete a less difficult level. This illustrates the basic concept of state: knowing which players have completed the lesser levels and who are thereby qualified to proceed to the higher levels. Without state information it would be necessary to ask a player if he or she has completed the first level before offering the second. While this may be sufficient for a basic gaming application, more advanced play environments, financial transactions and a whole group of online commerce transactions, to name just a few, clearly require a more advanced method for establishing and maintaining state information. It is for these reasons that state is essential: yet, state is missing in the underlying design of HTTP. Fortunately, as it's designer intended, HTTP is a highly flexible and adaptable protocol: state information can be accommodated, thereby enabling rich, interactive experiences. The next section presents several options for discerning and maintaining state along with the plusses and minuses of each. About the Author Dave Evans is Vice President, Digital Voodoo, Inc., an Internet applications solution provider formed in 1994 and now focused exclusively on the Microsoft Active Server platform. Dave has been involved with the Microsoft Windows NT platform since 1995, beginning with the Blackbird project (Visual InterDev) and the first Gibraltar releases (Internet Information Server). Dave has worked as a consultant and developer with Microsoft's Education Products Group during the evolution of ISAPI extensions to Internet Information Server including IDC and Active Server as applicable to the needs of K-12 educators. Dave Evans
Vice-President, Digital Voodoo, Inc.
(512) 266-9288
http://www.digital-voodoo.com
dave@digital-voodoo.com.
|
