Agent Architecture

    In the introduction we described the problem space and the reasons why an agent is needed to manage, negotiate and transfer personal information on the Web. Our solution to this problem is the Online Privacy Agent (OPA). This chapter illustrates the concept and the design of this agent as well as a first implementation done at the IBM Research - Almaden [7] . After providing an overview of the OPA's architecture and functionality, its context and its components will be described and illustrated. Following the architectural overview, this chapter describes our current implementation as well as its advantages and limitations. This chapter closes with a classification of the OPA concept and how it relates to existing agent technology.

Architectural Overview

Basic Concept

    The basic concept of the OPA is that of an observer as shown in Figure 2-1 .

    Basic concept (observer) of the Online Privacy Agent.

    This observer has knowledge about the user and his preferences regarding personal information and privacy. When the user browses the Web, the OPA watches the user and any online transaction which he performs. Based on the kind of the transaction as well as its terms and conditions the OPA takes one or more of the following actions:

  1. The OPA intercepts the transaction and informs the user (if appropriate) about various aspects of the transaction, such as potential privacy violations, or provides a summary of the terms and conditions.
  2. The OPA assists the user by suggesting reasonable decisions based on the user's preferences and previous experiences in online transactions. In addition to this, the OPA can negotiate the terms and conditions of the transaction on behalf of the user and then have the user decide whether to complete the transaction.
  3. The OPA takes over the transaction and finishes it on behalf of the user by negotiating the terms and conditions of the agreement and then automatically transferring the information to the other party.
  4. In order to enable the Online Privacy Agent to perform the above mentioned tasks, several conditions must be met:

  5. If the OPA is to be able to access and understand a Web site's privacy policy, then a protocol for expressing and exchanging such information is needed.
  6. If the OPA is going to act on behalf of the user, the user's preferences need to be accessible in a machine-readable form.
  7. In order to support the automated negotiation and transfer of a user's personal information, the OPA needs a negotiation strategy as well as access to (a subset of) the user's personal information.
  8. In order to use the OPA with existing technology (i.e., Web browsers), a connection to existing technology is needed to make them P3P compliant.
Agent Context
Architectural Overview.

    This section will illustrate the OPA's concept and design by using P3P and APPEL, among other things. As shown Figure 2-2 , the agent is placed between the Web application (Web browser) and the Web. 1 To briefly summarize Figure 2-2 , every request from the Web browser will be routed through the OPA. The OPA modifies this request by adding additional information to it before forwarding the modified request to a Web server. 2 Every response from Web services is also routed through the OPA. The OPA analyzes the response according to its configuration and then either forwards the response to the Web browser, creates its own response, or starts a negotiation with the Web server. In addition to this, Figure 2-2 also shows the OPA's individual components. The following sections will explain these components in detail.

Components

Protocols

    Browsing the Web and exchanging privacy information requires the use of protocols. The two protocols used in this context are the Hypertext Transfer Protocol (HTTP) [8] and P3P, which are represented by the arrows between the Web users and servers, and the Web as shown in Figure 2-2 on page 13 . HTTP is the standard protocol for requesting Web resources, such as Hypertext Markup Language (HTML) documents or images. 3 P3P provides a set of extensions to the HTTP protocol and an associated syntax for exchanging privacy information between a Web site and Web users (or their agents). This exchange of information is done through standard HTTP methods. In addition to this, P3P provides a framework for specifying proposals. A proposal specifies the terms and conditions of an online transaction. HTTP, P3P and their use for the transfer and management of personal information are described in detail in Section 3.1.1 on page 35 and Section 3.1.2 on page 37 . A brief introduction to P3P with information about P3P's syntax and a sample P3P transaction can be found in Appendix B , Platform for Privacy Preferences Project (P3P) .

P3P Module

    The P3P module is one of the OPA's major components and is responsible for the P3P support. Because P3P is still in progress and does not yet have recommendation 4 status, none of the existing Web browsers support P3P. Thus, a mechanism was needed to modify and analyze HTTP requests and responses. This is done by intercepting the HTTP stream and adding the P3P information to a HTTP request and by extracting the P3P information from a HTTP response.

    In addition to this, the P3P module is responsible for sending P3P messages (using standard HTTP) to a Web server in order to perform the seamless transfer of personal information or to simply abort a transaction in case of potential privacy violations. If the P3P module aborts a transaction based on the output of the Trust Engine (see next section), it must also inform the user. This is done by sending HTTP messages to the connected Web browser.

    Detailed information about the functionality of the P3P module and how it can be used to transfer personal information can be found in Chapter 3 , Management and Transfer of Personal Information .

Trust Engine

    The OPA's second major component is the Trust Engine. After the P3P module detects and extracts privacy information (e.g., a P3P proposal) from a Web server response it invokes the trust engine. Among other things, the proposal is the main input for the trust engine and represents the Web server's privacy policy regarding the current transaction. The proposal might also include a request for pieces of the user's personal information. To summarize the trust engine's functionality briefly, the trust engine analyzes and checks the server proposal against the user's preferences and proposes an appropriate response. This response will be returned to the P3P module which in turn will inform the user, respond to the Web server, or both. The trust engine consists of three major components which are described in the following three subsections.

Evaluation and Negotiation Module

    The evaluation and negotiation module is the computation module of the trust engine. It takes a P3P proposal and additional information about the current transaction and performs an analysis. This analysis includes rule evaluation and optionally the negotiation of various aspects of the current transaction. Negotiation would be performed if the Web server were willing to negotiate the terms of the current transaction. The Web server would indicate this by including this information in its initial P3P proposal. Both, rule evaluation and negotiation are based on the user's preferences and the underlying negotiation knowledge base (see Section 2.2.3.2 ).

    Rule evaluation is done to determine whether the Web site's privacy practices are compatible given the user's preferences. If so, the trust engine signals the P3P module to either inform the user that the current transaction complies with his preferences or finish the transaction seamlessly. If the Web site's proposal includes the request for information, the trust engine would access this information (if available) from the personal information storage (see Section 2.2.3.3 ) and include it in the response sent to the P3P module.

    If the Web site's proposal is not acceptable according to the user's preferences the trust engine will signal the P3P module to either inform the user about potential privacy violations or abort the transaction. If the Web site indicates that it is willing to negotiate, the trust engine performs a negotiation step before signaling the P3P module to perform its next action. The result of the search for a counter-proposal step will be either the found counter-offer (P3P proposal) or a rejection 5 of the Web site's proposal. The result depends on whether the trust engine is able to find a reasonably close counter-offer which satisfies the user's preferences. This counter-proposal should be found within a certain number of negotiation rounds. The P3P module will then either send the counter-offer back to the Web server or inform the user that the transaction should be aborted.

    Please refer to Section 3.3.2 on page 46 for a functional model of the OPA. It illustrates how the OPA's individual modules collaborate during online transactions. The concept of negotiation and the algorithm of how to find a reasonably close counter offer go beyond the P3P specification. Chapter 4 , Negotiation of Personal Information explicitly describes these two issues. As mentioned above, the user's preferences and personal information are also needed to perform the described steps during an online transaction. The following two sections describe how these components are integrated in the trust engine.

Preferences and Negotiation Knowledge Base

    The preferences and the negotiation knowledge base are shown in Figure 2-2 on page 13 as parts of the trust engine. First of all, this is a logical view of the Online Privacy Agent which means that the preferences and the knowledge base are not necessarily contained in the trust engine but are used by the trust engine. The functionality and output of the trust engine highly depend on these two parts.

    The preferences can be seen as a set of rules which define under which circumstances pieces of the user's personal information can be released to another party during an online transaction. The preferences also define the actions the agent has to perform during an online transaction when the Web site's privacy practices comply or do not comply with the user's preferences. Moreover, the preferences are the basis for the negotiation knowledge base. They are expressed using APPEL which is an ordered rule-based language. A brief introduction to APPEL is given in Appendix C . In addition to this, Section 3.2 on page 39 illustrates the use of APPEL in the OPA in order to manage personal information.

    The negotiation knowledge base contains information which is used by the trust engine to perform the negotiation of personal information. In order to do so, the trust engine needs to know about acceptable terms and conditions of transactions as well as have a negotiation strategy. The strategy contains information such as the importance of certain aspects of an online transaction and the number of rounds of a negotiation allowed before the trust engine must reject or accept a transaction. Based on the information in this knowledge base, the trust engine will try to find a reasonably close counter offer which then will be sent back to the Web server. A detailed description of the concept and current implementation of the negotiation module can be found in Chapter 4 , Negotiation of Personal Information .

Personal Information Storage

    Similar to the preferences and the negotiation knowledge base, the personal information storage is shown as a part of the trust engine (see Figure 2-2 on page 13 ). This does not necessarily mean that this storage is physically contained in the trust engine. It is shown this way in order to illustrate that the trust engine needs access to the actual personal information, such as the user's name and address.

    The trust engine needs access to the personal information for two reasons. First of all, the trust engine might determine that the terms and conditions of the current transaction are acceptable. If the trust engine is to finish the transaction on behalf of the user, the trust engine needs access to the actual values of the user's name and address. After the trust engine has read this information from the personal information storage, it includes the information in a P3P message. Then, this message is sent back to the Web server (P3P module). Secondly, if the user gathers new information during online transactions or a Web server wants to store information on the user's computer, the trust engine needs a way to store this information. Storing this information in the same place as a user's personal information has the advantage that the newly stored information will then be available to the OPA in subsequent transactions.

    Note: The personal information storage, the user's preferences, and the negotiation knowledge base are shown as separate modules (see Figure 2-2 ). This was done to distinguish between the personal information itself (name, address, etc.) and information regarding the use and distribution of such personal information. In later P3P applications, whether they perform negotiation or just simple rule evaluation, all of the information (personal information and the respective preferences) will probably be available through a user's data repository. This means that all of this information is available in one place which can be either a database on the same computer or something completely different. Please refer to the next section for information on how personal information and the respective preferences are accessed in our current implementation.

Current Implementation

    The previous sections explained the OPA's underlying concept and architecture. In this section, its implementation will be explained. The following subsections provide information about implementation details, such as design decisions and information about the implementation of the OPA's modules as presented in the previous sections (see Figure 2-2 on page 13 ).

Proxy Implementation

    The OPA is implemented as a proxy. A proxy receives HTTP requests and forwards them to the appropriate server for the request to be satisfied. When this server returns the results to the proxy, they are then forwarded back to the client. This proxy function is often completely transparent to the client. In other words, the client receives back the same results as if the server had been addressed directly. Transparent proxies are commonly used to provide firewall protection and to cache web pages for better network utilization. Proxies need not be transparent. In other words, the proxy may produce different results for the client than the client would have received had it addressed the origin server directly. Common uses for non-transparent proxies are transcoding, blocking access to particular Web resources, and user modeling, among others. The OPA is a non-transparent proxy based on WBI [9] which stands for Web Browser Intelligence and was invented at the IBM Research - Almaden.

    There were several reasons why we decided to implement the OPA as a proxy. First of all, the proxy approach is not browser-specific and can be used with all currently existing Web browsers that can connect to a proxy. Secondly, the OPA is also platform-independent through the use of WBI as the underlying implementation platform. WBI is fully written in Java [10] and can be run on any operating system for which a Java Virtual Machine (VM) exists.

    The alternative to a proxy would have been a browser specific approach. This was rejected because it is not possible to implement the agent as a browser plugin. As mentioned in previous sections, in order to exchange privacy information the OPA needs access to the HTTP stream (requests and responses). Browser plugins do not have this ability. Thus, the only way to implement the OPA in an existing browser would have been the modification of a particular browser. This approach was rejected as well because it would have meant losing the platform independence and the ability to use the OPA with different kinds of browsers.

Web Browser Intelligence ( WBI)

    As explained in the previous section the OPA was implemented as a proxy based on WBI which represents an architecture for intermediaries. [Barrett98] defines intermediaries as computational elements that lie along the path of Web transactions. Intermediaries may operate on Web data at many different times: when a request is sent from the browser, when a request is passed through a firewall or proxy, or when a document is returned to the browser. Intermediaries have access to Web data at all these stages and may observe requests, respond to requests, or modify both the requests and responses.

    WBI is a programmable proxy server that was designed for easy development and deployment of intermediary Web applications. The WBI architecture provides a programming platform which supports the implementation of all kinds of intermediaries, from simple server functions to more complex tasks as document format conversion and knowledge management. Many projects have been implemented so far using WBI, including password management, collaborative filtering and intelligent agents. An intermediary based on WBI is called WBI plugin, which is constructed from basic building blocks called MEGs (Monitor/Editor/Generator).

    A simple example of a WBI Plugin is an intermediary for managing HTTP cookies. Current Web browsers allow servers to send a cookie with a document. The cookie is stored by the Web browser on the client machine and can be used to identify the user later. Some users are not very comfortable with cookies because cookies remove a certain degree of privacy. Some browsers allow the user to configure a cookie policy, such as accept all cookies, never accept a cookie or always ask the user for each cookie. These simple policies are often not sufficient. It may also be difficult to examine the cookies that have already been stored. Using WBI it is relatively easy to build a flexible cookie manager just by implementing three MEGs. One MEG would modify all documents that are sent to the browser. If a cookie is detected, it will always be removed and only stored if it fits a preselected policy. If this policy permits cookies, a second MEG adds stored cookies back into requests before they are sent to the server. Last but not least a third MEG is used to produce and interpret a few simple HTML forms which allow the user to set the cookie policy and to review or delete stored cookies. These three MEGs form a WBI Plugin to manage HTTP cookies (see Figure 2-3 ). For more information about WBI and its underlying architecture, please see [Barrett98] and the WBI home page at the IBM Research - Almaden [9] .

    A sample WBI plugin: HTTP cookie manager.
Modules

    The OPA is implemented as a WBI plugin, i.e., a composition of MEGs. The MEGs represent the P3P module as described in Section 2.2.2 . They are responsible for modifying HTTP requests for an arbitrary Web resource and then forwarding this modified request to the Web server. In addition to this the MEGs intercept each HTTP response in order to look for privacy information encoded using P3P. When P3P information is found, one of the MEGs either sends a P3P response to the Web server or sends a document to the browser. All the MEGs use the standard WBI MEG library to perform tasks such as sending and receiving information (documents) from a specified destination which is either the browser or a Web server. The documents sent to the browser can either be Web resources received from Web servers or newly-created HTML pages which inform the user about the current transaction. If the user responds to this information by agreeing or rejecting the information shown in the browser, a new HTTP request is issued. These are special requests that are intercepted by the MEGs in order to extract information from the user's response and forward the request. WBI knows how to distinguish between the different MEGs because they are configured with different rules. A detailed description of WBI's rule engine and various features would exceed the scope of this document. We will later return to WBI plugins and MEGs after we explicitly described the OPA's functional model. Chapter 3 , Management and Transfer of Personal Information , describes the different tasks and stages of the OPA during Web transactions and how the OPA's functional model was mapped onto a WBI plugin.

    The trust engine consists of a series of Java classes that can analyze transaction information. These classes are used within the MEGs in order to determine which of the MEGs needs to be invoked to perform the next action.

P3P / APPEL Implementation

    The request editors and the document editor need ways to access and to extract P3P information from the HTTP stream as well as the ability to add P3P information to it. We implemented two Java class packages 6 (java.ibm.com.p3p and java.ibm.com.appel) which make it easy for implementations to create and manipulate P3P messages according to the P3P protocol. Classes in these packages can also easily load and use APPEL preferences stored in files. Moreover, the APPEL package also provides rule evaluation based on the APPEL specification. The two class packages and a few Java test classes are packaged as the P3P Parser, 7 which is available for download at the IBM Alphaworks Web site [12] . Both class packages make extensive use of the XML Parser for Java [13] . The XML parser can check whether an XML document is well-formed or valid. An XML document is well-formed if the document obeys the syntax of XML. A well-formed document is valid only if it contains a proper Document Type Declaration (DTD) and if it obeys the constraints of that declaration [Walsh97] . Because APPEL rulesets and P3P messages are encoded using XML, the classes of the P3P Parser package use the XML parser to verify that rulesets are correct and that P3P messages comply with the current P3P specification. Both class packages contain classes that represent certain parts of the APPEL and P3P specification and allow easy access to the attributes and values of the particular items. For a detailed description of the P3P parser, please download the package and refer to the included Java documentation. It explains the included classes and interfaces and also provides information regarding how to use the package. The P3P Parser was the first and is still the only publicly available implementation for handling and manipulating P3P messages and APPEL rulesets.

Preferences, Negotiation Knowledge Base, and Personal Information

    The user's preferences are stored in a file that is accessible to the OPA. The file contains an APPEL ruleset which can be read using the P3P parser package as presented in the previous chapter. The package contains a class that represents a ruleset and that can be instantiated by passing a filename to the APPEL ruleset constructor. On the OPA's startup the ruleset is constructed from the XML-encoded APPEL source. The negotiation knowledge base is also constructed on the OPA's startup. Please refer to Chapter 4 , Negotiation of Personal Information , for detailed information on how the negotiation knowledge base is constructed and used in Web transactions.

    The negotiation knowledge base and the personal information storage is accessed through the interfaces of two special objects. These objects are instances of Java classes that hide the implementation of the information storage and the knowledge base from the OPA. The OPA accesses the functionality and information represented by these objects through the class interfaces. These class interfaces are independent from the underlying implementation. For example, the object that represents the personal information storage has four major methods. One for establishing a connection to the storage, one for closing the connection and two in order to get and set information. It does not matter to the OPA whether connecting to the storage means connecting to a database, connecting to another object, or simply reading the contents of a file. The first implementation used a simple initialization file (INI-file) which contained key value pairs for the personal information, such as user.name.first = John.

    In later versions, this approach was replaced by an object that could access a personal information storage over the network using HTTP. Since this approach allows a physical separation between the OPA and the user's personal information, they could be located on different computers.

Usage

    The previous sections described the OPA and its modules and how the OPA can assist a user in Web transactions regarding privacy and the release of personal information. In order to test the OPA we also had to implement a P3P test server because P3P implementations are not generally available. The following sections describe the server implementation as well as how to use the OPA with existing browser technology. Moreover, it illustrates the usage of our implementation with the P3P demo. This demo was presented on several occasions 8 and represents the first running P3P-Client-Server-Demo.

P3P Test Server

    The P3P demo contains the OPA as described in the previous sections and the P3P demo server. This server is relatively simple. It offers four HTML documents, a home page and three pages that can be reached from the home page by clicking on one of the hypertext links to the pages. When the user clicks on one of these links and requests the page, the server receives this request and first checks whether the client is a P3P enabled browser. If so, the server responds to the client's request by sending a P3P proposal which covers the requested page. The server sends the requested Web page only if the user accepts the proposal and provides the information (through the use of P3P) as requested in the proposal. If the client does not understand P3P, the server sends an information page that the requested resource can only be accessed with a P3P-enabled Web browser.

    The P3P demo server is also implemented using WBI. The server WBI plugin has three MEGs. The first MEG will check incoming requests for Web resources and look for P3P information. If the request is the initial request for a Web resource and the request indicates that the client understands P3P, the second MEG is invoked to send a P3P proposal back to the client. Note that the server does not send the requested Web resource yet. If the P3P information in the request satisfies a corresponding P3P server proposal, the third MEG is invoked and sends the Web resource as specified in the client's initial request.

Setup

    The demo requires two WBI instances. The first WBI instance (a P3P client) runs the OPA plugin, while the second WBI instance runs the server plugin (a P3P server). The P3P client is connected to the client Web browser by configuring the browser to use localhost as its proxy. The P3P client will process all requests from the browser by listening to the localhost port as specified in the browser configuration. This makes the client's Web browser P3P compliant. The P3P server is configured such that it listens on port 80 9 and can be accessed by the name of the machine it is running on. Because of the use of WBI, this demo can run on one machine, which was very efficient during implementation and testing.

P3P Online Session

    This section explains the P3P demo itself and how the OPA works in common Web transactions. In the demo, the OPA assists the user or finishes transactions on behalf of the user. The user of this session has a set of preferences specified in an APPEL ruleset. This ruleset was read by the P3P client on startup and contains four rules (see See ). The P3P server in this demo can be reached using the respective Uniform Resource Locator (URL) which depends on the machine the server is running on.

    The demo starts with the user accessing the P3P server's home page. The P3P server responds by sending its home page (see Figure 2-4 on page 25 ). Note that the P3P server does not send a P3P proposal when a visitor accesses the home page. This home page offers some information about P3P and three links to other Web resources offered by the P3P Server. All of these links can only be accessed with a P3P compliant Web browser. The user decides to click on the first link (see hand-cursor in Figure 2-4 ). To the user it appears that after he clicked on the link (and the Web browser sent the request to the P3P server), the server returns the requested document (see Figure 2-5 on page 26 ). This Web page shows the user's first name and some information about his year of birth. The P3P server received this information (first name and year of birth) during the transaction from the P3P client. This shows that in-between the user's request and the display of the server's response, a few things must have happened transparently.

    P3P Demo: Server home page.

    Here is a description of the missing steps: The requested Web page (see Figure 2-5 ) was covered by a P3P proposal which was sent back by the server as a response to the initial request. This response was analyzed by the P3P client (agent) and checked against the user's preferences. As one can see in the user's ruleset (see Appendix D ), the first rule specifies that the P3P client can seamlessly accept proposals that only ask for the user's first name, his date of birth, and some special identifiers under certain conditions. The proposal sent by the P3P server matched this rule and the P3P client seamlessly sent the requested information to the server. Then, the server responded to the initial request by extracting the user's data (first name {Joerg} and year of birth {1971}) from the client's P3P response, including the data into the Web document, and sending the modified document to the browser (see Figure 2-5 on page 26 ). This is only one example how P3P can be used to customize Web sites for visitors.

    P3P Demo: Result after seamless P3P transaction.

    From the page as shown above in Figure 2-5 , the user advances to the next Web page offered by the P3P server (see hand-cursor). By clicking on this link, the user can (if his browser is P3P compliant) automatically subscribe to a mailing list and advance to the next page. When the user sends a request for this document again, the P3P server responds by sending a P3P proposal which asks for the user's full name, his email address, and some additional information. Again, the P3P client receives this proposal and checks it against the user's preferences (see Appendix D ). This time though, the first rule does not apply because the P3P server asks for additional information than specified in the first rule. The rule that is matched is the second rule which specifies that whenever a server asks for any parts of the user's name or email address the user should be informed and prompted to make a decision. The P3P client applies the rule and produces an informational HTML document which is sent to the browser (see below, Figure 2-6 ).

    P3P Demo: Interception of Web transaction (informational prompt).

    Figure 2-6 on page 27 shows the P3P client informing the user about the data elements requested by the P3P server. The client prefilled the form for the user with the known data elements. It is now the user's decision to fill out the blank edit fields and accept the transaction by submitting that data, modify the information, or reject the transaction. In this demo, the user accepts by hitting the submit button.

    P3P Demo: Result after intercepted P3P transaction.

    The P3P client intercepts this request, extracts the user's information from the form, creates a P3P response with this information, and sends the response back to the server. Now the server can take the response, extract the user's information, add the user to the mailing list, include the information in the corresponding Web document and then send this document back to the browser (see Figure 2-7 on page 28 ).

    The last stage in this demo demonstrates how the P3P client can automatically reject Web transactions. From the Web page as shown in Figure 2-7 , the user clicks on the link (see cursor hand) that would lead him to a kind of online catalog. This transaction involves the release of the user's address and some additional data. The server asks for this information by sending a third P3P proposal that covers this Web page. When the P3P client receives this proposal, it will extract the P3P information check it against the user's preferences (see Appendix D ). In this case, though, none of the rules which were matched in the previous transactions apply. The first rule is violated because the server asks for other information than specified in the rule. The second rule cannot be matched because the P3P server's purposes for this transaction do not match the purposes allowed in the second rule. The third rule is violated for the same reasons as rule number one is violated. Because none of the rules can be matched, the rule evaluation returns the behavior of the default rule. This default behavior is a seamless reject behavior which causes the P3P client to intercept the current transaction, send a P3P reject message to the P3P server, and send an informational HTML document to the user. This document contains information about the transaction and the reasons why it was automatically rejected 10 (see Figure 2-8 on page 30 ).

    P3P Demo: Seamless Reject of a Web transaction.
Advantages and Limitations

    As with almost every software package the current implementation of the OPA has its advantages as well as limitations. We described how the OPA can assist a user by informing him about transaction characteristics and performing tasks on his behalf. Among other things, the OPA lessens the burden of providing information to Web sites by either prefilling forms or seamlessly finishing transactions. The sometimes annoying procedure of typing in the same information over and over again is now limited to the provision of information that the OPA has no knowledge about (see last edit field in Figure 2-6 ). By supporting P3P, the OPA can summarize the terms and conditions of the current transaction and display this information in a less complicated way than privacy policy statements. This will make Web transactions less time-consuming for users who want to know about these things.

    Besides the benefits for the user, the current implementation offers several technical advantages. Because of the use of WBI and Java, the OPA is platform-independent and can easily be used on each operating system for which a Java VM is available. Moreover, the implementation of the OPA as a WBI proxy makes the OPA browser independent, i.e. it can be used with any existing browser technology that allows a proxy to be used in order to connect to the network.

    The current implementation also has limitations because of the use of a proxy. Currently, WBI does not know how to handle secured connections, such as SSL. There are ways to tunnel SSL through a proxy but this means that the proxy can only forward the information rather than read and decrypt it. This is a critical problem for the OPA which is supposed to help protect a user's privacy. Please refer to Section 5.2.3 on page 86 for information on a possible solution to this problem.

Agent Classification

    The first chapter and the previous sections described a system to manage, negotiate, and transfer personal information on the Web, for which the term (software) agent was used. In recent years the term agent has become very popular, and a significant number of developers now present existing components of their software as agents. [Foner93] criticizes this phenomenon:

"... I find little justification for most of the commercial offerings that call themselves agents. Most of them tend to excessively anthropomorphize the software, and then conclude that it must be an agent because of that very anthropomorphization, ... Most are barely autonomous, unless a regularly-scheduled batch job counts. Many do not degrade gracefully, and therefore do not inspire enough trust to justify more than trivial delegation and its concomitant risks."

    The reason why so many now use the term agent for a wide variety of software is that nearly everyone has a different understanding of what an agent is. [Bradshaw97] alone lists eleven different approaches that imply different definitions of an agent. Basically, there is no consensus definition of the word agent [Nwana96] .

    In this section a short overview about existing agent technology is given. Based on this overview, the Online Privacy Agent (OPA) is compared to existing agent technology and it is explained why this document presents the OPA as an agent and not just as a piece of software.

Agents Overview

    As mentioned above there is no consensus definition for the word agent [Nwana96] , and this thesis will not propose yet another one. Most of the confusion about what justifies the use of the term agent, is based on differences among people's expectations and points of views.

"... one person's intelligent agent is another person's smart object; and today's smart object is tomorrow's dumb program." [Bradshaw97]

    A full overview of software agents exceeds the scope of this thesis, but we will give at least a short overview in order to compare the OPA to existing agent technologies and to justify the use of the term agent in this document.

    First of all, following [Nwana96] , this overview will use the term software agent as an umbrella term that covers a range of other more specific agent types. These types share the notion of a component of software that is capable of acting exactingly in order to accomplish tasks on behalf of its user. Different agents can be classified by their locality (e.g., mobile vs. static), the roles they play (e.g., searching or reporting), their attributes (e.g., autonomy, learning, or cooperation) and their behavior (e.g., deliberative or reactive). This model of classification was used by [Nwana96] to introduce a typology of agents which specifies seven basic types of agents. Among them is the interface agent, which can be seen as a personal assistant which collaborates with the user in the same work environment [Maes97] . Such an assistant can help the user in various ways, such as hiding complexity of difficult tasks or performing tasks on the user's behalf. In addition to this, interface agents can monitor events and procedures and learn from the user or from what they observe.

    Others, like [Etzioni95] and [Franklin96] , defined taxonomies for agents. These taxonomies characterize agents by the degrees to which they possess attributes like reactivity, autonomy, collaborative behavior, knowledge level communication ability, inferential capability, temporal continuity, personality, adaptivity, and mobility. As one can see, both classifications overlap in some aspects. Without going into further detail, we will now use the information as mentioned above to explain why the OPA is an agent.

Agent Comparison

    Classifying agents is not an easy task; agents may fit more or less into more than one category. The OPA, though, can clearly be viewed as an interface agent. According to the definition of an interface agent [Maes97] , the OPA assists the user in online transactions, collaborates with him in order to complete a transaction, and lessens the burden on the user. It clearly possesses the main characteristics of an interface agent. Moreover, by looking at the OPA's functionality, we can also see that the OPA complies with the taxonomies as introduced by [Etzioni95] and [Franklin96] :

  1. The OPA monitors the user and its Web transactions.
  2. The OPA can finish Web transactions on behalf of the user. (autonomy)
  3. The OPA collaborates with the user by informing the user about the status of transactions and asks for advice if it cannot finish them seamlessly. (collaborative behavior)
  4. The OPA learns from the user by keeping track of the transactions finished by the user. This information can be used in subsequent transactions such that the user does not need to finish transactions anymore. (adaptivity)
  5. The OPA represents the user by applying the user's preferences on Web transactions. (personality)
  6. The OPA has the ability to negotiate terms and conditions of a transaction on behalf of the user. This ability is based on a rule-based knowledge base. (autonomy, personality, collaborative behavior)
  7. The OPA hides the complexity of analyzing privacy policy statements and checking them against the user's preferences.
  8. As we have shown, the OPA's concept and architecture justifies the use of the term agent. It combines several agent characteristics in a useful tool to assist a user by reducing the complexity of online transactions.


1. This does not necessarily mean that they are separate modules. The agent can either be integrated in the browser or be connected to a browser as a stand-alone module.

2. Forwarding a request to a Web server includes many steps which are not explained in this document. Requests issued with a browser go through several network layers (e.g., operating system, hardware). Among other things, this includes Web server name resolution through a Domain Name Server (DNS) and sending the request over the physical network connection, using the Transfer Control Protocol/ Internet Protocol (TCP/IP) [Stevens94] .

3. The most commonly used image formats are JPEG (Joint Photographic Experts Group) and the Graphic Interchange Format (GIF).

4. W3C's current P3P specification is a working draft.

5. When a P3P proposal gets rejected as the result of a negotiation step, it is the server's decision to either resume the transaction by sending a second proposal or simply end the transaction.

6. See [Flanagan97] for information about classes, interfaces and packages in Java.

7. Note: The P3P parser package does not include WBI or our current agent implementation.

8. Among other occasions, the P3P demo was presented to W3C's P3P working group in a face-to-face meeting held at the IBM Research - Almaden and at the XML'98 conference in Chicago, USA.

9. Port 80 is the default. If client and server run on the same machine the ports need to be different. If another port than 80 is used, the server needs to be accessed like http://<url>:<portnumber>.

10. Although not shown in this demo, it is possible to allow the user to override the seamless reject and finish the transaction if desired.


April 9, 1999 · Jörg Meyer · jmeyer@almaden.ibm.com