The most powerful technique in web publishing is also the most subtle: Instead of serving the same static page to their whole audience, many web sites today customize content for individual users, putting pages together dynamically as users request them. Often, users do not even realize they are seeing a page tailored specifically to them because the dynamic content is integrated seamlessly with static elements. This technique, known as personalization, is what sets the World Wide Web apart from any other broadcast medium.

The applications for personalization are virtually limitless: A news site, for example, can display headlines of unread articles prominently on the page, while removing articles which the user already read to reduce clutter. Taking this one step further, the site can record which articles the user reads and which he ignores in order to display a more relevant selection of headlines when he visits the next time. The same mechanism can be applied to products offered on an e-commerce site, advertising displayed on a content site, and many more.

The technical challenge of personalization lies in the fact that in order to serve customized content to a user, the system has to identify him first. This can be achieved by prompting the user to enter a login name before accessing any content. However, that solution is cumbersome for both the user and the system developer. The user will soon become irritated for having to enter a code every time he wants to use the system - while this is acceptable when security is a concern, it is not reasonable for looking up today's headlines. On the server side, the developer has to make sure that the system recognizes the user throughout his session although he enters his identification only once. Since HTTP is a stateless protocol [FGM99], successive requests cannot be associated with a specific session. Thus, the developer must build state management into the system at a higher level, for example by attaching the user's ID to every URL requested - a complicated and error-prone process.

In 1996, Netscape Communications introduced a feature in the Navigator browser that made the simulation of state in HTTP transactions much easier: A so-called cookie [NC96] is a piece of server-generated state information which is stored on the client and automatically transmitted back to the server with every client request. This mechanism has two advantages: Firstly, the developer does not need to implement any state management but can rely on the client to supply the necessary information. Secondly and more importantly, a cookie can be configured to be persistent on the client even if the session with the server ends (i.e. the user leaves the web site or closes the browser). Yet, the next time the client connects to the server, it transmits the cookie again, thereby re-establishing the state that existed before. This way, if the cookie contains a unique identification value, the server can recognize the user without having to prompt for manual identification. The whole process is transparent to the user.

While many users are concerned with the privacy and security implications of letting web servers store and read data on their hard drives, the cookie mechanism implements some safeguards against abuse: Firstly and most importantly, the browser only transmits a cookie if the URL of the requested file matches the valid domain and valid path parameters specified when the cookie was generated. For example, if the valid domain was set to .matthiasbook.de and the valid path was set to /papers when generating a certain cookie, browsers would only send this cookie when they requested files in the papers path of the domain matthiasbook.de (including requests for files like polaris.matthiasbook.de/papers/personalization/index.html). If no valid domain or path are specified when a cookie is generated, the browser uses the host name of the server and the path to the file that generated the cookie. This mechanism ensures that a cookie can only be read by the server it was intended for, but not by any other server. As a second safeguard, transmission of a cookie can be restricted to secure channels, i.e. it will only be sent if an encrypted transmission protocol like HTTP over Secure Socket Layer (HTTPS) is used. This option is useful if the cookie contains confidential information like a password.

Online Preference Marketing >