Title: OUTLINE OF THE SOLUTION

The basic idea for realizing a protocol fulfilling these privacy-related requirements in recommender systems is implied by allowing the temporary acquisition of private information: User and provider entity both propagate the respective profile data to the filter entity. The filter entity provides the recommendations, and subsequently deletes all private information, thus fulfilling the requirement regarding permanent acquisition of private information. 

The entities whose private information is propagated have to be certain that the respective information is actually acquired temporarily only. Trust in this regard may be established in two main ways: 

1. Trusted Software: The respective entity itself is trusted to remove the respective information as specified.

2. Trusted Environment: The respective entity operates in an environment that is trusted to control the communication and life cycle of the entity to an extent that the removal of the respective information may be achieved regardless of the attempted actions of the entity itself. Additionally, the environment itself is trusted not to act in a malicious manner (e.g. it is trusted not to acquire and propagate the respective information itself).

In both cases, trust may be established in various ways. Reputation-based mechanisms, additional trusted third parties certifying entities or environments or Trusted Computing mechanisms may be used. This approach is based on a trusted environment realized via Trusted Computing mechanisms, because this solution constitutes the most generic and realistic approach. This decision and its realization are discussed in section .

The abstract information filtering protocol as shown in Figure 28 consists of the following steps: The filter entity deploys a Temporary Filter Entity (TFE) operating in a trusted environment. The user entity deploys an additional relay entity operating in the same environment. Through mechanisms provided by this environment, the relay entity is able to control the communication of the TFE, and the provider entity is able to control the communication of both relay entity and the TFE. Thus, it is possible to ensure that the controlled entities are only able to propagate recommendations, but no other private information. In the first stage (steps 1.1 to 1.3 of Figure 28), the relay entity establishes control of the TFE, and thus prevents it from propagating user profile information. User profile data is propagated without participation of the provider entity from the user entity to the TFE via the relay entity. In the second stage (steps 2.1 to 2.3 of Figure 28), the provider entity establishes control of both relay and TFE, and thus prevents them from propagating provider profile information. Provider profile data is propagated from the provider entity to the TFE via the relay entity. In the third stage (steps 3.1 to 3.5 of Figure 28), the TFE returns the recommendations via the relay entity, and the controlled entities are terminated. Taken together, these steps ensure that all private information is acquired temporarily only by the other main entities. The problems of determining acceptable queries on the provider profile and ensuring unlinkability of the recommendations are discussed in the following section. 

This approach requires each entity in the distributed architecture to have the following five main abilities: The ability to perform certain well-defined tasks (such as carrying out a filtering process) with a high degree of autonomy, i.e. largely independent of other entities (e.g. because the respective entity is not able to communicate in an unrestricted manner), the ability to be deployable dynamically in a well-defined environment, the ability to communicate with other entities, the ability to achieve protection against external manipulation attempts, and the ability to control and restrict the communication of other entities. 

Figure The abstract privacy-preserving information filtering protocol. All communication across the environments indicated by dashed lines is prevented with the exception of communication with the controlling entity.

MAS architectures are an ideal solution for realizing a distributed system characterized by these features, because they provide agents constituting entities that are actually characterized by autonomy, mobility and the ability to communicate, as well as agent platforms as environments providing means to realize the security of agents. In this context, the issue of malicious hosts, i.e. hosts attacking agents, has to be addressed explicitly. Furthermore, existing MAS architectures generally do not allow agents to control the communication of other agents. It is possible, however, to expand a MAS architecture and to provide designated agents with this ability. For these reasons, this architecture is based on a FIPA-compliant MAS architecture. The entities introduced above are mapped directly to agents, and the trusted environment in which they exist is realized in the form of agent platforms.

In addition to the MAS architecture itself, which is assumed as given, the architecture consists of the following five main modules: 

1. The Controller Module described in Section provides functionality for controlling the communication capabilities of agents.

2. The Transparent Persistence Module facilitates the use of different data storage mechanisms, and provides a uniform interface for accessing persistent information, which may be utilized for monitoring critical interactions involving potentially private information e.g. as part of queries. Its description is outside the scope of this document.

3. The Recommender Module, details of which are described in Section , provides recommender system functionality.

4. The Matchmaker Module provides matchmaker system functionality. It additionally utilizes social aspects of MAS technology. Its description is outside the scope of this document.

5. Finally, a separate module described in Section provides exemplary filtering techniques mainly in order to show that various restrictions imposed on filtering techniques by this approach may actually be fulfilled. These filtering techniques may be used as the foundation for more advanced algorithms to be applied in real-world recommender systems.

The trusted environment introduced above encompasses the MAS architecture itself and the Controller Module, which have to be trusted to act in a non-malicious manner in order to rule out the possibility of malicious hosts. 

Main Modules and Implementation

This section describes the main modules of the architecture for privacy-preserving information filtering, and outlines the implementation. While a specific MAS architecture has been chosen for the implementation, the specification of the module is applicable to any FIPA-compliant MAS architecture. A module basically encompasses ontologies, functionality provided by agents via agent services, and internal functionality. Regarding the terminology used in the following, {m}K_X denotes a message m encrypted via a non-specified symmetric encryption scheme with a secret key K_X used for encryption and decryption which is initially known only to participant X. A key K_XY is a key shared by participants X and Y. A cryptographic hash function is used at various points of the protocol, i.e. a function returning a hash value h(x) for given data x that is both preimage-resistant and collision-resistant. A set of hash values for a data set X = {x1, .., xn} is denoted as H(X) = {h(x1), .., h(xn)}, whereas h(X) denotes a single hash value of the entire data set X.