Businesses are willing to give away software or offer services in exchange for people's personal information, such as name, address, and phone number. The use of personal information, especially in online transactions, is of ever increasing value. However, along with the growing benefits of revealing personal information and the proliferation of information systems that collect, store and aggregate data, privacy becomes an important factor; important enough to trigger the development of protocols and languages which address privacy issues. The Platform for Privacy Preferences Project (P3P) is a current project of the World Wide Web Consortium (W3C). P3P offers a framework for informed online interactions on the Web. It allows for the automatic exchange of privacy policies (i.e., proposals) and transaction information (e.g., requests for data and personal information) between Web sites and Web clients (e.g., Web browsers or user agents). In addition to P3P, the W3C is currently working on A P3P Preference Exchange Language (APPEL), which allows a user to express his preferences regarding P3P transactions.
This thesis described the Online Privacy Agent (OPA), one of the first systems to support P3P and APPEL, and our approach towards better privacy protection on the Web. The OPA is a software agent that helps a user during Web transactions, just like a personal assistant. The OPA's accomplishes this by monitoring a user's actions when browsing the Web. By supporting P3P, the OPA can analyze Web sites' proposals received during transactions and evaluate them based on the user's preferences. Based on the results of the evaluation, the OPA can offer advice to the user or complete a transaction on behalf of the user. The evaluation process and the ability to complete transactions depend on the user's preferences, which are expressed with APPEL. The OPA's APPEL and P3P support was implemented in Java and was made publicly available on the IBM Alphaworks Web site  . This package is still the the only available P3P and APPEL implementation.
The OPA clearly distinguishes itself from simple monitoring and reporting tools. The OPA's ability to act on behalf of the user was realized by making it user-configurable and by allowing it access to the user's personal information. A user's preferences (i.e., APPEL rules) are used to determine the OPA's behavior during a transaction. There are several possible behaviors, such as informing the user about the transaction and having him decide what to do or completing the transaction on behalf of the user. Completion of a transaction can be a rejection of a proposal because the respective terms and conditions do not meet the user's preferences. If the terms and conditions are compatible with the user's preferences, the OPA can seamlessly accept the proposal and satisfy the Web site's request (i.e., send personal information).
When the OPA's acts on behalf of the user, it lessens the burden on the user in several ways. The user does not have to read privacy policies for each transaction because the automated access to and evaluation of privacy policies is made possible through the use of P3P. Furthermore, the user does not need to type in the same information over and over again. Giving the OPA access to the user's personal information means that information can be sent seamlessly (given the fact that the terms and conditions of the current transaction are compatible with the user's preferences). Besides the direct benefits for the user during a transaction, the OPA also provides long-term benefits. Its ability to monitor transactions allows the creation and maintenance of a transaction history. Such a history is not only useful for later reference but also for future transactions.
However, we felt that rejecting or accepting offers represented only a fraction of the aspects of transactions in the physical world. One of the most interesting parts of a transaction is the process of negotiation. Thus, we designed a framework for the automated negotiation of sets of information. In contrast to most negotiation systems that simply negotiate the price of an item by bidding, our framework considers the terms and conditions of transactions. This makes the framework useful for various eCommerce applications, in which not only the price of an item but also aspects such as warranty or support are of increasing importance. In the context of privacy in online transaction, the framework allows the OPA to negotiate the terms and conditions of online transactions. The benefit of negotiation is that the OPA can try to reach an agreement with the Web site that is satisfactory to both parties, without bothering the user or rejecting a proposal. A negotiated agreement is always compatible with the user's preferences, since they are the basis for negotiation.
The OPA's platform- and browser-independent architecture make it a widely usable tool to enhance a user's privacy protection when browsing the Web. By using an OPA, users can be made aware of possible privacy threats. In addition to this, the OPA reduces the work and information overload on the Web by representing the user during online transactions. The OPA certainly does not prevent privacy violations. However, the OPA is still a valuable assistant which makes the user more sensitive about online privacy and helps the user to manage, negotiate, and transfer personal information on the Web.
There are several possibilities for future work regarding the OPA, such as a few unresolved issues with respect to its implementation. In addition to this, there are several things to do in regards to testing and reviewing the OPA's concept and architecture. In this section, we will mention some of the issues that are relevant in the near future.
One of the larger research projects is to extensively test the OPA's usability. Due to the fact that P3P had not been widely deployed yet, we were limited to our own implementation when testing the OPA. Although we have shown that the OPA exhibits a number of useful features, it still needs to be tested against a wide variety of Web services. However, this requires a broader deployment of P3P on the Web. As P3P is moving towards recommendation status, we hope that more Web sites will implement P3P, thereby allowing us to extensively test the OPA. This will help us review and modify the OPA's concept and architecture where necessary.
One of the OPA's features is to accessing the user's personal information in order to prefill forms and complete transactions on behalf of a user. In addition to this, the OPA needs a way to keep track of transaction information and store the appropriate data. As we have mentioned earlier, the personal information storage can be a simple file, a database, or any other possible storage system that can be accessed. However, there are several things to consider when coosing a data storage system. First of all, one should avoid creating yet another place where information is stored. There are already numerous applications that store personal information, and most of them cannot share their data with others. The ideal solution would be to make personal information available through a unique gateway. The Digital Persona (DP) project, done at the IBM Research - Almaden, represents such a gateway to personal information [Kelin99] . By separating the personal information storage from the OPA, the usage of a personal OPA is not limited to the computer which runs the OPA. Instead, a networked solution would allow the use of an OPA on any machine. Preliminary experiments involving the use of an OPA in conjunction with a DP were successful but there is still a lot of work that needs to be done.
According to [Camp97] , privacy requires security, because without the ability to control access to and distribution of information, privacy cannot be protected. This starts with a secured transfer of the information. There are already several mechanisms available which can protect the transfer of data, such as SSL or PGP. The OPA's current implementation lacks the ability to support these mechanisms, for example SSL, because the OPA is a proxy. This proxy is positioned between the Web browser and the Web and monitors all data traffic between the browser and the Web. This approach works fine when the connection between the browser and Web server is not encrypted. If a browser and a Web server establish a secure connection (e.g., by using SSL), all the proxy does is forward requests and responses. In other words, the proxy tunnels SSL  . The ability to monitor and evaluate the information sent between the browser and Web server is lost.
If P3P becomes a standard, we expect the next generation of browsers to incorporate some or all of the OPA's features. However, until then it would add value to the OPA if it could handle SSL-encrypted connections. In SSL, once the client establishes contact with a server, the server sends it a server certificate containing information about the server as well as its public key. In order to make sure that this certificate is really from whom the user thinks it is, a server certificate is often signed (digitally) by a certificate agency (CA). These agencies attest that this public key is indeed the public key of this site. The CA in turn is certified by a CA certificate, which contains similar information as the server certificate but for the CA. Popular CAs are Verisign  and Thawte Consulting  , to whom a server operator submits the server's certificate (and some other form of identification) once, and in turn receives a signed version of it.
In order to support SSL in a proxy, the OPA needs to be its own CA, meaning that it will send its CA certificate to the user once an SSL connection is requested. 1 The proxy can then dynamically create a server certificate, certifying that the proxy is actually the server the user wants to connect to. The proxy will then establish its own connection to the server. To summarize, instead of having one secure connection between the browser and the server, there will be two secure connections: one between the browser and the proxy, and one connection between the proxy and the server.
The OPA in its current implementation allows a user to specify his preferences by using APPEL. On a technical level, we have described how APPEL files are structured and how rules can be specified, following the given APPEL syntax. Currently, the user of an OPA has to manually write and maintain such a file. With the available APPEL package  , it is then possible to check whether a file represents a valid APPEL file. However, this is not an appropriate interface for a person to use when defining his preferences. Especially not for the ordinary user because it requires technical knowledge about APPEL and XML. Instead, we envision helper applications that let users define their preferences through a graphical user interface (GUI). These applications would hide the technical details of APPEL and lead the user through the process of defining a ruleset. In addition to this, we expect such applications to detect conflicts between certain types of rules.
We defined and explained a rather general framework for the automated negotiation of sets of information. We have also shown how this framework can be applied in the context of online transactions and privacy, and how this adds value to the OPA's implementation. Due to time constraints and the inability to test our negotiation scheme against a wide variety of Web services, there are several issues that need further research. When we started this project, the P3P specification included a framework for multi-round negotiation. This was recently removed from the P3P specification because the W3C expected it to be too complicated and did not see a reason for having such a feature. However, we see the ability to negotiate as an advanced feature for online transactions. Moreover, we have shown in this thesis that negotiation can be implemented with reasonable efforts on the basis of the existing protocols. If P3P is not going to support multi-round negotiation, a new protocol must be defined in order to communicate during the negotiation. Languages and protocols to consider are the Knowledge Interface Format (KIF)  and the Knowledge Query Manipulation Language (KQML)  .
A second large research topic is that of forms of negotiation and the modeling and application of negotiation strategies in automated negotiation. For example, the simplest form of negotiation is the ability to send proposals between the negotiation parties which can then either accept or reject a proposal. A more sophisticated approach is the ability to offer counter-proposals as a response to a proposal, which is the approach we are using with the OPA. The OPA's strategy is based on the importance of individual aspects of transactions to the user. An even more elaborate form of negotiation is the argumentation-based form of negotiating [Sierra97] . In this form of negotiation, parties are able to send justifications or arguments along with (counter) proposals in order to indicate why the proposals should be accepted. It would be very interesting to incorporate argumentation-based negotiation into online transactions.
Last but not least, in order to prove that our framework for negotiating sets of information is useful, it would be very interesting to see how it is used in contexts other than P3P transactions. We believe that this framework can be used to enhance the negotiation capabilities of existing systems, which are currently limited to negotiating the price of an item.