Bhavesh Borisaniya
email: borisaniyabhavesh@gmail.com

Avi Patel

Dhiren Patel
email: dhiren29p@gmail.com

Hiren Patel

Incorporating Honeypot for Intrusion Detection in Cloud Infrastructure

Keywords: Cloud Computing, Intrusion Detection System, Honeypot, Eucalyptus IaaS framework

Cloud services delivered as utility computing over the Internet makes it an attractive target for cyber intruders. Protecting network accessible Cloud resources and services from ever increasing cyber threats is of great concern. Most of the Network based Intrusion Detection System (NIDS) being rule based and therefore only capable of identifying known attacks (through pattern matching). Traditional Anomaly Detection based IDS may generate more number of false positives. In this paper, we attempt to amalgamate IDS with Cloud computing. Introducing Honeypot in Cloud IDS design can greatly help in detecting potential attacks with reduced number of false positives. This research work provides an impetus to strengthen network security aspects related to Cloud computing to make it more trustworthy.

Introduction

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (such as server, storage, applications, services etc.) that can be rapidly provisioned and released with minimal management effort or service provider interaction [START_REF] Grance | The nist definition of cloud computing[END_REF]. It is a major aid for start-ups offering online applications and services without investing much in storage, Web, or computing infrastructure. Using known Internet protocols, standards and formats; Cloud computing exposes a set of consumable services delivered to end-users/consumers. These services range from computing utilities to platforms for application development.

Need for Security in Cloud

Cloud services are executed on the Cloud provider's site along with data. These require large amount of data to be transferred over the network. Cloud providers have to ensure about the quality of service, performance, reliability and basic security [START_REF] Roschke | Intrusion detection in the cloud. Dependable, Autonomic and Secure Computing[END_REF].

If an intruder gains unwanted access to Cloud services, he may also exploit the underlying architecture. In case of IaaS, the intruder may also be able to exploit the Virtual machine monitor (VMM) by using vulnerabilities in the implementation. Penetration to the hardware layer may allow an attacker to compromise any VM provided by the infrastructure.

Because of its provisioning through the Internet and vulnerabilities in involved (underlying) technologies; there are many issues related to security of Cloud infrastructure and its services. Major threats to Cloud computing includes insecure interface and APIs of shared technology, account and service hijacking [START_REF]Top threats to cloud computing[END_REF] etc. Shared and distributed resources in the Cloud system make it difficult to develop a security model for detecting intrusion and ensuring the data security and privacy in Cloud. Because of transparency issue, no Cloud provider allows its customers to implement intrusion detection or security monitoring system extending into the management services layer providing back channel behind virtualized Cloud instances. IDS technology has been tested to be capable of working well in some large scale networks, however, its utilization and deployment in Cloud Computing is still a challenging task [START_REF] Roschke | Intrusion detection in the cloud. Dependable, Autonomic and Secure Computing[END_REF].

Intrusion Detection Systems (IDS)

Intrusion detection systems have proved to be a major tool for network administrators to protect their internal network from threats of cybercriminals and also of internal threats. A Common Intrusion Detection Framework (CIDF) which illustrates a general IDS architecture, based on the consideration of four types of functional modules as shown in Figure 2 [START_REF] Garca-Teodoro | Anomalybased network intrusion detection: Techniques, systems and challenges[END_REF].

Fig. 2. Common Intrusion Detection Framework

The components of this IDS framework include the following: E blocks (Event-boxes): These blocks contain sensor elements that monitor the target system and gather information events that can be analyzed by other blocks. D blocks (Database-boxes): These are the blocks intended to store information from E blocks for subsequent processing by A and R boxes. A blocks (Analysis-boxes): These are the processing modules which analyze the events and detect the potential hostile behaviour, so that some kind of alarm will be generated if necessary. R blocks (Response-boxes): If any intrusion occurs, this block is responsible to provide a response to prevent the detected threat.

Network based IDS (NIDS) detects the intrusion by monitoring malicious activity in network traffic while Host based IDS (HIDS) inspects the unusual activity within the host by monitoring its file system.

Most of the NIDSs monitor network traffic and match it with the dataset of predefined attack patterns(signatures) to detect the attacks. For network intrusion detection, a signature can be as simple as a specific pattern that matches a portion of a network packet. However, signature-based technique fails to detect the unknown or new attacks whose signatures are not defined or not included in the dataset of signatures.

An anomaly based IDS establishes a baseline of normal usage patterns, and anything that widely deviates from it gets flagged as a possible intrusion [START_REF] Marinova-Boncheva | A short survey of intrusion detection systems[END_REF]. A large number of false positives can limit this technique which can force it to sign even a genuine activity as an intrusion attempt.

The objective is to build efficient IDS which can work in Cloud environment with the capability of detecting known and unknown intrusions. The IDS must also prove to be a tool to the user to detect if the used-service or hosts are used to attack other victims.

The rest of the paper is organized as follows: In section 2, related work is reported. Section 3 discusses important design considerations for deploying IDS in Cloud. Section 4 discusses our approach to implement NIDS along with honeypot in Cloud framework. Section 5 describes implementation details using Eucalyptus Cloud framework and section 6 discusses experiments and results. We conclude in section 7 with references at the end.

Related Work

There has been relevant work done in the field about IDS for Cloud computing. The major approaches are listed as follows:

Sebastian Roschke et al. [START_REF] Roschke | Intrusion detection in the cloud. Dependable, Autonomic and Secure Computing[END_REF] points the need for deploying IDS in the Cloud by proposing extensible IDS architecture which can be used in a distributed Cloud infrastructure.

Noah Guilbault and Ratan Guha [START_REF] Guilbault | Experiment setup for temporal distributed intrusion detection system on amazon's elastic compute cloud[END_REF] shows a way for designing and implementing distributed grid based IDS using virtual servers deployed on Amazon's Elastic Compute Cloud service. Aman Bakshi et al. [START_REF] Bakshi | Securing cloud from ddos attacks using intrusion detection system in virtual machine. Communication Software and Networks[END_REF] proposed a framework for securing Cloud from DDoS attacks using an IDS in a virtual machine. This can be done by employing intrusion detection sensors installed in a virtual machine to sniff network traffic and to analyze packets over the Internet using Snort. Both these approaches incorporate IDS in each virtual machine, requires as many IDS as number of running virtual machine instances. Claudio Mazzariello et al. [START_REF] Mazzariello | Integrating a network ids into an open source cloud computing environment[END_REF] has placed Snort as a NIDS on the virtual switch component of the physical machine. This physical machine hosts virtual machines of clients using open source Eucalyptus cloud computing framework. Virtual Switch enables the NIDS to monitor all in-bound and out-bound traffic from the entry-point. Chi-Chun Lo et al. [START_REF] Lo | A cooperative intrusion detection system framework for cloud computing networks[END_REF] proposed a cooperative IDS framework for Cloud computing networks to reduce DDoS attacks. All these approaches use signature based technique, limited to detect only known attacks.

Kleber Vieira et al. [START_REF] Vieira | Intrusion detection for grid and cloud computing[END_REF] have described an intrusion detection based on Grid and Cloud computing system which can identify unknown as well as known attacks. However, this approach is only suitable for PaaS.

Design Considerations

Deploying IDS in the Cloud is a tricky issue. From the users' perspective, they need to make sure that the service they use is not subjected to any kind of attack. They should also know whether these services are being used to attack other hosts or not. On the other hand, Cloud providers need to ensure if its infrastructure is subjected to any attack or not. With knowledge of attacks and their behavior, the provider should be prompted to take appropriate actions.

In order to justify our approach and make it useful for a Cloud environment, we explored various Cloud frameworks for implementing IaaS as a service model and configure them for analysis in our lab environment. There are several opensource frameworks for Cloud computing viz; Eucalyptus [START_REF]Eucalyptus[END_REF], OpenNebula [START_REF] Opennebula | [END_REF], Globus Nimbus [START_REF] Nimbus | [END_REF] etc. Amongst them, we have zeroed into Eucalyptus because it provides simpler interface, supports different virtual machine monitors (or hypervisors) and modular architecture, which provides us an easy alternative to incorporate honeypot with IDS.

Network based intrusion detection tools are usually deployed over a perimeter of an organization network in order to monitor inbound and outbound network traffic. We have looked at various intrusion detection tools chosen Snort [START_REF]Snort, network intrusion detection and prevention system[END_REF], as it is configurable, widely used and constantly updated. We have augmented the simple honeypot to a dynamic honeypot and incorporated it into our proposed approach. For testing the proposed architecture, we have setup a configurable private Cloud using Eucalyptus framework. We have created and tested the installed machine images of different operating systems which can be delivered as virtual machine instances with different configurations (RAM and CPUs) to the Cloud users in context of private Cloud.

Eucalyptus Architecture

Figure 3 shows the Eucalyptus Cloud architecture containing various components [START_REF] Nurmi | The eucalyptus open-source cloud-computing system[END_REF][START_REF] Nurmi | A technical report on an elastic utility computing architecture linking your programs to useful systems[END_REF]. Each high-level system component in the Eucalyptus design is implemented as a stand-alone Web service. These Web services expose a well defined language-agnostic API in the form of a WSDL (Web Service Descriptive Language) document, which contains operations that the service can perform and input/output data structures. It also support secure communications using WS-Security policies and rely upon industry-standard Web services software packages like Axis2, Apache and Rampart [START_REF] Nurmi | The eucalyptus open-source cloud-computing system[END_REF][START_REF] Nurmi | A technical report on an elastic utility computing architecture linking your programs to useful systems[END_REF].

Basic Components of Eucalyptus Architecture and their functions are summarized in Table 1. Eucalyptus provides a functionality called security groups which acts as a firewall for running machine instances. It is a named collection of network access rules, defining which incoming traffic is delivered to instances. A user can add or remove a security group to meet his security requirement. By using this, a user can open or close ports to control the inbound or outbound network traffic over it. By restricting the number of open ports in an instance; a user can only decrease the probability of an attack to some extent. If the services running on these ports are vulnerable, then its easy for an intruder to exploit it.

Placement of a NIDS in Eucalyptus based private Cloud

Figure 4 shows the architecture of the system which comprises the NIDS. We have placed the NIDS in each Cluster Controller to monitor the network traffic of all the Node Controllers which report to the respective CC. NIDS will capture all the packets passing through the CC intended to the instances hosted by NCs and examine them for the malicious content. If malicious content is found, it generates alerts and logs that network activity into the central database. The Cloud administrator can view and analyze these logged alerts and network activities (i.e. packets) by accessing the database. Also, the owner of the instance can analyze the logged attack alerts related to it by querying the central database using interface through the instance.

This approach allows the Cloud administrator (Instance provider as well as instance owner) to monitor the type and source of the attack, which in turn can be used to prevent the similar future attacks.

Use of Honeypot

A honeypot is a deception system which allures the attackers. It has no production value and is intended to be compromised. All the traffic sent to a honeypot is almost certainly unauthorized meaning no false positives, false negatives or large data sets to analyze [START_REF] Mokube | Honeypots: concepts, approaches, and challenges[END_REF]. Any connection with honeypot can be considered as an attack and an attacker who breaks into a honeypot is comprehensively monitored. Honeypots are serving several purposes that include the following [START_REF] Mokube | Honeypots: concepts, approaches, and challenges[END_REF]:

1. They can distract attackers from more valuable machines on a network. 2. They can provide early warning about new attack and exploitation trends. 3. They allow in-depth examination of adversaries during and after exploitation of a honeypot.

In our approach, honeypot plays an important role. Any attempt to access honeypot is labeled as an attack.

Proposed Approach: Incorporating a Honeypot in Eucalyptus based private Cloud

Unknown attacks, for which signatures are not available, have to be dealt with caution and it requires a more efficient IDS mechanism. In our approach, we have incorporated a honeypot to enhance the working of a NIDS in a Cloud environment. The introduction of a honeypot allows identification of suspicious activities by monitoring those network packets which were previously marked as non-suspicious by a normal NIDS. In order to deploy a honeypot in a Cloud environment, we have considered a design in which the administrator launches instances through the honeypot manager. Honeypot manager is an administrative tool used for managing honeypot instances, which are made vulnerable and attractive for intruders to exploit (by running various services accessible through the Internet through open ports).

Figure 5 shows the NIDS incorporating a honeypot in a Cloud architecture. We have shown two such machine instances which work as honeypot. These instances have no production value and hence any inbound or outbound network activity with these instances is considered as malicious. Any packet passing through CC intended for honeypot machine instances will be captured by a packet sniffer and logged into the central database for later analysis. Here, NIDS is placed in CC to listen the traffic intended for instances and generates (and logs) the alerts to the central database if any malicious activity is found. A packet sniffer sniffs and logs all network packets related to the honeypot instances in the central database.

All packets intended towards honeypot instances, also passes through NIDS. As cloud provider is not delivering honeypot instances to any client, any activity towards it can be considered as malicious. Hence, by querying the database for activities which are captured by honeypots and passed through NIDS, we are able to find such activities/attacks, which were not detected earlier. From these logged activities, we can find information like source (IP) of attack and services they are trying to access using destination and source port. Figure 6 depicts this intrusion detection process flow diagram.

The compromised honeypot instance image can also be used as a means to learn new ways, tools and methods to get into the system. It is also helpful to understand the motive of attacker, to avoid the future attacks and to make the existing NIDS more efficient. The compromised honeypot instance image can also be used as a means to learn new ways, tools and methods to get into the system. It is also helpful to understand the motive of attacker, to avoid the future attacks and to make the existing NIDS more efficient.

Implementation Issues

Figure 7 shows the experimental setup of a Eucalyptus private Cloud with the proposed framework of NIDS.

Our setup consists of three machines, a Node Controller (NC), a Cloud Controller (CLC) and a machine consisting of both Storage Controller (SC) and Cluster Controller (CC). We have used a separate cluster controller (i.e. SC and CC) and database server (i.e MySQL) on different machines. They can also be Snort is configured in the CC machine along with a packet sniffer, while the Honeypot Manager is placed in the CLC. A set of machine images of different OS is used to create the honeypot in our environment. Under ideal circumstances, it should cover machine images of all the OS, whose instances are provided by the Cloud provider. These images are made in a way that can attract the attackers.

In our experiments we have used machine images of Windows XP, Windows Server 2003 and Ubuntu 10.04. The central database contains the information of machine images that can be used to launch as honeypot instances. It also maintains the information of the fake Cloud users (for experimentation) like their username and credentials that can be used to run the honeypot instances with different instance ownership.

The honeypot manager is responsible for launching the honeypot instances. It gathers the information about the operating system and the state of open and closed ports for different services for all instances. Accordingly, the honeypot manager schedules the type of operating system to be used as a honeypot. The honeypot manager launches each machine instance of a different OS having the ownership of fake users. It also opens different ports for vulnerable services through a security group mechanism to make it more attractive. These machine instances are not delivered to normal users and also its owners credentials are only with the Cloud administrator (nobody can access these instances directly).

Hence, any connectivity with these machine instances can be considered malicious.

A packet sniffer captures all the network packets which pass through the CC whose source or destination IP is one of the honeypot IPs. It logs all the captured packets into the central database. Snort examines those packets that are sniffed by the packet sniffer and generates alerts if it finds a known attack pattern within the packet content.

Controlled monitoring of vulnerable images can assist the behavioral analysis of an intruder. Vulnerable images are crafted to exploit with absolute zero or no security and placed in a DMZ. These images are monitored periodically for intrusion attempts. In case of an intrusion, an alert is reported on the primary basis. A local cache directory can be included on top of the Cloud architecture which saves copies of vulnerable images periodically on a version basis. Careful analysis can be done of these vulnerable images to record intruder activity and to enhance the security of the Cloud architecture there after using appropriate security measures.

Experiments and Results

We have used Snort as a NIDS and launched vulnerable machine instances to work as honeypots. In order to compare the vulnerability in both original as well as vulnerable copies of operating system images, we conducted a scan using Nessus by enabling all available plug-in modules. The statistics collected are shown in Table 2. Nessus and Metasploit send bad packets in order to find vulnerabilities and exploit them. Then we compared the alerts generated by Snort and honeypot in response to the attacks made by each tool.

Figure 8 shows the graphical representation for the comparison of the total number of logged packets by the honeypot and Snort. In order to verify the results, we formally developed a web application which gives the details of intrusion attempts logged by Snort as well as the honeypot. Screen shot of this web application is shown in Figure 9.

Conclusion

By incorporating honeypot, the proposed IDS for Cloud not only alerts the users (about possible network attacks) but also helps Cloud administrator to monitor unknown attacks to enhance its Intrusion Prevention Strategy. The proposed system can be implemented in a Cloud environment to make it more trustworthy by providing an intrusion alert mechanism for attacks against Cloud.

The core benefits of the proposed approach are:

1. It can detect known as well as potential unknown attacks.

2. Controlled use of honeypot generates less number of false alarms for unknown attacks making it an efficient solution for intrusion detection specific to private Cloud.

Though, the proposed scheme is implemented with a Eucalyptus framework, it may work well for other Cloud platforms. It can serve as model to study the behavior of NIDS for distributed environment.

Fig. 1 .

 1 Fig. 1. Cloud computing

Fig. 3 .

 3 Fig. 3. Eucalyptus Cloud Architecture

Fig. 4 .

 4 Fig. 4. Architecture of Eucalyptus Private Cloud with NIDS

Fig. 5 .

 5 Fig. 5. Architecture of intrusion detection system using honeypot in Eucalyptus Cloud

Fig. 6 .

 6 Fig. 6. Intrusion detection process in proposed framework

Fig. 7 .

 7 Fig. 7. Experimental Setup for NIDS using Honeypot in Cloud

Fig. 8 .

 8 Fig. 8. Comparison of total number of packets logged by Snort and Honeypot in Cloud environment

Fig. 9 .

 9 Fig. 9. Web application(screen shot) for analyzing proposed system

Table 1 .

 1 Eucalyptus Components

	No Component	Function
	1 Cloud Controller(CLC)	High level Scheduling decisions
	2 Node Controller(NC)	Management of Virtual machine instances and its execution
	3 Cluster Controller(CC)	Scheduling of Virtual Machine execution on specific hosts
		and Virtual network management
	4 Storage Controller(SC)	Storage of user data as well as storage service for
		Virtual Machine Images

Table 2 .

 2 Nessus vulnerability scan result of machine images

	Operating System Machine Instance Total High Medium Low Open Port
	Windows XP	Original	20	0	2	14	4
		Vulnerable	48	0	5	29	14
	Windows 2003 Server Original	11	0	1	8	2
		Vulnerable	32	5	1	18	8
	Ubuntu 10.04	Original	21	0	0	17	4
		Vulnerable	64	1	2	43	18

We launched two instances of each operating system (i.e. Windows XP, Windows 2003 and Ubuntu 9.10) in the Cloud and opened the required ports for the services that run on different operating system instances using security group. Honeypot manager also launches instances of the vulnerable images relative to these operating systems.

We attacked all the nine machine instances (3 for each operating system -2 normal and 1 launched by the honeypot manager) using Nmap, Nessus and Metasploit to test the designed system. Nmap scans all the open ports while


Audun Jøsang
email: josang@mn.uio.no

Robustness of Trust and Reputation Systems: Does it Matter?

Trust and reputation systems provide a foundation for security, stability, and efficiency in the online environment because of their ability to stimulate quality and to sanction poor quality. Trust and reputation scores are assumed to represent and predict future quality and behaviour and thereby to provide valuable decision support for relying parties. This assumption depends on two factors, primarily that trust and reputation scores faithfully reflect past observed quality, and secondly that future quality will be truly similar to that represented by the scores. Unfortunately, poor robustness of trust and reputation systems often makes it relatively easy to manipulate these factors, so that the fundamental assumption behind trust and reputation systems becomes questionable. On this background we discuss to what degree robustness against strategic manipulation is important for the usefulness of trust and reputation systems in general.

Introduction

Online markets and communities are commonly moderated by trust and reputation systems, called TRS hereafter. The explosion in the use of collaborative trust and reputation propagation was triggered primarily by the speed and efficiency of the Internet and modern computers for collecting and propagating reputation information, and secondly by the emergence of Web 2.0 platforms and people's active engagement in them. Through collaborative effort members of the community provide ratings and reviews about targets which e.g. can be online services and resources as well as other community members and physical world goods and service, for example hotels, universities and medical doctors [START_REF] Jøsang | Online Reputation Systems for the Health Sector[END_REF]. Cumulated ratings and reviews about a given target can assist other parties in deciding whether or not to use, transact with or connect with that target in the future. Introducing such systems in a community or market has multiple interrelated effects. The most direct effect is that it provides decision support for relying parties, by choosing the targets with the best scores or reviews. Targets that want to attract the business of relying parties in the future know that they need a high reputation score for that. The principle that future reputation depends on present behaviour typically influences present behaviour through the "shadow of the future" effect [START_REF] Resnick | Reputation Systems[END_REF], meaning that anticipated future reputation casts a controlling shadow on present behaviour.

A trust scope refers to the specific function or quality that the target is assumed to have for the purpose of the trust relationship. In other words, the target is relied upon to have certain qualities, and the scope is what the relying party assumes those qualities to be. For example, providing financial advice and providing medical advice represent two different scopes for which trust and reputation should be considered separately. Trust and reputation also exist within a context. It should be noted that the term context is sometimes used in the sense of scope in the literature.

The term "context" generally means the surroundings, circumstances, environment, background or settings which determine, specify, or clarify the meaning of something. We therefore define trust context to cover elements such as the legal and cultural environment, the domain policy, ethics and social attitudes of participants. A specific online market or social community such as eBay or facebook is always embedded in a wide context that consists of the above mentioned elements as well as others. The context of a TRS can therefore take a rather general meaning that would difficult to specify exhaustively. It would be practical to consider a domain identity such as "eBay" or "facebook" as an attribute of, or maybe the name/identifier of the context itself, because it indirectly refers to all its elements such as those elements mentioned above.

Another aspect of trust context is that two communities might use the same term for a specific trust scope such as "politeness", but the meaning could have different qualitative and semantic value if the two communities have different cultures. A simple way to convey this fact might be to include the name of the community/context as metadata or as an attribute of specific reputation scores. Another issue worth considering when comparing different TRS domains is the possibility that participants deliberately behave differently in specific different communities, so that it would not be meaningful to compute an average/federated reputation score for a specific participant who behaves in that way. In fact the community name becomes an attribute of the behaviour, i.e. the participant consciously behaves in a specific way in each different community and context. It would be possible for the participant to use the same name in the different communities so that relying parties would be aware of the difference in behaviour, or the participant could use different pseudonyms so that relying parties would ignore that two separate pseudonyms represent the same participant.

In relation to trust systems the term "recommendation" is often used in the sense of a trust measure passed between entities, whereas the term "rating" is often used with relation to reputation systems. In this presentation we will use the term "rating" to denote both. The term "score" primarily refers to a measure of trust or reputation derived by a TRS function based on the received ratings.

Many web sites allow participants to write reviews in natural language, not just as a numerical rating. For generality we will use the term "rating" also in the sense of a review. Similarly, we let the term "'score" also represent the collection of reviews that are presented to the public through a website, not just a numerical trust or reputation score.

Attempts to misrepresent quality and to manipulate reputation are commonplace in human societies, and probably also in animal societies. Con artists employ methods to appear trustworthy, e.g. through skillful acting or through the fabrication and presentation of false credentials. Analogous types of attacks are being used in online communi-ties and markets. In case of online TRSs, vulnerabilities in the systems themselves can open up additional attack vectors. From that perspective TRSs should be robust against attacks that could lead to misleading trust and reputation scores. In the worst case, a vulnerable reputation system could be turned around and used as an attack tool to maliciously manipulate the computation and dissemination of scores. The consequence of this could be a total loss of community trust caused by the inability to sanction and avoid low quality and deceptive services and agents.

Attacks against TRSs are not normally committed by computer hackers breaking into the server where the TRS functions are being hosted, although of course this could happen. Attacks against TRSs typically consist of playing the role of relying parties and/or service provider, and of manipulating the TRS through specific behaviour that is contrary to policy and/or to assumed ethical behaviour. For example, a malicious party that colludes with the service provider, or simply an unethical service provider, could provide fake or unfair positive ratings to a reputation system with the purpose of inflating the service provider's score, thereby increasing the probability of that service provider being selected by other relying parties, which in turn would lead to increased profit. Alternatively, an unethical service provider could engage in unfair badmouthing of competitors in order to reduce their business and profit, with in turn would result in increased own business and profit.

Many other attack scenarios can be imagined that, if successful, would give unfair advantages to the attackers. All such attacks have in common that that they result in the erosion of community trust, with damaging consequences for services and applications in the affected market or community. The robustness of TRSs can therefore be crucial for the quality of markets and communities where a TRS is being applied.

A TRS must not only be robust against intentional attacks, but should produce quality trust and reputation scores under changing conditions and in the presence of unsophisticated participants. Assuming that ratings provided by the community are fair one would expect that a quality service provider always is represented as such through its trust and reputation scores published through the TRS. If that is not the case, i.e. if a reliable service provider is represented with a low score and bad reviews, or an unreliable service provider is represented with a high score and good reviews, then the TRS does not fulfill its most basic role, which could be very damaging for the community. In economic terms, this could cause severe inefficiencies similarly to those resulting from corruption. A second important TRS requirement is that it must react swiftly when the rating trend changes in the positive or negative direction, by immediately producing correspondingly more positive or more negative scores [START_REF] Resnick | Reputation Systems[END_REF].

A TRS can be attacked from multiple angles, meaning that designing adequate defence against possible threats can be a daunting challenge. This presentation focuses on the need for robustness in real implementations of TRS i communities and markets. We do not focus on traditional security threats such as hacking and denial of service, although such defences must of course also be included in any practical implementation. Given that each community has its own specific characteristics the need for TRS robustness will different in each case. At the same time, there are some fundamental requirements for robustness that should be satisfied in general.

Threat Analysis and Proposed Solutions

Fig. 1 illustrates potential attack vectors related to a TRS integrated with targets and relying parties in a community or market. Note that Fig. 1 represents a functional view, not an architectural view. It is for example possible that the TRS function is distributed among all the relying parties as in case of a TRS for P2P networks. It is also possible that there is no distinction between relying parties and service providers. The combination of a TRS and a large number of participants (relying parties and targets) represents a highly dynamic and complex feedback system with many potential vulnerabilities. Making such systems robust against malicious manipulation represents a daunting challenge. The attack vectors in Fig. 1 are briefly describe in Table 1.

Attack Vector Brief Description (1) Service Request

Malicious relying parties, possibly colluding with the service provider, could request services for the sole purpose of being entitled to rate. For example on eBay, ratings can only be provided after a registered transaction, which provides a ticket to rate. (2) Service Provision Malicious service providers could deliberately provide low quality services. Alternatively, low quality service could simply be the result of incompetent or unreliable service providers. (3) Service rating Ratings or reviews could be false or could unfairly misrepresent the actual service received. (4) Enrollment

Relying parties and service providers can e.g. enroll multiple times in order to strategically manipulate the TRS.

Table 1. TRS attack vectors with reference to Fig1

The research literature on TRSs (Trust and Reputation Systems) is relatively mature, where the PhD thesis of [START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF] [START_REF] Marsh | Formalising Trust as a Computational Concept[END_REF] represents an early study of computational trust systems and the article by [START_REF] Resnick | Reputation Systems[END_REF] [START_REF] Resnick | Reputation Systems[END_REF] represents an early introduction to reputation systems. This literature is currently substantial and is still growing fast [START_REF] Golbeck | Trust on the World Wide Web: A Survey[END_REF][START_REF] Jøsang | A Survey of Trust and Reputation Systems for Online Service Provision[END_REF]. A large number of TRS designs and architectures have been and continue to be proposed and implemented. Commercial implementations of TRSs are now part of mainstream Web technology which has resulted in general textbooks on how to build TRSs in real applications, such as Farmer & Glass (2011) [START_REF] Farmer | Building Web Reputation Systems[END_REF].

However, the literature specifically focusing on the robustness of TRSs is much more limited and still in an early stage. It should be noted that publications on TRSs usually analyse robustness to a certain extent, but typically only consider a very limited set of attacks. The text book by Farmer & Glass [START_REF] Farmer | Building Web Reputation Systems[END_REF] also offers advice on robustness. However, many studies on robustness in the research literature suffer from the authors' desire to put their own TRS designs in a positive light, with the result that the robustness analyses often are too superficial and fail to consider realistic attacks. Publications providing comprehensive robustness analyses are rare.

Hoffmann, Zage and Nita-Rotaru (2009) [START_REF] Hoffman | A Survey of Attack and Defense Techniques for Reputation Systems (to appear)[END_REF] provide a taxonomy and analysis framework for TRSs proposed for P2P networks, and then give an analysis of 24 of the most prominent TRSs based on 25 different attributes. Out of the 24 TRSs, 6 were analysed in more detail because of the representativeness of their characteristics. General challenges for the building robustness into TRSs are presented in Jøsang & Golbeck (2009) [START_REF] Jøsang | Challenges for Robust of Trust and Reputation Systems[END_REF]. They give an overview of typical attacks described in the literature, such as those listed in Table 2.

Attack type Short Description

Playbooks

Planned sequence of actions in order to manipulate and deceive Unfair Ratings Ratings that do not correctly reflect the actual experience Review Spam (aka. opinion spam) False reviews, often in conjunction with unfair ratings Discrimination Deliberately providing different quality services to specific relying parties Collusion Coordinated actions among participants in order to manipulate and deceive Proliferation Multiple offerings of the same service in order to obscure competing services Reputation Lag Abuse multiple buyers before the TRS reacts to their negative feedbacks Re-entry Take new identity, in order to eliminate bad reputation of old identity Value Imbalance Exploit reputation from many low value services, for one high value fraud The Sybil Attack Take on multiple identities in order to generate rating and review spam

Table 2. Various strategies for attacking trust and reputation systems

Early proposals for strengthening the robustness of TRSs were typically based on the assumption that false or unfair ratings could be detected statistically, and focused on detecting patterns and outlayers among the ratings, e.g. [START_REF] Dellarocas | Immunizing Online Reputation Reporting Systems Against Unfair Ratings and Discriminatory Behavior[END_REF] [START_REF] Dellarocas | Immunizing Online Reputation Reporting Systems Against Unfair Ratings and Discriminatory Behavior[END_REF], [START_REF] Yu | Detecting Deception in Reputation Management[END_REF] [START_REF] Yu | Detecting Deception in Reputation Management[END_REF], and [START_REF] Withby | Filtering Out Unfair Ratings in Bayesian Reputation Systems[END_REF] [START_REF] Withby | Filtering Out Unfair Ratings in Bayesian Reputation Systems[END_REF]. While these approaches could be characterised as simplistic and relatively easy to bypass for determined attackers, they present the idea of using data mining and reasoning to detect and protect against such attacks.

Kerr (2009) [START_REF] Kerr | Smart Cheaters Do Prosper: Defeating Trust and Reputation Systems[END_REF] provides independent robustness analyses of a set of proposed TRSs, and thereby represents a step in the right direction for TRS research. They also propose a testbed for evaluating TRSs in [START_REF] Kerr | An Experimental Testbed for Evaluation of Trust and Reputation Systems[END_REF].

Large commercial TRSs have attracted, and continue to attract, the attention of independent third party analysts. For example, the robustness of Google's PageRank algorithm has been analysed by [START_REF] Zhang | Making Eigenvector-Based Reputation Systems Robust to Collusion[END_REF] [START_REF] Zhang | Making Eigenvector-Based Reputation Systems Robust to Collusion[END_REF] and by [START_REF] Clausen | The Cost of Attack of PageRank[END_REF] [START_REF] Clausen | The Cost of Attack of PageRank[END_REF], and the robustness of eBay's Feedback Forum has been analysed by several authors, including [START_REF] Resnick | The Value of Reputation on eBay: A Controlled Experiment[END_REF] [START_REF] Resnick | The Value of Reputation on eBay: A Controlled Experiment[END_REF] and [START_REF] Dini | Buiyng reputation on eBay: Do recent changes help[END_REF] [START_REF] Dini | Buiyng reputation on eBay: Do recent changes help[END_REF].

The relative simplicity of writing false reviews of goods and services, and the lack of sanctioning of this practice, currently is a significant problem and a major challenge for review sites such as epinions.com and tripadvisor.com. The problem of false reviews seems difficult to solve because it is in principle impossible to read people's minds and verify whether a review really reflects their inner thoughts. There are nevertheless techniques based on data mining and natural language processing for analysing the consistency of reviews against specific criteria, which can provide an indication of whether a given review is genuine or malicious spam. The goal of this research is to design the equivalent of a lie detector for ratings and reviews.

Analysis and detection of review spam (aka. opinion spam) is a relatively recent research trend, so the literature is still relatively limited, but some studies show promising results. Studies include [START_REF] Benevenuto | Detecting spammers and content promoters in online video social networks[END_REF] [START_REF] Benevenuto | Detecting spammers and content promoters in online video social networks[END_REF], [START_REF] Lim | Detecting Product Review Spammers Using Rating Behaviors[END_REF] [START_REF] Lim | Detecting Product Review Spammers Using Rating Behaviors[END_REF], Gilbert & Karrie (2010) [START_REF] Gilbert | Understanding deja reviewers[END_REF], Wu et al. [START_REF] Wu | Distortion as a validation criterion in the identification of suspicious reviews[END_REF][START_REF] Wu | Merging multiple criteria to identify suspicious reviews[END_REF], [START_REF] Ott | Finding deceptive opinion spam by any stretch of the imagination[END_REF] [START_REF] Ott | Finding deceptive opinion spam by any stretch of the imagination[END_REF], and Duan & Liu (2012) [START_REF] Duan | Building and Managing Reputation in the Environment of Chinese E-commerce: A Case Study on Taobao[END_REF].

As with traditional security solutions, it is to be expected that attackers will adapt to robustness solutions implemented in TRSs, thereby resulting in a endless cat-andmouse game. This phenomenon can already be observed with regard to Google's search engine where the first version of the PageRank algorithm was attacked by link spam, which consists of inserting links to a specific page on open web fora such as discussion groups and wikis. A fix to the link spam problem was to introduce the no-follow tag in 2005 which from then on has been automatically added by web server software to every URL inserted in publicly editable web pages. The no-follow tag instructs search engines to ignore the link, thereby eliminating the effect of link spam. SEO (Search Engine Optimalization) is to influence search engines to get the highest possible position of a specific web page on the SERP (Search Engine Results Page). In SEO, almost anything goes, and search engines such as Google and Bing must constantly change the way their SERP ranking is computed, in order to prevent strategic manipulation.

Regulatory and Social Context for Online Reputation

It is important to look beyond purely technical aspects of TRS robustness when prevention of TRS manipulation is the goal. A real TRS is always embedded in a real community or market with its policy and legal context. Even if there are no technical barriers to manipulating a TRS, the fact that it is forbidden by policy or legislation might have a significant preventive effect on potential attackers. As an analogy, there is nothing that physically can stop a car driver for speeding if he really wants to do it. However, the possibility of a fine, or simply knowing the danger that it poses to people is sufficient to prevent most motorists from speeding. As an alternative to technical robustness mechanisms, it could be useful to define adequate regulation and policies for the deployment and usage of TRSs in online communities.

The simplicity of manipulating TRSs is in many ways paradoxical when considering that that TRSs often have considerable impact on economic performance. A hotel owner can be tempted to use a TRS to gain an advantage over competitors and to maximise profit in the following ways:

(a) Write false positive reviews and artificially inflate own reputation score. (b) Write false negative reviews and give unfairly negative ratings to competitors.

While activity (a) would appear unethical to most people it would be difficult to define it as directly illegal. Activity (b) on the other hand would not only be considered unethical, but could be considered illegal under most jurisdictions on the basis of legislation regarding defamation.

Defamation is when someone makes a false claim implied to be true which may give a negative image to a person, business, product, group, government, or nation. In order for a complaint against defamation to succeed it is normally required that the defaming claim can be proven false and that the claim is communicated to someone other than the defamed entity. Slander and libel are specific categories of defamation, where slander typically refers to a malicious, false, and defamatory spoken statements, while libel refers to any other form of communication such as written words or images. Online defamation can therefore be characterised as libel. Most jurisdictions allow legal actions, civil and/or criminal, to deter various kinds of defamation and retaliate against groundless criticism.

In the case of Roger M. Grace vs. eBay (2004) [START_REF] Roger | Court of appeal of the state of California[END_REF] the plaintiff, Roger Grace, an eBay buyer, sued eBay and the seller Tim Neely after the seller had posted negative comments about Grace. According to court filings, Neely's comments about Grace were: "Complaint: SHOULD BE BANNED FROM EBAY!!!! DISHONEST ALL THE WAY!!!!". The Superior Court of Los Angeles County held that Section 230 of the US Communications Decency Act of 1996 and the User Agreement on eBay's Web site relieve eBay of liability for libel with respect to comments posted by a seller on the eBay Web site. The user agreement on eBay's website contained the the following section: "Because we are a venue, in the event that you have a dispute with one or more users, you release eBay (and our officers, directors...) from claims, demands and damages (actual and consequential) of every kind and nature, known and unknown, suspected and unsuspected, disclosed and undisclosed, arising out of or in any way connected with such disputes". The court also dismissed the suit against the seller Neely after eBay removed the challenged comments from its website.

While the above case released the owner of the TRS itself from liability, it does leave open the possibility of upholding complaints of libel against the party who produces an alleged defaming statement. Leaving baseless negative feedback and reviews can thus lead to legal prosecution. Not only that, even when users genuinely feel that there is an objective basis for leaving negative reviews, the user still faces the risk of legal action from the target of the negative reviews. This creates risk for anybody who wants to leave negative feedback, which by itself represents a disincentive against leaving negative feedback, even when it is warranted.

TRSs are so widespread in online communities and markets that one can speak about the reputation society as a new significant dimension of modern society [START_REF] Masum | The Reputation Society: How Online Opinions Are Reshaping the Offline World[END_REF].

Reputation is an asset that can be won and lost, just like real money. We have strict laws governing how money is exchanged, but very little legal regulation regarding reputation. While legislation about defamation provides protection against unfair damage to reputation, there seems to be no typical legislation against unfair inflation of own reputation. From a general point of view, unfair inflation of own reputation can have a negative economic impact on other parties similarly to damaging their reputation. One could therefore argue that there currently is a hole in most legislations in that respect. Participants in online communities thus face little risk when engaging in unfair inflation of own reputation. It is then up to the TRS owner to define specific policies and sanctions against this practice.

Since TRSs often cannot be considered robust, it seems surprising that they still can provide significant value and that they have become so widespread. One might therefore say that TRSs follow the paradoxical "Yhprums Law," which is the inverse of Murphys Law, expressed by: "Something that shouldnt work sometimes does work.".

One possible explanation of why TRSs are useful despite their weaknesses is that in many situations, a TRS does not necessarily need to be robust. [START_REF] Resnick | Trust Among Strangers in Internet Transactions: Empirical Analysis of eBay's Reputation System[END_REF] [START_REF] Resnick | Trust Among Strangers in Internet Transactions: Empirical Analysis of eBay's Reputation System[END_REF] consider two explanations: (a) Even though a reputation system is not robust it might serve its purpose of providing an incentive for good behaviour if the participants think it works, and (b) even though the system might not work well in the statistical normative sense, it may function successfully if it reacts swiftly to bad behavior and imposes costs for a participant to get established.

Finally, it could be argued that the TRS in an online community serves as a kind of social glue. A TRS provides an interface through which participants can communicate and relate to each other, which in itself is valuable. Any TRS with user participation will depend on how people can use it to better connect to other participants and to the community as a whole, and must be designed with that perspective in mind.

Conclusion

The online world is somewhat analogous to the US Wild West of the 19th century where legislation was unclear and law enforcement was weak. In this context of relative lawlessness, trust and reputation systems represent alternative methods for moderating and regulating online communities. However, the informal and collaborative mechanisms of trust and reputation systems will inevitably come under pressure and attack whenever there is significant financial or political value at stake. In that case, malicious manipulation of a reputation system can only be prevented or mitigated if either 1) there exists regulation or policy that prohibits malicious manipulation with credible sanctioning options, or 2) there are technical mechanisms that can detect and block manipulation attempts. Ideally, both protection principles should be implemented simultaneously. In addition, adequate security mechanisms must be in place in order to prevent hacking attempts against trust and reputation systems or against participants' networks. If adequate robustness can be achieved, well functioning trust and reputation systems will become catalysts for healthy growth in online markets and communities.


Stephen Marsh
email: steve.marsh@crc.gc.ca

Anirban Basu
email: abasu@cs.dm.u-tokai.ac.jp

Natasha Dwyer
email: natasha.dwyer@vu.edu.au

Rendering unto Caesar the Things that are Caesar's: Complex Trust Models and Human Understanding

In this position paper we examine some of the aspects of trust models, deployment, use and 'misuse,' and present a manifesto for the application of computational trust in sociotechnical systems. Computational Trust formalizes the trust processes in humans in order to allow artificial systems to better make decisions or give better advice. This is because trust is flexible, readily understood, and relatively robust. Since its introduction in the early '90s, it has gained in popularity because of these characteristics. However, what it has oftentimes lost is understandability. We argue that one of the original purposes of computational trust reasoning was the human element -the involvement of humans in the process of decision making for tools, importantly at the basic level of understanding why the tools made the decisions they did. The proliferation of ever more complex models may serve to increase the robustness of trust management in the face of attack, but does little to help mere humans either understand or, if necessary, intervene when the trust models fail or cannot arrive at a sensible decision.

Introduction

Computational Trust is the study, formalization and implementation of human trust in computational settings [START_REF] Marsh | Formalising trust as a computational concept[END_REF]. It was intended to be used by autonomous systems of all types in their missions to perform their duties with humans in mind. This qualification is both interesting and important -there is an implicit, at least, expectation that the systems in question are working for humans, perhaps where humans co-exist with the systems themselves. Thus, we can imagine autonomous agents or devices in eCommerce scenarios [START_REF] Ping | A mathematical trust model in e-commerce[END_REF][START_REF] Noorian | Multi-layer cognitive filtering by behavioural modeling[END_REF], Smart Cities [START_REF] Mahizhnan | Smart cities:: The singapore case[END_REF][START_REF] Shapiro | Smart cities: Quality of life, productivity, and the growth effects of human capital[END_REF], Information Systems [START_REF] Li | Predicting user trust in information systems: A comparison of competing trust models[END_REF] and ubiquitous computing in general [START_REF] Shankar | On trust for ubiquitous computing[END_REF][START_REF] Sillence | Ubiquitous computing: Trust issues for a "healthy" society[END_REF]. We have seen trust explored for example in user interfaces [START_REF] Riegelsberger | Shiny happy people building trust?: photos on ecommerce websites and consumer trust[END_REF][START_REF] Riegelsberger | Trust in Mediated Interactions[END_REF] and 'real world' marketplaces [START_REF] Wakeman | Bringing the virtual to the farmers' market: Designing for trust in pervasive computing systems[END_REF]. A recent paper [START_REF] Stanier | Can We Use Trust in Online Dating?[END_REF] tellingly did not build any trust model, noting that current trust models are inappropriate. Trust, of course, is everywhere people are, and if the people are using technology, then it makes sense, at some level, to allow trust to be used there too.

Trust has unquestionable utility -it has been used by humans for millennia to manage risk. Of course, humans have issues estimating and handling risk [START_REF] Zeckhauser | Risk within reason[END_REF], a subject beyond the scope of this paper, but we could argue that this is another reason for trust being so important to people. People make trusting decisions, for better or worse, almost in the blink of an eye, and adapt these decisions over the lifetime of a relationship [START_REF] Boon | The dynamics of interpersonal trust: resolving uncertainty in the face of risk[END_REF]. We should mention that, of course, they make mistakes all the time, but one of the strengths of trust is the implicit acknowledgment of the potential for mistakes in the face of incomplete information, and the fact that it is used anyway and still manages to work both at an individual and a societal level [START_REF] Bok | Lying: Moral Choice in Public and Private Life[END_REF]. Perhaps one triumph of irrationality over rationality.

We are faced with something of a dilemma in the user of trust in technology, however. There is a noticeable trend to more and more complex models, using deeper mathematical techniques and constructs. Complex models (involving trust or related reasoning) have been applied in places as diverse as eCommerce [START_REF] Ping | A mathematical trust model in e-commerce[END_REF][START_REF] Zhang | An improved trust model in agent-mediated ecommerce[END_REF] and Mobile Ad-Hoc Networking [START_REF] Sun | Securing manet databases using metadata and context information[END_REF], through to financial systems (for instance in algorithmic trading). The use of such complex models in systems where time is of the essence, or even where attacks are both prevalent and can have far-reaching effects, is potentially both sensible and timely, but the failures can be interesting, to say the least -witness the Flash Crash of May 6th, 2010 for instance. 4 The use of 'trust' models in these instances is troubling to us because they explicitly preclude the human element, and it is the human element that makes trust trust.

This paper examines the purposes of computational trust, its human element, and the fact that, without the human element, there is a lost link. It goes on to argue that with increasing complexity the human element is ever-more difficult to enlist, even in circumstances where, as almost certainly must happen, the trust model cannot accomplish its task. We argue that the use of the term 'trust' in such systems is misleading, and as such potentially dangerous, and that the increasing complexity of the models does not advance the field or its understanding or applicability in systems where it can be at its best.

The Need for Models

Trust has long been seen as a tool for the reduction of complexity [START_REF] Luhmann | Trust and Power[END_REF]. It allows people to exist in complex societies, where there are far too many considerations of what might go wrong, by taking certain things 'on trust' and not considering them. We can extend this to computational infrastructures in various interesting ways. Developers and creators of ICT systems are encouraged to engage trust, and solve the trust 'problem,' quickly because trust, in this mode reduces uncertainty. This in turn can speed up transactions and 'grease the wheels' of e-commerce [START_REF] Fukuyama | Trust: The social virtues and the creation of prosperity[END_REF]. The complexity-reduction nature of trust is important here because, if trust is not resolved, a user can stay in a cycle of exploring possibilities [START_REF] Cofta | Trust, Complexity and Control[END_REF]. Since trust results in the foreclosure of some future possibilities [START_REF] Goffman | Frame analysis[END_REF], this can remove the need to consider them, and results in a more satisfying, or at least more quickly engaging, experience. This is why trust is often viewed as a type of confidence, even when the confidence is not well placed. Distrust is at least as important in this respect also. Often seen as a negative attribute, distrust can in fact holds benefits for similar reasons. Distrust can also resolve a complex scenario, closing down possible paths for the individual to balance [START_REF] Cofta | Distrust[END_REF]. For this reason, an understanding of both trust, distrust, and everything inbetween is needed [START_REF] Marsh | Trust, untrust, distrust and mistrust -an exploration of the dark(er) side[END_REF][START_REF] Mcknight | Trust and distrust definitions: One bite at a time[END_REF]. Perhaps ironically, whilst trust models can help create systems that more accurately follow humans, ostensibly the topic of this paper, they can also, properly executed, help in developing a greater understanding of the phenomenon in humans [START_REF] Marsh | Formalising trust as a computational concept[END_REF].

That said, we arrive at a juxtaposition where models in the technical setting have become increasingly complex, and as has in fact generally been the case, overly contextual and applicable in narrow domains. We see these as problems. The latter problem, perhaps, feeds the former, and is in a cycle fed by it. One reason that they are problems is that they are incomprehensible to the very humans that they, in all cases, must inevitably serve [START_REF] Marsh | Non-standards for trust: Foreground trust and second thoughts for mobile security[END_REF], but another is that they are not, in the final analysis, approximations of trust at all. Models of any type, be it trust or anything else, helps us simplify our understanding of a phenomenon in natural sciences or social sciences. Empirical models are expected to be built on actual observations of large samples of data. We argue that models of a 'real' phenomenon (in this case, trust) should be, as close as possible, a fit to that real phenomenon. This is, perhaps obviously, because we would wish to use those models so as to confidently explain (and in some instances predict with some accuracy) future occurrences of the same phenomenon. We can happily accept that models of complex phenomena must in themselves be inherently complex, but we do not accept that models should be so complex as to be beyond the understanding of their creators, or, most tellingly in the case of models used to interact with humans in sensible ways, beyond the understanding of the very people that are intended to use them.

3 Where the Models Work, and Where They Don't

Trust models perform best when a general and abstract understanding of a context and associated trustworthiness of others is required, rather than detailed advice about a specific situation. For instance, the reputation system of Ebay can provide an adequate picture of whom the most trustworthy parties are -who deliver goods on time, who do not overcharge, whose goods are as described and of consistent expected quality, for instance. However, the model cannot say whether a user should definitely trust a particularly seller in a specific situation, particularly if the parties in question do not meet the measurement standards of the system. Consider for example a buyer who has found a rare item. The buyer may greatly desire the item, but the seller has a low rating. In this instance, the buyer can override caution and 'trust despite the low reputation' -Ebay gives reputation values that the buyer can use to ascertain their own trust levels. Since here the trade off for the reward is great, the trust calculation is weighed by the rarity of the item. Thus, Ebay can only guide to a certain point, and we have to be aware that trustworthiness (or reputation as calculated by Ebay) is no more than a guide in this respect.

Models also work when the users concern is a predictable one shared by the majority of others and does not stray far from the objectives others have. Models are not good at handling nuance. For instance, the movie recommender system Netflix can only work to a certain extent. For instance, over time and with experience, a user's taste changes [START_REF] Lathia | Evaluating collaborative filtering over time[END_REF]. Models encourage conformity, which in turn, creates conditions for the model to work, creating a self supporting system. Ahn and Esarey [START_REF] Ahn | A dynamic model of generalized social trust[END_REF] explain that systems that provide some sort of information about what is expected as trustworthy behaviour (for instance, Wikipedia), actually foster trustworthy behaviour because users can learn from the system.

We find ourselves here in danger of a cardinal sin for trust and reputation systems -a conflation of trust and reputation -and this is an ideal example for us to approach and consider from the point of view of this paper -that an adequate understanding of what the model is trying to do is absolutely necessary for its successful use. Bearing in mind that trust decisions are based on two questions -how much do you have, and how much do you need (cf [START_REF] Marsh | Formalising trust as a computational concept[END_REF]) -the next steps should be clear in any evidence-gathering approach. Consider embedded reputation systems. In all instances of such systems the system is informing its user of the reputation of the person or thing they are considering. Reputation is a societal judgment of the past behaviour (hopefully in context) of the thing being considered. It is not an indication of the amount that the potential trustee can trust the other. For example, building from Allman et al. and others [START_REF] Allman | An Architecture for Developing Behavioral History[END_REF][START_REF] Wei | Building Reputations for Internet Clients[END_REF], [START_REF] Basu | A Reputation Framework for Behavioural History[END_REF] suggested the formulation of a reputation framework for network clients based on their behavioural histories in order to inform service providers to make decisions about future service provision. Although, on a continuous numeric scale [-1 1] for the sake of comparability, the contextual reputations developed therein did not equate to or imply trust at the level of human connotation. Rather, the reputation was only an indicator. What service providers would do with such reputation would be policy specific, and outside the remits of the reputation framework.

In this context, we should also look at inherent challenges with numerical comparability. While during most part of our daily lives, we deal with numbers, we also do so with agreed upon (within some "community") standard units. These units are nothing but enforcements of connotations of numerical values. For example, a 500ml. bottle of water anywhere in the world will contain very close to 500ml. of water (excluding the minor measurement errors) because milliliters is an already agreed upon standard measurement unit. This is good because that helps our society to function. But, assigning numbers to anything without units takes away the very essence of comparability for which we resort to using numbers in the first place. Even if we suggest that such numerical values are only indicators that people should use to inform their trust decisions, the indications carry little meaning in the absence of comparability. Since, numbers are really hard to assign and units are even harder to define in such cases, perhaps, we should call on the use of more qualitative comparators, e.g. partial order. For example, the reputation of A is higher than B and the reputation of C is also higher than B gives us a reasonable (at least to human mind) qualitative indicator and stops us from making the mistake that reputation of A is equal to C. Humans will, inevitably, tend to make that mistake of comparison if they are presented with concrete numbers. Then the point about trust with humans is that we can safely ignore the internal workings of the human mind when it comes to making a trust based decision, and infer those workings based only on observation. On top of that, we also envisage that if we were to ask about such trust decisions from artificial agents, we should be able to get understandable explanations.

The reason for considering this is the following: models work best when they are best understood. Part of the responsibility for that understanding is the responsibility of the person using the system, that is clear. However, part of it must rest with the system itself, and how it is represented to the person. If reputation is shown as a 'trust' value, it is of little surprise when the sinful conflation occurs and mistakes are subsequently made. On the other hand, it is equally unsurprising to find that overly complex models for trust-reasoning technologies result in diminished, or zero, understanding by their target users, with, we suggest, a corresponding lack of engagement. In the next section we explore this problem further, and look at the concept of 'foreground trust' [START_REF] Dwyer | Traces of Digital Trust: An Interactive Design Perspective[END_REF][START_REF] Marsh | Non-standards for trust: Foreground trust and second thoughts for mobile security[END_REF], which aims to bring trust right into the user interface by encouraging users to make their own decisions based on the evidence.

Putting People First

Trust and reputation models are there for people in much the same way as technologies are there for people -they make certain things more straightforward, or more easy. The implicit assumption that we are making is that all technologies are deployed in order to help, in some way, at least a subset of people. Thus, there is always a human in the loop [START_REF]Socially Intelligent Agents: Creating Relationships with Computers and Robots[END_REF] of technological advancement and deployment. It is indeed difficult to find instances of technology where this is not in some sense, the case -and anything that might be found begs a question, we conjecture, as to its worth. That said, we acknowledge the fact that some systems may have people so far from the immediate consideration that they are effectively ignored. That said, we propose that any system that uses trust or reputation must explicitly acknowledge and make room for the human element. If this is the case, it follows that the models must have not only predictive power, but explanatory power also.

The User Interface

User interfaces are important. They convey system states, valuable information, environmental states, history and predictions to users. In the case of trust (and reputation) systems, they convey recommendations, perspectives, decisions (or, better, suggestions) evidence and requirements. They might also ask for information in order to better do their jobs. They should also ask for help when necessary. Their design is vitally important. The terminology they use, as discussed in the previous section, has power to enlighten or confuse. Most especially, if complex models are used in the background for whatever reason, the user interface has a role to make the model understandable without losing any of its predictive power. Thus, if we consider models of the weather, an interface showing movement of air masses, and associated weather patterns, is infinitely more accessible to anyone than a mass of numbers on a screen, or the output of some set of algorithms. The same must be true for trust models.

When Systems Fail, People Pick up the Pieces

Trust models and their operationalized reputation and trust management systems are ideal targets for attacks and misunderstandings. Whilst the attacks possible on reputation systems are relatively well understood, we would argue that spotting these attacks autonomously is difficult. There are nuances to attacks (hence their efficacy) that computerized systems are not good at spotting. Humans, however, are much better at spotting anomalies in trust reasoning and reputation. And it is to people that we must always turn when at the edges of trust -which include boundaries close to thresholds, cold-start problems, and possible ongoing attacks as well as less stress-laden situations (see e.g. [START_REF] Kaur | User interface for trust decision making in inter-enterprise collaborations[END_REF]).

Designing trust systems that hide the way in which they work must result in misunderstandings, misinterpretations, and mistakes by the very people that the systems are serving. This is guaranteed to result in dissatisfaction and disengagement.

Is it Trust?

There are countless ways of defining trust, but most definitions engage with the notion of confidence and risk and there is an acknowledgement that there is a sense of the unknown embedded in the concept of trust. Möllering [START_REF] Möllering | Trust, institutions, agency: towards a neoinstitutional theory of trust[END_REF] goes as far to argue that there is something magical about trust, otherwise a concept is not trust. Thus models that claim to have removed uncertainty as much as possible are removing trust. If a situation is clear and the future outcome known, then trust is no longer the issue and the relevant ways of understanding a scenario is better described with notions such as control and security.

Making a trust model more complex does not solve the problem when a model interfaces with human reality. A trust model could dictate how much information a user is safe to reveal to others. In reality, humans are swayed by other factors. For instance, most people are aware that a birth date is information required to verify ones identity and most people are aware of identity theft. Even though there is this awareness, a large number of people put their birth date on their social networking profile presumably so that others can wish them a happy birthday. Vanity wins over sensible behaviour. And who can say that what people do in reality is wrong? To do so is to make a value judgment that prejudices rationality. So any trust model that tries to dismiss how humans actually work is not engaging with human reality. A trust model that can function without humans needs to be able to compute ambiguity; unpredictable irrationality, a continual state of uncertainty and lack of clarity, without any claims on what is a correct position. Ambiguity is different to complexity. Complexity is when a model can process a large amount of variables and conditions.

There are some human phenomena that cannot be short-cut [START_REF] Donath | Signals in social supernets[END_REF], and we argue that trust is one these concepts. In the context of on-line dating, Stainer et al. [START_REF] Stanier | Can We Use Trust in Online Dating?[END_REF] demonstrate how a machine can calculate a trust interaction, but when it comes to two people interacting, that calculation can mean very little. While not claiming that humans have a monopoly on trust, we argue that machines are not able to solely process trust without the input of humans. This is because trust is both a rational and irrational phenomena. Trust is a grey concept rather than a black and white, binary position. Computers are renowned for dealing with calculations quickly. Humans are schooled at dealing with ambiguity. Trust models that can incorporate the best of both human and machine work will excel.

Render unto Caesar: a Manifesto

Trust models are approximations of human trust, and as such should be used sensibly and designed so that, whenever possible, humans can be involved. Our basic premise throughout this paper is that any system deployed in the 'real world' in fact influences, is influenced by, and/or works on behalf of humans (whether they like it or not!). When we consider this, we can examine a set of requirements for any trust model that may be designed and deployed in this world. We do not expect this is a complete list, and would expect it to evolve as our understanding of computational trust evolves.

(1) The model is for people.

(2) The model should be understandable, not just by mathematics professors, but by the people who are expected to use and make decisions with or from it. (3) Allow for monitoring and intervention. Understand that a human's conception of trust and risk is difficult to conceptualise. Many mathematical and economic models of trust assume (or hope for) a 'rational man' who makes judgments based on self-interest. However, in reality, humans weigh trust and risk in ways that cannot be fully predicted. A human needs to be able to make the judgment. [START_REF] Thaler | Nudge: improving decisions about health, wealth, and happiness[END_REF]. However, only the user can make that call. [START_REF] Li | Predicting user trust in information systems: A comparison of competing trust models[END_REF] The model should allow for querying: a user may want to know more about a system or a context. A trust interface working in the interest of the user should gather and present data the user regards as relevant. Some of the questions will be difficult for a system to predict and a developer to pre-prepare, so a level of dynamic information exchange is necessary. [START_REF] Shankar | On trust for ubiquitous computing[END_REF] The model should cater for different time priorities. In some cases, a trust decision does need to be made quickly. But in other cases, a speedy response is not necessary, and it is possible to take advantage of new information as it comes to hand. A trust model working for humans needs to be able to respond to different timelines and not always seek a short-cut. [START_REF] Sillence | Ubiquitous computing: Trust issues for a "healthy" society[END_REF] The model should allow for incompleteness. Many models aim to provide a definitive answer.

Human life is rarely like that. A more appropriate approach is to keep the case open; allowing for new developments, users to change their minds, and for situations to be re-visited.

Conclusions

Trust models are becoming more prevalent, applied to many places in many different contexts. Models can be applied in narrow contexts or be much more generic and descriptive (see for example [START_REF] Castelfranchi | Trust Theory: A Socio-Cognitive and Computational Model[END_REF]), but we suggest in this paper that models of trust, pure or applied, are, as part of sociotechnical systems deployed in the world at a concrete level, human-oriented. If this is the case, computational trust models are only useful in situations where the people who interact with them understand them in a reasonable way. It is unsatisfactory to have eCommerce models, for instance, that use mathematical tools that are indecipherable to people who use eCommerce systems (and agents) because the ultimate endpoint is then a shift of trust from the other person to the model (I will do what it says because I can't figure out why, and it's smarter than I am) -this is not what computational trust in its origin was intended to achieve. Without human understanding and focus, trust models are not trust, but a mere statistical, probabilistic or other mathematical approach to uncertainty. We have provided a small manifesto for computational trust models that we hope can be of some service to the community -as a discussion point, as the start of a set of requirements above and beyond 'does it work in this instance, or against this attack?' and as a reminder that, (to paraphrase Einstein) in all of our considerations, humans are the root.

( 4 )

 4 The model should not fail silently, but should prompt for and expect input on 'failure' or uncertainty. (5) The model should allow for a deep level of configuration. Trust models should not assume what is 'best' for the user. Often design tends to guide users towards what the owner or developer of the site thinks what people should be doing

See, e.g. http://www.iosco.org/library/pubdocs/pdf/IOSCOPD354.pdf


Rajat Moona
email: moona@iitk.ac.in

transCryptFS: A Trusted and Secure File System

For the reasons of flexibility and availability, the data may be stored in the cloud. However security of sensitive data and the reliability of access of data are two major issues that become immediate concern. Trust on the services for the secure upkeep of data, its regular maintenance and mechanisms for seamless access are other issues related to such organization of data.

In this talk, we present an encrypting file system based on GNU/Linux based servers which can be accessed through standard protocols such as NFS over unsecured networks. At the same time, the data stored in the servers is always in encrypted form. With only a suitable key management protocol and access control mechanisms, it is ensured that data is made available only to right entities. In the trusted domain for the files, even the system administrators are not included which makes it highly robust yet providing mechanisms for routine administrative jobs such as backup, restoration, duplication and other similar functions on data.

We also present a few more applications for this same file system, such as the case where data on a portable device such as laptop can be protected against loss of information in case of thefts etc.