Title: RECOMMENDER MODULE

The Recommender Module is mainly responsible for carrying out information filtering processes, according to the protocol described in . The participating entities are realized as agents, and the interactions as agent services. Mechanisms for secure agent communication are assumed to be available within the respective MAS architecture. Two issues have to be addressed in this module: The relevant parts of the provider profile have to be retrieved without compromising the user’s privacy, and the recommendations have to be propagated in a privacy-preserving way.

The solution is based on a threat model in which no main abstract entity may safely assume any other abstract entity to act in an honest manner: Each entity has to assume that other entities may attempt to obtain private information, either while following the specified protocol or even by deviating from the protocol. Following (Goldreich, 1987), the former case is classified as honest-but-curious behavior (as an example, the TFE may propagate recommendations as specified, but may additionally attempt to propagate private information), and the latter case as malicious behavior (as an example, the filter may attempt to propagate private information instead of the recommendations). 

Retrieving the Provider Profile 

As outlined above, the relay agent relays data between the TFE agent and the provider agent. These agents are not allowed to communicate directly, because the TFE agent cannot be assumed to act in an honest manner. Unlike the user profile, which is usually rather small, the provider profile is often too voluminous to be propagated as a whole efficiently. A typical scenario consists of a user profile containing ratings of about 100 movies, and a provider profile containing some 10,000 movies. Retrieving only the relevant part of the provider profile, however, is problematic because it has to be done without leaking sensitive information about the user profile. Therefore, the relay agent has to analyze all queries on the provider profile, and reject potentially critical queries, such as queries containing a set of user profile items. Because the propagation of single unlinkable user profile items is assumed to be uncritical, the information filtering protocol is extended as follows: The relevant parts of the provider profile are retrieved based on single anonymous interactions between the relay and the provider. If the MAS architecture used for the implementation does not provide an infrastructure for anonymous agent communication, this feature has to be provided explicitly:  

Table The basic information filtering protocol with participants U = user agent, P = provider agent, F = TFE agent, R = relay agent, based on the abstract protocol shown in Figure 28. UP denotes the user profile with UP = {up1, .., upn}, PP denotes the provider profile, and REC denotes the set of recommendations with REC = {rec1, .., recm}.

The most straightforward way is to use additional relay agents deployed via the main relay agent and used once for a single anonymous interaction. Obviously, unlinkability is only achieved if multiple instances of the protocol are executed simultaneously between the provider and different users. Because agents on controlled platforms are unable to communicate anonymously with the respective controlling agent, control has to be established after the anonymous interactions have been completed. To prevent the uncontrolled relay agents from propagating provider profile data, the respective data is encrypted and the key is provided only after control has been established. Therefore, the second phase of the protocol described in is replaced as described in . Additionally, the relay agent may allow other interactions as long as no user profile items are used within the queries. In this case, the relay agent has to ensure that the provider does not obtain any information exceeding the information deducible via the recommendations themselves. The cluster-based filtering technique described in Section is an example for a filtering technique operating in this manner.

Table The updated second stage of the information filtering protocol with definitions as above. PPq is the part of the provider profile PP returned as the result of the query q.

Recommendation Propagation 

The propagation of the recommendations is even more problematic mainly because more participants are involved: Recommendations have to be propagated from the TFE agent via the relay and provider agent to the user agent. No participant should be able to alter the recommendations or use them for the propagation of private information. Therefore, every participant in this chain has to obtain and verify the recommendations in unencrypted form prior to the next agent in the chain, i.e. the relay agent has to verify the recommendations before the provider obtains them, and so on. Therefore, the final phase of the protocol described in is replaced as described in . It basically consists of two parts (Step 3.1 to 3.4, and Step 3.5 to Step 3.8), each of which provide a solution for a problem related to the prisoners’ problem described in (Simmons, 1984), in which two participants (the prisoners) intend to exchange a message via a third, untrusted participant (the warden) who may read the message but must not be able to alter it in an undetectable manner. There are various solutions for protocols addressing the prisoners’ problem. The more obvious of these, however, such as protocols based on the use of digital signatures, introduce additional threats e.g. via the possibility of additional subliminal channels. In order to minimize the risk of possible threats, the described approach uses a protocol that merely requires a symmetric encryption scheme.

The first part of the final phase is carried out as follows: In order to prevent the relay from altering recommendations, they are propagated by the filter together with an encrypted hash in Step 3.1. Thus, the relay is able to verify the recommendations before they are propagated further. The relay, however, may suspect the data propagated as the encrypted hash to contain private information instead of the actual hash value. Therefore, the encrypted hash is encrypted again and propagated together with a hash on the respective key in Step 3.2. In Step 3.3, the key K_PF is revealed to the relay, allowing the relay to validate the encrypted hash. In Step 3.4, the key K_R is revealed to the provider, allowing the provider to decrypt the data received in Step 3.2 and thus to obtain H(REC). Propagating the hash of the key KR prevents the relay from altering the recommendations to REC’ after Step 3.3, which would be undetectable otherwise because the relay could choose a key K_R’ so that H(REC)}K_PF }K_R H(REC’)}K_PF}K_R’ . The encryption scheme used for encrypting the hash has to be secure against known-plaintext attacks, because otherwise the relay may be able to obtain K_PF after Step 3.1 and subsequently alter the recommendations in an undetectable way. Additionally, the encryption scheme must not be commutative for similar reasons.

The remaining protocol steps are interactions between relay, provider and user agent. The interactions of Step 3.5 to Step 3.8 ensure, via mechanisms similar to those used in Step 3.1 to 3.4, that the provider is able to analyze the recommendations before the user obtains them, but at the same time prevent the provider from altering the recommendations. Additionally, the recommendations are not processed at once, but rather one at a time, to prevent the provider from withholding all recommendations. Upon completion of the protocol, both user and provider have obtained a set of recommendations. If the user wants these recommendations to be unlinkable to him, the user agent has to carry out the entire protocol anonymously. Again, the most straightforward way to achieve this is to use additional relay agents deployed via the user agent which are used once for a single information filtering process. 

Table The updated final stage of the information filtering protocol with definitions as above.