Anna Vapen

Niklas Carlsson

Anirban Mahanti
email: anirban.mahanti@nicta.com.au

Nahid Shahmehri

Information Sharing and User Privacy in the Third-Party Identity Management Landscape

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Many popular web services, such as Facebook, Twitter, and Google, rely heavily on their large number of active users and the rich data and personal information these users create or provide. In addition to monetizing the high service usage and personal information, the rich user data can also be used to provide personalized and customized user experiences that add value to their services.

With this in mind, it is perhaps not surprising that many websites are using third-party single sign-on (SSO) [START_REF] Dhamija | The seven flaws of identity management: Usability and security challenges[END_REF][START_REF] Sun | Investigating user's perspective of web single sign-on: Conceptual gaps, alternative design and acceptance model[END_REF] services provided by popular websites. With SSO, a website such as Soundcloud will partner with one or more other third-party websites (e.g., Facebook and Google), which will be responsible for user authentication on behalf of Soundcloud. As illustrated in Figure 1(a), a user is given the option of using Facebook and Google for authentication. Assuming that the user selects Google, the user is redirected to Google for authentication (Figure 1(b)). We refer to Soundcloud as a relying party (RP) and Facebook/Google as a third-party identity provider (IDP).

(a) IDP selection (b) Authentication (c) App rights Fig. 1. Soundcloud example illustrating the login process when using IDPs, as well as the app rights requested by Soundcloud when using Google as IDP.

In addition to providing an authentication service, at the time of account creation or first login, the user is typically asked to approve an app-rights agreement (e.g., Figure 1(c)) between the user and the RP, which (i) gives permission to the RP to download agreed-upon information from the user's IDP account, and (ii) authorizes the RP to perform certain actions on the IDP, such as posting information. Such permissions place great responsibility on the RPs, and can raise significant privacy concerns for users.

Privacy concerns related to the rich information shared across websites will likely increase as more sophisticated statistical methods are used to reveal private information using only public data [START_REF] Pennacchiotti | Democrats, republicans and starbucks afficionados: user classification in twitter[END_REF][START_REF] Zafarani | Connecting users across social media sites: A behavioralmodeling approach[END_REF][START_REF] Chaabane | You are what you like! information leakage through users' interests[END_REF]. For example, public Twitter feeds can be used to determine political views and ethnicity [START_REF] Pennacchiotti | Democrats, republicans and starbucks afficionados: user classification in twitter[END_REF], users can be identified across websites even when they lie about their identity [START_REF] Zafarani | Connecting users across social media sites: A behavioralmodeling approach[END_REF], and even relatively innocent information such as the music that people listen to can reveal personal information many users want to keep private [START_REF] Chaabane | You are what you like! information leakage through users' interests[END_REF]. Despite many interesting case studies of how this information can be misused, and our previous basic characterization of the geographic and service-based biases in how RPs select their IDPs [START_REF] Vapen | Third-party identity management usage on the web[END_REF], we are not aware of any study that characterizes the cross-site information sharing and RP authorization in this third-party landscape. Such a study is important to assess the current privacy risks.

This paper provides the first broad empirical analysis of the cross-site information sharing, app-rights agreements, and account management complexities in the current third-party identity management landscape. We place particular attention on the personal information shared and accessed between different sites, and discuss potential privacy implications for end users. Motivated by a high skew in website popularities [START_REF] Gill | Characterizing organizational use of web-based services: Methodology, challenges, observations, and insights[END_REF], our analysis primarily focuses on the cross-site information sharing associated with the 200 most popular websites. 3 Focusing on these sites allows us to manually identify and analyze the information sharing, account creation process, and website interactions as observed by the user.

Contributions and Roadmap

A high-level summary of the results were reported in a short (3-page) poster paper [START_REF] Vapen | Information sharing and user privacy in the third-party identity management landscape[END_REF]. Here, we first briefly present a high-level characterization of the protocol and IDP usage observed in the wild (Section 2). Our results confirm that the use of authorization protocols such as OAuth is significantly more common than the use of pure authentication protocols such as OpenID and that OAuth is becoming increasingly dominant. Since OAuth allows richer cross-site information sharing and can authorize RPs to perform actions on the IDPs, on behalf of the user, these results reaffirm the importance of characterizing today's apprights agreement usage and their privacy risks. We find that many RPs likely select IDPs on other criteria than protocol compatibility. We also find that some IDPs are much more frequently used in combination than on their own, and that there is a high concentration in IDP usage. This can be a potential privacy and security concern in itself, as the user credentials for the most popular IDPs become more valuable to an impersonator, for each RP that adds that IDP.

Thereafter, we characterize the cross-site information sharing and authorized app rights associated with the most popular IDPs (Section 3), responsible for the majority of RP-IDP relationships. We categorize app-rights agreements based on the type of information and actions granted to the RPs (Section 3.1) and identify the most commonly observed privacy risk categories (Section 3.2). We find significant differences in the information leakage risks associated with different RP classes (Section 3.3) and IDPs (Section 3.4).

Finally, we use targeted login and account creation tests to analyze the information sharing in scenarios in which the users have accounts with multiple IDPs (Section 4). Among other things, we find that there often is significant overlap in the information that an RP may request from different IDPs (Section 4.1), that there are significant differences in how well RPs combine the information from multiple IDPs (Section 4.2), and that some IDPs (e.g., Facebook) are much more likely to implicitly enable information leakage between IDP accounts through the RP than others (Section 4.3). In many cases, we have also found that the results depend on the order IDPs are added and that users often lose control of what is shown in their public profile with the RP. We even found several cases in which account merging is not possible or additional IDPs cannot be added/used. The significant differences observed from case to case also illustrate that there is no common API, and that RPs typically pick IDPs based on IDP popularity and the information sharing and actions they enable, rather than protocol compatibility. With each RP implementing its own solution, the user must trust the RP and its implementation. Both OpenID and OAuth have many security issues [START_REF] Dhamija | The seven flaws of identity management: Usability and security challenges[END_REF][START_REF] Armando | From multiple credentials to browser-based single sign-on: Are we more secure?[END_REF], even when used alone, especially if implemented incorrectly [START_REF] Wang | Signing me onto your accounts through facebook and google: a traffic-guided security study of commercially deployed single-sign-on web services[END_REF][START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of oauth sso systems[END_REF]. Many privacy issues discussed here will therefore likely take time to address.

Protocol and IDP Selection

Today's RP-IDP relationships are typically implemented using OpenID or OAuth. While OpenID was designed purely for authentication and OAuth primarily is an authorization protocol, both protocols provide an SSO service that allows the user to access the RP by authenticating with the IDP without needing local RP credentials. With OAuth, a local RP account is always linked with the users IDP account, allowing information sharing between the RP and IDP. Local RP accounts are optional with OpenID.

We primarily focus on all RP-IDP relationships that we have manually identified on the 200 most popular websites on the Web (as observed in Apr. 2012, Feb. 2014, and Sept 2014), but will also leverage the 3,203 unique RP-IDP relationships (3,329 before removing false positives) identified using our custom designed Selenium-based crawling tool [START_REF] Vapen | Third-party identity management usage on the web[END_REF].

OAuth is the dominant protocol as observed in both manual and crawled datasets. For example, in Apr. 2012, 121 of 180 (67%) relationships in the manual dataset and 2,543 of 3,203 (79%) relationships in the crawled dataset are directly classified as OAuth, compared to only 20 (11%) and 180 (6%) as OpenID relationships in the two datasets. Of the remaining relationships, 39 and 441 used an IDP that supports both OpenID and OAuth. Since then, as measured in Sept. 2014, we have seen a further increase of OAuth usage (+24%) and drop in OpenID usage (-10%) among the top-200 websites.

We have found that IDP selection differs significantly depending on how many IDPs an RP selects, and some IDPs are more likely to be selected together with others. In total the top-5 ranked IDPs are responsible for 92% (33 of 36) and 90% (1,111 of 1,233) of the relationships of RPs selecting one single IDP. For RPs with 2-3 IDPs, 83% and 75% of the relationships are to the top-5, but for RPs with 4 or more IDPs only 38% and 55% are to the top-5 IDPs. Facebook+Twitter is the most popular pairing with 37% (125 of 335) of all IDP pairs, Chinese QQ+Sina place second (19%), and Facebook+Google third (12%).

App Rights and Information Flows

This section considers the information sharing and actions that RPs are permitted. Although it is impossible to know exactly how each RP uses the information they obtain from the IDPs (e.g., if they use data mining to present targeted ads, provide better services, or if they simply store the information for potential future use), the app-rights agreements between RPs and users reveal (i) the information that the RP will obtain from the IDP, and (ii) the actions the RP will be allowed to perform on behalf of the user.

For this study, we have carefully recorded the app-rights agreements for the RP-IDP relationships identified in the manual top-200 dataset. We created fake accounts on the IDPs, initiated the account creation process for each identified RP-IDP relationship involving this IDP, and recorded the app-rights agreements that our fake users were requested to agree to. For the tests in this section, we interrupt the login process after recording the app rights. Due to limited translation support, we only recorded statistics that provided app-rights agreements in English. The use of fake identities helps remove potential biases in the app-rights agreements presented to the users.

A few IDPs required the use of phone numbers in the registration process. Although these phone numbers or advanced data mining techniques [START_REF] Zafarani | Connecting users across social media sites: A behavioralmodeling approach[END_REF] can be used to link the fake profiles with real identities, we have not observed anything that would suggest that these phone numbers have impacted our results.

For this analysis we focus on the RP-IDP relationships in the top-200 dataset from Feb. 2014. However, as Facebook has significantly changed their API since then, from version 1.0 (Apr. 2010) to 2.0 (Apr. 2014), and again to 2.1 (Aug. 2014), we analyze recorded app rights from both Feb. 2014 and Sept. 2014.

Classification of Information

When analyzing app-rights restrictions as described in the APIs of the three major IDPs (Facebook, Twitter and Google) as well as the actual app-rights usage across the top-200 websites in our datasets, we have identified five different classes of app rights, each with their own privacy implications. The first four classes (B, P, C, and F) capture information (or content) transferred from the IDP to the RP. The last class (A) has to do with actions being performed by the RP, on the IDP, on behalf of the user.

-Basic information (B): Relatively non-private information that the user is often asked to provide websites, including identifiers (e.g., email address) to identify existing accounts, age range, language, and public information. -Personal information (P): This class includes personal information, common in many basic "bundles" (e.g., gender, country, time zone, and friend list), but also more sensitive information such as political views, religion, and sexual orientation.4 -Created content (C): This class contains content directly or indirectly created by the user, and includes images, likes, and check-in history. The sensitivity of the data varies. For example, in some cases the user may want to share images and video across sites, while in other cases this content may be considered private. Also the sensitivity of "logged" content (e.g., likes, watched video clips, location history) varies significantly on the situation. -Friends' data (F): This class consists of data of other users (e.g., friends of the user). Even when of a non-sensitive nature, this data is privacy critical since it belongs to another, potentially non-consenting, user. -Actions taken on behalf of the user (A): This final class includes the right to actively export data from the RP to the IDP and the right to perform actions on behalf of the user. This may include posting information on a user's IDP timeline or feed. The transferred data may include content the user creates at the RP (e.g., images), or information about the user's actions on the RP (e.g., sharing read articles, or music the user has listened to).

While the current example considers a scenario with a single RP-IDP pair, Section 4 briefly considers the multi-IDP case, in which information may be shared/leaked across multiple sites. Here, the action (A) class is particularly interesting when used in combination with friends' data (F). In this case, the RP may enable the actions by one user at one IDP to be leaked (through the RP) to other users at another IDP.

It is perhaps for this reason that Facebook, in their recent (Sept. 2014) multistep app-rights agreements, does not share friend (F) data, and first request that the user approve data sharing permissions (B, P, and C), before the RP can ask the user to agree to optional action (A) permissions of different types. Regardless how these action permissions were classified in Feb. 2014, in the Feb. 2014 dataset, we include the most recent optional Facebook action (A) permissions from Sept. 2014. For the other big IDPs there have been no major changes in their APIs since Feb. 2014.

Risk Types

Today, many IDPs bundle the information requested into larger "bundles", and RPs must select which bundle to present to the users. 5 This simplifies the agreements, but reduces the granularity of control over information sharing, often resulting in the user being asked to grant permissions to share more information than the RP requires to perform the desired service.

Figure 2 summarizes all the observed app-rights agreements in our Feb. 2014 dataset. We use a Venn diagram to show all relationships involving actions in the left square and all others in the right square. Any relationship that is not in any of the three classes P, C, and F is in class B.

Only a handful of cases (4) limit themselves to only the basic (B) information (without actions (A)), and most RPs are requesting significantly more personal information from their users. These observations suggest that there is an expectation of trust in the RPs, beyond what the user would share publically. Generally, RPs that are performing actions (A) on behalf of their users are more likely to request access to content (C) from the IDP. In total, 40 of the 87 classified relationships include actions (A). Of these, 14 RPs also request access to content (C). Of the 47 app-rights agreements that does not request actions to be performed, only 12 (9+3) also request access to content (C).

Another important observation is that within each of the two boxes there is a clear ordering in risk types observed, suggesting that there is a natural ordering of the risk types observed in practice. In particular, class F is only used in combination with both C and P. This combination clearly has the highest privacy risks associated with it. Similarly, class C is only used in combination with P, clearly distinguishing its risks with those of sites that only request personal (P) or basic (B) information.

R - A A ∩ B R - ¬A ∩ B RA A ∩ P R ¬A ∩ P R + A A ∩ P ∩ C R + ¬A ∩ P ∩ C R ++ A A ∩ P ∩ C ∩ F R ++ ¬A ∩ P ∩ C ∩ F
Motivated by these observations, we identify eight semi-ordered risk types (strict ordering within columns). Table 1 summarizes the observed risk types. We note that there is a strict privacy ordering in each column (from (-) to (++)), and with regards to each row (as allowing actions implies some risk), but that further ordering is not possible without making assumptions.

RP-based Analysis

Using the above RP-IDP relationship type classification, we next compare the app rights for different classes of RPs. In particular, we compare the app rights of RPs with different (i) primary web services, or (ii) number of IDPs.

Table 2 shows the number of relationships of each type, for websites that provides different web services. Here, we use a basic service categorization inspired by categories defined by Gill et al. [START_REF] Gill | Characterizing organizational use of web-based services: Methodology, challenges, observations, and insights[END_REF]. With this categorization, each of the top-200 websites was manually classified as one of nine classes.

Among the classes with at least 10 RPs, News sites and File sharing sites are the most frequent users of actions (risk types R A and R + A ), with 55% and 50% of their relationships including actions, respectively. Also Video sharing (67%) and Tech (63%) sites have a large fraction of relationships that include action (A) permissions. The high action (A) permission usage is likely an effect of these sites often wanting to promote articles, files, or videos to friends of the user. While we express privacy concerns regarding R + A relationships, these sites would in fact desire that the information that their articles/content are being read to propagate across many sites. This is also reflected in the relatively large number of IDPs per RP for these four website categories (3.3, 2.83, 2.33, and 3.0, respectively, compared to an overall average of 2.5). We next compare RPs with different numbers of IDPs (Table 3). Interestingly, relationships including actions (R A and R + A ) are primarily associated with RPs that have many IDPs. For example, while RPs with a single IDP use actions in 33% (8 of 24) of their relationships (all using Facebook), RPs with multiple IDPs (2, 3, or 4+) use actions in 48-53% of their relationships. As with our discussion about News sites and File sharing sites, the many IDPs of these RPs increases the risk for cross-site information leakage.

The most restrictive type (R -) includes only OpenID relations. For content sharing without actions (R + ), OAuth is the primary protocol, even if it is possible to transfer personal data and (links to) content over OpenID. Naturally, all relationships including actions use (and must use) OAuth.

Head-to-Head IDP Comparison

We have found that the top-three English speaking IDPs (Facebook, Twitter, and Google) are used differently by their RPs and that the usage is relatively independent of which other IDPs the RPs are using.

Table 4 breaks down the app rights for RPs using each of these three IDPs. Google is the only IDP with type R -relationships. Most of these relationships are due to use of Google's OpenID-based API, which in comparison to Google's OAuth API typically share less information and does not allow actions. Overall, Google's mix of OpenID-based and OAuth-based relationships share less information (large fraction of R -, R, and R A ) than Twitter and Facebook (who also have many R + , R ++ , and R + A relationships). Furthermore, compared to Twitter and Facebook, Google allows more fine-grained personalization of app-rights agreements. The user is sometimes able to select which contacts (if any) to share information with (e.g., using Google's concept of "circles"). The most privacy preserving choice is, however, typically not selected by default.

Facebook is dominated by R and R A relationships, and typically allows rich datasets to be imported to the RP. For Twitter, public messages and contacts are normally the only shared data (counted as content (C)); however, it should be noted that there are Twitter relations in which even private messages are shared with the RP. Twitter has the largest fraction of relationships with actions (R A and R + A ). Twitter is particularly attractive for RPs wanting to perform actions on behalf of their users, as it provides an API that allows a wide of range of such actions to be performed and has a relatively active user population.

While we have not found any major statistical biases when comparing the fraction of relationship types observed when two IDPs (an IDP pairing) are used by the same RP vs. when they do not appear in such a pairing, we have found that there are some relatively common combinations. Figure 3 shows app-rights selections for IDP pairs consisting of Facebook/Google (19 pairs), Facebook/Twitter (11 pairs), and Google/Twitter (12 pairs). For example, we note that RPs importing personal data (P) from Facebook, often do the same with Google (with or without actions). We also observe several cases where Google and Twitter are used together and both IDPs use actions (A) and importing personal (P) data (being classified as R A ). In general, there is a bias for selecting to use actions (A) with one IDP, given that actions are used with the other IDP. For example, in 24 of 40 cases (60%) in which an RP-IDP relationship of a pairing uses action (A) the other relationship uses actions (A) too. In contrast, only in 16 of 44 cases (37%) in which the first RP-IDP relationship does not use actions (A), the other does. Using one-sided binomial hypothesis testing, these differences are significant with 98% confidence (p = 0.015, z = 2.167).

Multi-account Information

It is becoming increasingly common that users have accounts with multiple of the RP's IDPs. For example, in our original Soundcloud example (Figure 1), a user may have accounts with both Google and Facebook. In addition, a local RP account may be created either before connecting the account to one of the IDPs, or when first creating the account using one of the IDPs. The use of all these accounts and their relative dependencies can complicate the situation for the end user, potentially increasing privacy risks.

In this section we present the highlights from a set of targeted scenariodriven case studies that we have performed to analyze the interaction between the different accounts, as observed in the wild. (Due to space limitations detailed results and tables are omitted.) For this analysis, we performed tests for each pairing of the three most popular English-speaking IDPs: Facebook, Twitter, and Google. For each possible IDP pairing, we allowed both IDPs in the pair to be used first in a sequence of tests. The tests were also performed both with and without first creating local accounts at the RPs. For each test sequence, we recorded all information I u(α→γ) (of class B, P, C or F) that a user u agrees that the RP γ can import from IDP α, all information I u(γ→α) that user u agrees that the RP can post on the IDP (through actions (A)), all information I u(u→γ) that the user manually inserts into its local profile, and the information I u(p) which ends up in the user profile.

Information Collision

When looking closer at the overlap between the information shared by the IDPs (i.e., I u(α→γ) and I u(β→γ) ) with the RP, we observe that contact lists (26 of 42) are the most common overlap. As Twitter does not explicitly list email address, profiles picture, and names in their agreements or bundles, the overlaps for these categories are limited to Facebook+Google scenarios: 14 out of 42 cases for email addresses, 10 of 42 for profile pictures, and 10 of 42 for names. Having said this, we did observe cases where the profile picture and name were imported from Twitter without asking (or being listed in the app-rights agreement), suggesting that these numbers only provide a lower bound of the potential information collisions.

As the shared information can be both conflicting and complementary, significant identity management complications can arise because of overlapping information. Yet, we have found little to suggest that the RPs provide users with identity/information management for these instances. In fact, even among the typically very small subset of information transferred to the user profile (Section 4.3) there often is an overlap. For example, regardless if there exists an initial local account or not, in 9 of 42 cases, at least some potentially conflicting information is imported to the user's RP profile from both IDPs.

Account Merging and Collisions

We next evaluate how well the RPs allow multiple accounts to be associated with a single user, and if the RPs allow multiple accounts to be merged. For merging to take place, the RP must allow the user to connect an IDP to an existing local account, or to connect a second IDP to an account that already have an IDP associated to it, such that both IDPs can be used to login to the RP.

Interestingly, we have found that both account merging and the information transferred between accounts often are highly dependent on the order in which accounts are added. Furthermore, in many cases the user is not able to merge accounts, or control if merging should take place. For example, out of the 42 (6x7) first-login cases when using a local account, only 10 cases resulted in optional merging and 11 in automatic merging. In 6 of the remaining cases, temporary accounts were created that did not have full functionality, in 7 cases the login failed altogether (typically due to collisions of email accounts between the original local account and that used at the IDP), and in the remaining cases a new account is created.

Similarly, out of the 2x42 (2x6x7) second-login cases with a second IDP, starting both with and without a local account, we observe few merging opportunities: 9 optional cases and 2 automatic cases, when there is no local account (12 and 10 cases when there is a local account). In total, a second IDP can be added (and merged) in 33 (11+22) of 84 cases.

Our results suggest that many RPs are not designing for multi-IDP scenarios, but that Facebook is doing the best job allowing for such relationships. The lack of multi-IDP support can have serious negative consequences as many of these IDPs are popular services with many users; increasing the chance that users have accounts with multiple IDPs. In the following, we take a closer look at information flow in the cases when two IDPs could be added.

Cross-IDP Information Leakage

Not only can information I u(α→γ) be shared from an IDP α to an RP γ, but in some cases the app-rights agreements with another IDP β may (intentionally or unintentionally) allow information to be moved from one IDP to another IDP (through the RP). This occurs when this agreement allows the RP γ to post some subset of this information to IDP β. Looking at the overlap I u(α→γ) ∩I u(γ→β) we observed multiple cases where such cross-IDP sharing is possible. For example, six RPs allow personal (P) and/or content (C) from Facebook to be posted on Twitter, and five RPs allow basic (B) information from Facebook or Google to be transferred. We have also observed two RPs that have general posting rights on Facebook that allow transfer from Google, and two RPs that allow Facebook to transfer data from Twitter (although in this case Twitter would only transfer profile picture and name to the RPs). While these results show that all IDPs can be potential information sources and publishers of leaked information, in general, we see that Facebook allows the richest cross-IDP leakage and Twitter is the most likely publisher of cross-IDP leaked information.

Related Work

The third-party authentication landscape has gone from a situation with many OpenID enabled accounts but very few RPs supporting login with an IDP [START_REF] Sun | A billion keys, but few locks: The crisis of web single sign-on[END_REF] to a landscape dominated by OAuth and Web 2.0 services that share data between sites. Limited work has been done on characterizing this emerging landscape.

In this paper, we leverage our RP-IDP relationship identifications and manual collection methodology [START_REF] Vapen | Third-party identity management usage on the web[END_REF], previously used to characterize and compare the relative biases (geographic and service-based) that RPs have in their IDP selection relative to the biases in the third-party content delivery landscape. In contrast, this paper looks closer at the information sharing and privacy risks associated with the observed RP-IDP relationships.

Sun et al. [START_REF] Sun | Investigating user's perspective of web single sign-on: Conceptual gaps, alternative design and acceptance model[END_REF] have shown that there are misconceptions about how SSO works and the information transfers using OAuth, which leads to many users avoiding SSO. However, it can perhaps be argued that the users' fear is partially justified, as it has been shown that users become increasingly susceptible to phishing attacks as they get used to being redirected between sites and providing their credentials [START_REF] Dhamija | The seven flaws of identity management: Usability and security challenges[END_REF].

Others have proposed recommendation systems to help users make informed choices about what data to allow on different IDPs [START_REF] Shehab | Roauth: Recommendation based open authorization[END_REF] and frameworks that provide users added control over how third-party applications (TPAs) can access data from an online social network (OSN) [START_REF] Cheng | Preserving user privacy from third-party applications in online social networks[END_REF][START_REF] Felt | Privacy protection for social networking APIs[END_REF]. Many of the insights in these works are directly applicable to ours, as TPAs play a similar role as our RPs and the OSN acts as IDP. Extending these frameworks to the general RP-IDP landscape, characterized here, provides interesting future work.

Many researchers have used the data available on the popular IDPs, sometimes generated with the help of RPs, to illustrate how data mining and other statistical methods can be used to determine potentially private information from public data (such as likes, twitter feeds, etc.) [START_REF] Chaabane | You are what you like! information leakage through users' interests[END_REF][START_REF] Zafarani | Connecting users across social media sites: A behavioralmodeling approach[END_REF][START_REF] Pennacchiotti | Democrats, republicans and starbucks afficionados: user classification in twitter[END_REF], or correlating user data from several websites to identify a user based on behavior [START_REF] Goga | Exploiting innocuous activity for correlating users across sites[END_REF]. This type of cross correlations is, of course, even easier if RPs and IDPs are linked. We see these examples as motivation for looking more closely into the increased cross-site sharing and potential information leakage associated with the RP-IDP relationships. Cross-site leakage and the associated privacy risks have also been studied in the context of ad services and trackers [START_REF] Malandrino | Privacy awareness about information leakage: Who knows what about me?[END_REF].

Birrell and Schneider [START_REF] Birrell | Federated identity management systems: A privacybased characterization[END_REF] present a privacy-driven taxonomy of the design choices in the third-party identity management landscape. Protocol related security problems that enable identity theft and blackmailing [START_REF] Wang | Signing me onto your accounts through facebook and google: a traffic-guided security study of commercially deployed single-sign-on web services[END_REF], and economic factors [START_REF] Dhamija | The seven flaws of identity management: Usability and security challenges[END_REF] have also been discussed in the literature.

Discussion and Conclusions

This paper characterizes the cross-site information sharing and privacy risks in the third-party identity management landscape. We show that OAuth is the dominant protocol, and OpenID is decreasing in usage. Not only is OAuth used by the most popular IDPs (e.g., Facebook, QQ, and Twitter) but it also enables sharing of much richer information with RPs.

We also observe high concentration in usage of a few popular IDPs, and that some IDPs are more frequently used in combination with others. The skew towards a few popular IDPs, which often allow RPs to act on behalf of the users, has privacy implications for the end users, regardless of whether the users choose to create an account with the RP or not. For example, a user with a compromised IDP account could easily be impersonated across all the RPs using a particular IDP, even if the user did not originally have an account with these RPs.

We then carefully classify and analyze the app-rights agreements of the most popular websites. Our classification of RP-IDP relationships is based on both the information that the RPs are allowed to import (e.g., basic, personal, generated content, or friend data) from the IDP, and if the RP is allowed to perform actions (e.g., create, update, or delete information) on behalf of the user on the IDP. Although we observe significant differences in the information leakage risks seen both across classes of RPs and across popular IDPs, we find multiple high-risk sites (e.g., RPs that both import private information and that are authorized to perform actions) among the top-200 websites for all website classes except Ads/CDN services. Such sites can easily become a source of information leakage.

Our multi-account case studies show that users are often asked to allow the RP to import more information from the IDP than is needed for the local user profile, and to enter redundant information. Furthermore, we find significant incompatibilities and inconsistencies in scenarios involving multiple IDPs. Often it is not possible to merge accounts with different IDPs, and the user can be stuck with a wide range of undesirable account situations. Clearly, many RPs are not designed to simply and securely use multiple IDPs.

We believe that more focus must be placed on multi-IDP scenarios when defining future policies for OpenID Connect (based on OAuth2), for example. Ideally, the user should remain in control of exactly what is being shared between the involved parties, and which information should be used and shared with each IDP. Similar to how Google+ (and to some extent Facebook) allows users to define circles, we believe that carefully designed protocols with added user control can be defined in this context. Already today, these IDPs allow some degree of personalization in their RP-IDP permission agreements, so generalizing this concept to the context of multiple IDPs could be one possible approach. Future work will include the definition and evaluation of such policies.

Fig. 2 .

 2 Fig. 2. RP-IDP relationships of different app-rights classes in the top-200 dataset.

Fig. 3 .

 3 Fig. 3. Dependencies between app rights for the top-three English speaking IDPs. Here, the top-right legend shows the labeling of RP-IDP relationship types for each IDP, and link weights specify the number of RPs with such a relationship pair.

Table 4 .

 4 Breakdown of risk types of the RP-IDP relationships associated with the top-three English speaking IDPs.Relationship type IDP Tot R -R R + R ++ RA R +

Table 1 .

 1 Risk types identified in dataset.

	Risk	Class	Risk	Class
	type combination type combination

Table 2 .

 2 Breakdown of risk types of the RP-IDP relationships for RPs belonging to different websites categories, as classified based on their primary service.

		Sites		Relationship type
	Categ.	RPs/Tot Tested/Tot R -R R + R ++ RA R + A R ++ A
	Ads/CDN	0/9	-/-	-	-	-	-	-	-	-
	Commerce	8/26	7/16	0 5 0	0	2	0	0
	File sharing	6/10	12/17	2 3 1	0	3	3	0
	Info	9/14	10/16	0 5 0	1	4	0	0
	News	12/20	22/40	0 4 6	0	7	5	0
	Social/portal	26/81	22/65	1 10 2	2	3	4	0
	Tech	7/23	8/21	1 2 0	0	2	2	1
	Video	9/17	6/21	0 2 0	0	4	0	0
	Total	77/200	87/196	4 31 9	3	25 14	1

Table 3 .

 3 Breakdown of risk types of the RP-IDP relationships for RPs with different numbers of IDPs. Tot R -R R + R ++ RA R +

				Relationship type
	IDPs RPs Tested/A R ++ A
	1	36	24/36	0 11 3	2	7	1	0
	2	15	19/30	1 7 0	1	7	2	1
	3	11	21/33	1 6 3	0	6	5	0
	4+	15	23/97	2 7 3	0	5	6	0
	Total 77	87/196	4 31 9	3	25 14	1

Alexa (official website), www.alexa.com.

One current Facebook bundle and two Google bundles named "Basic information" and similar (from which the RP selects which bundle to use in the app-rights agreement presented to the user) include both class B and P information.

For Twitter, the RP selected bundles (either "read", "read + write", or "read + write + direct messages") are translated into an explicit list of app rights presented to the users.


Mohsen Rezvani
email: mrezvani@cse.unsw.edu.au

Mohammad Allahbakhsh
email: allahbakhsh@uoz.ac.ir

Lorenzo Vigentini
email: l.vigentini@unsw.edu.au

Aleksandar Ignjatovic

Sanjay Jha
email: sanjay@cse.unsw.edu.au

An Iterative Algorithm for Reputation Aggregation in Multi-dimensional and Multinomial Rating Systems

Keywords: Online Rating, Voting, Trust, Provenance, Multi-dimensional

Online rating systems are widely accepted as a means for quality assessment on the web, and users increasingly rely on these systems when deciding to purchase an item online. This fact motivates people to manipulate rating systems by posting unfair rating scores for fame or profit. Therefore, both providing useful realistic rating scores as well as detecting unfair behaviours are of very high importance. Existing solutions are mostly majority based, also employing temporal analysis and clustering techniques. However, they are still vulnerable to unfair ratings. They also ignore distance between options, provenance of information and different dimensions of cast rating scores while computing aggregate rating scores and trustworthiness of raters. In this paper, we propose a robust iterative algorithm which leverages the information in the profile of raters, provenance of information and a prorating function for the distance between options to build more robust and informative rating scores for items as well as trustworthiness of raters. We have implemented and tested our rating method using both simulated data as well as three real world datasets. Our tests demonstrate that our model calculates realistic rating scores even in the presence of massive unfair ratings and outperforms well-known ranking algorithms.

Introduction

Nowadays, millions of people generate content or advertise products online. It is very unlikely for a customer to have a personal experience with a product or to know how trustworthiness a seller might be. One of the widely used methods to overcome this problem is to rely on the feedback received from the other users who have had a direct experience with a product or have already bought it. Online rating systems collect feedback from users of an online community and, based on the feedback, assign a quality score to every product or trustworthiness of a user in the community. The Amazon4 online market and the eBay 5 are some of the well-known outlets which incorporate an online rating systems.

One of the big issues with the online rating systems is the credibility of the quality ranks that they produce. For various reasons, users might have interest to post unfair feedback, either individually or as an organised, colluding group. If such unfair feedback is taken into account when ranks are computed, the resulting quality ranks are no longer reliable. Many pieces of evidence show that the online rating systems are widely subject to such unfair ratings [START_REF] Wang | Serf and turf: crowdturfing for fun and profit[END_REF][START_REF] Morgan | Reputation in online auctions: The market for trust[END_REF]. Some studies propose methods for dealing with this problem which rely on clustering techniques to analyze the behaviour of raters and find the abnormal ones [START_REF] Lim | Detecting product review spammers using rating behaviors[END_REF][START_REF] Mukherjee | Spotting fake reviewer groups in consumer reviews[END_REF]. The main problem with such solutions is that the clustering techniques are generally based on solutions to NP-Hard graph problems; thus their performance is severely degraded when the size of an online systems is too large. The other type of solutions to such problems is based on iterative filtering (IF) techniques [START_REF] Laureti | Information filtering via Iterative Refinement[END_REF][START_REF] De Kerchove | Iterative filtering in reputation systems[END_REF][START_REF] Zhou | A robust ranking algorithm to spamming[END_REF]. These techniques, while performing better than the simple aggregation techniques, are still vulnerable to sophisticated collusion attacks [START_REF] Rezvani | Secure data aggregation technique for wireless sensor networks in the presence of collusion attacks[END_REF].

We have recently proposed an algorithm [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF], Rating Through Voting (RTV), which outperforms the previous IF algorithms in terms of detection and mitigation of unfair behaviour. Although RTV shows a promissing robustness against unfair ratings, it still has limitations that require more investigations.

The first limitation is that in RTV the order of the choices is not important and the distance between the choices is not defined. For example, when a rater chooses the Nominee 1 as the most popular candidate and another rater selects the Nominee 2 , it does not make sense to talk about the distance between these two options. However, in a movie rating system, if one of the raters chooses 4 star rating of a movie and another chooses a 3 star rating then a distance between there ratings is well defined and might be important for rating methods. The distance between choices is not taken into account in the RTV algorithm.

Moreover, in a rating system, raters may assess quality of a product, a service or a person from different aspects. For instance, in eBay's detailed seller rating system, buyers express their opinion on the quality of a transaction form four different aspects 6 . For a reputation to be more credible, it is necessary that the reputation system aggregates the scores received for all different aspects to build the final reputation score. This is another limitation of the RTV algorithms.

Finally, the provenance of a rating score is another piece of information that is ignored in the RTV algorithm. The contextual information around a cast rating score can give the system useful hints to adjust its weight. The profile of the rater, the time a feedback has been cast, etc., are examples of contextual meta data that can be taken into account in the computation of the ranks.

In this paper we propose a novel reputation system which is based on the RTV algorithm 7 . The proposed method takes into account the distance between options to fairly propagate credibility among options. We also, consider the different dimensions of the cast rating scores and utilize them in order to build more realistic and credible reputation aggregation. Finally, our proposed method takes advantage from the provenance of the cast feedback when calculating reputation and rating scores and consequently computes more informative and reliable scores. We have assessed the effectiveness of our approach using both synthetic and three real-world datasets. The evaluation results show superiority of our method over three well-known algorithms in the area, including RTV.

The rest of this paper is organized as follows. Section 2 formulates the problem and specifies the assumptions. Section 3 presents our novel reputation system. Section 4 describes our experimental results. Section 5 presents the related work. Finally, the paper is concluded in Section 6.

Preliminaries

Basic Concepts and Notation

Assume that in an online rating system a set of n users cast ratings for m items. Each user rates several items (but not necessarily all) and each item might be rated from K different perspectives. We represent the set of ratings by a three dimensional array

A n×m×K in which A i,j,k (1 ≤ i ≤ n, 1 ≤ j ≤ m, 1 ≤ k ≤ K)
is the rating cast by user i on the item j from the k th perspective. We suppose that rating scores are selected from a discrete set of numbers each of which represent a quality level, for example 1-star to 5-stars.

Rating through Voting

The RTV algorithm [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF] reduces the problem of rating to a voting task. In the algorithm, when a rater chooses a quality level, say 4-stars, to represent quality of a product, one can say that the rater believes that 4-stars represents the quality of the product better than the other options; thus, in a sense, he has voted for it out of the list of 1-star to 5-stars options.

RTV assigns a credibility degree to each quality level in order to show how credible this quality level is for representing the real quality of the item. Thereafter, it aggregates the credibility of all quality levels a users has voted for to build the users' trustworthiness. Assume that for each item l, there is a list of options Λ l = {I l 1 , . . . , I l n l } and each user can choose maximum one option for each item. We define the credibility degree of a quality level I i on list Λ l , denoted by ρ li as follow:

ρ li = r : r→li (T r ) α 1≤j≤n l r : r→lj (T r ) α 2 (1)
7 An extended version of this paper has been published as a technical report in [START_REF] Rezvani | An iterative algorithm for reputation aggregation in multi-dimensional and multinomial rating systems[END_REF].

where r → li denotes that user r has chosen option I l i from list Λ l . α ≥ 1 is a parameter which can be used to tune the algorithm for a particular task. T r is the trustworthiness of user r which is obtained as:

T r = l,i : r→li ρ li (2)
Equations ( 1) and [START_REF] Hoffman | A survey of attack and defense techniques for reputation systems[END_REF] show that there is an interdependency between the credibility and trustworthiness. RTV leverages such interdependency through an iterative procedure. Given the credibility degrees obtained by such iterative algorithm, the aggregate rating score of item l, denoted as R(π l ), is obtained as:

R(π l ) = 1≤i≤n l i × ρ p li 1≤j≤n l ρ p lj (3)
where p ≥ 1 is a parameter for controlling the averaging affect.

Reputation Aggregation System

In this section, we extend RTV by taking into account the rating provenance as well as credibility propagation in a multi-dimensional rating system.

Distance Between Nominal Values

In most of social rating systems, such as eBay 5-star feedback system, there is a numerical distance between the existing options. In order to take into account such distance in our reputation propagation method, we formulate the distance using a decaying function.

One can use any decreasing function, symmetric around the origin, i.e., such that d(x) = d(-x). Here we define the distance of two options i and j as d(i, j) = q |i-j| , where q is the base distance, 0 < q < 1 and is defined as the distance value between two consecutive options. We assume that there is a limited range for the ratings in the rating system. The main condition is that the sum of all distances must be equal to a constant value, we call it propagation parameter and is denoted as b. The propagation parameter is a positive value which controls the proportion of credibility propagation among options. By taking into account this condition, we have

q + q 2 + • • • + q n l -j + q + q 2 + • • • + q j-1 = b ⇔ q 1 -q n l -j 1 -q + q 1 -q j-1 1 -q = b ⇔ 2 -q j-1 -q n l -j = b 1 -q q (4)
Note that since 0 < q < 1, Eq. ( 4) has only one real solution for each positive value of b.

Provenance-Aware Credibility Propagation

Given the distance function d(i, j) for computing the numerical distance between options i and j, we update our computation equations for the credibility degree as well as users' trustworthiness. Firstly, we define β li as the non-normalized credibility degree of quality level li. Considering the idea of credibility propagation among the options, the credibility degree of a quality level is obtained not only from the raters who have chosen such particular level, but also from all raters who rated such item with proportion to the distance of their choices from such level. In other words, we define the credibility degree for a quality level in an item as amount of credibility which such level can obtain from all raters who rated such an item. Therefore, we reformulate the Eq. ( 1) for computing the non-normalized credibility degree of quality level li as follows:

β li = j,r : r→lj (T r ) α d(i, j) (5)
As we mentioned some rating systems provide contextual information about the ratings, we call it rating provenance. It contains attributes such as watching duration in a movie ratings system and educational level of raters in a student feedback system, which provides more information about either the raters or the environment of ratings. Since the rating provenance provides informative data about the quality of ratings, a reputation system needs to take into account these data in the its computations. In this paper, we propose a provenance model based on the attributes provided by a student feedback system which includes two contextual attributes: staff/non-staff and watching behaviour of students. We note that the approach can be easily adapted for other contextual attributes. This provenance model is based on the approach from [START_REF] Wang | ARTSense: Anonymous reputation and trust in participatory sensing[END_REF], originally proposed in the context of participatory sensing.

The main idea of our provenance model is to define a weight function for considering the contextual attributes provided by the rating system. To this end, we define a weight function for each attribute and then we aggregate all the weights from these functions using the simple product of the weights to obtain the provenance weight. Such provenance weight is used to assess the credibility level as well as users' trustworthiness.

In the student feedback system, users are asked to rate the movies in an online course. In this system, each user has an status which indicates whether such user is staff or non-staff. Moreover, the system provides for each rating the time spent for watching the movie. We utilize both the staff status and watching duration as two contextual attributes to model the rating provenance. To this end, we consider a somewhat higher credibility for the staff raters. Thus, we define the staff weight, denoted as w s , which is set w s = 0.98 for staff raters and w s = 0.95 for non-staff raters. Moreover, we take into account the watching time due to the fact that a student who spends enough time to watch a movie can provide higher quality ratings. We denote the watching time provided for each rating and the original duration of its corresponding movie as T r and T v , respectively. Thus, we compute the gap between them by |min{T r , T v } -T v |. Now, we define the watching time weight, denoted as w t :

w t = e -|min{Tr,Tv}-Tv|×β (6)
where 0 ≤ β ≤ 1 is the duration sensitivity parameter which controls the watching time weight. Note that Eq. ( 6) makes w t equal to 1 when the time gap between the watching and duration is 0 and w t approaches 0 when such gap is large. Given both staff and watching time weights, we define provenance weight, denoted as w p through aggregating these two weights as:

w p = w s × w t (7)
Note that in general the provenance weight can be define as the product of the weight values for all contextual attributes, where such weights are in the range of [0,1]. Given the provenance weight, we re-write Eq. ( 5) as follows:

β li = j,r : r→lj (T r ) α × d(i, j) × w p (8)
For normalizing the credibility degree, we use the same method used in our previous approach which is:

ρ li = β li 1≤j≤n l (β lj ) 2 (9)
The trustworthiness of a user is the weighted sum of all credibility degrees from all quality levels of items which has been rated by such user. The weight here is the distance between the chosen level by such user and the credible level. Thus, we have

T r = l,i : r→li 1≤j≤n l ρ li × d(i, j) × w p (10)
Note that we formulated the uncertainty in rating systems through both credibility propagation among options and rating provenance. Thus, we considered them in computing both credibility degrees and users' trustworthiness.

Iterative Vote Aggregation

Given equations ( 8), ( 9) and ( 10), we have interdependent definitions for credibility degree and trustworthiness. Clearly, the credibility degree of a quality level in for item depends on the trustworthiness of users who rated such item. on the other hand, the trustworthiness of a user depends on the credibility of the quality levels of the items which have been rated by such user. Thus, we propose an iterative algorithm to compute both the credibility degrees and trust scores simultaneously in a single recursive procedure. We denote the non-normalized credibility, normalized credibility and trustworthiness at iteration l as β

(l) li , ρ (l) li and T (l)
r , respectively which are computed from the values obtained in the previous iteration of the algorithm.

Algorithm 1 shows our iterative process for computing the credibility and trustworthiness values. One can see that the algorithm starts with identical trust scores for all users, T (0) r = 1. In each iteration, it first compute the nonnormalized credibility degree β li . After obtaining the normalized credibility degree ρ li for all options, the trustworthiness for all users are updated. The iteration will stop when there is no considerable changes for the credibility degrees.

Algorithm 1 Iterative algorithm to compute the credibility and trustworthiness.

1: procedure CredTrustComputation(A, b, α, n l ) 2:

Compute q using (4) 3:

d(i, j) ← q |i-j| for each 1 ≤ i, j ≤ n l 4:

T (0) r ← 1 5: l ← 0 6: repeat 7:
Compute β li using ( 5) for each level i and item l 8:

Compute ρ li using ( 9) for each level i and item l 9:

Compute Tr using [START_REF] Morgan | Reputation in online auctions: The market for trust[END_REF] for each each use r 10:

l ← l + 1 11:

until credibilities have converged 12:

Return ρ and T 13: end procedure

Multi-dimensional Reputation

As we discussed, a reputation system needs to consider the correlation among raters' perceptions among multiple categories. The eBay's feedback system and student course evaluation in educational systems are two examples of rating systems with multiple categories. A traditional approach is to apply the computations over the ratings of each category, separately. However, the correlation among ratings in various categories can help a reputation system to accurately assess the quality of ratings [START_REF] Tang | mTrust: Discerning multi-faceted trust in a connected world[END_REF].

In Eq. ( 3) we proposed a aggregation method for single category rating system. In this method, the final reputation of an item is obtained from an aggregate of the credibility values of different options for such item. In order to extend this method to multi-dimensional rating systems, we first perform Algorithm 1 over each category to obtain K weights for each user (Note that we have K dimensions in the ratings). Then, we aggregate the weights using simple averaging to obtain the final users' trustworthiness. Thereafter, we employ a weighted averaging method to compute the final reputation of item l in category k, as follows

R(π lk ) = i,r : r→lik i × ( Tr ) p i,r : r→lik ( Tr ) p (11)
where r → lik denotes that user r chose option I l i from list Λ l for category k. Tr is the average of weights of user r obtained by applying Algorithm 1 over the ratings of different categories. Moreover, constant p ≥ 1 is a parameter for controlling the averaging affect.

Experiments

In this section, we detail the steps taken to evaluate the robustness and effectiveness of our approach in the presence of faults and unfair rating attacks.

Experimental Environment

Although there are a number of real world datasets for evaluating reputation systems such as MovieLens8 and HetRec 2011 9 , none of them provides a clear ground truth. Thus, we conduct our experiments by both real-world datasets and generating synthetic datasets.

We generate the synthetic datasets by using statistical parameters of the MovieLens 100k dataset, as shown in Table 1. The quality of each movie has been uniformly randomly selected from the range [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF][START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF]. In addition, we consider a zero mean Gaussian noise for ratings of each user with different variance values for the users. All ratings are also rounded to be discrete values in the range of [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF][START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF]. We conducted parameter analysis experiments to find the values of parameters α, p and b. The results of these experiments are reported in [START_REF] Rezvani | An iterative algorithm for reputation aggregation in multi-dimensional and multinomial rating systems[END_REF] and consequently we choose α = 2, p = 2 and b = 0.5 for our subsequent experiments. In all experiments, we compare our approach against three other IF techniques proposed for reputation systems. Table 2 shows a summary of discriminant functions for these IF methods. We also call our new method PrRTV and the previous one BasicRTV, briefly presented in Section 2.2.

Robustness Against False Ratings

In order to evaluate robustness of our algorithm against false ratings, we conduct experiments based on two types of malicious behaviour proposed in [START_REF] De Kerchove | Iterative filtering in reputation systems[END_REF] over the MovieLens dataset: Random Ratings, and a Promoting Attack. For random ratings, we modify the rates of 20% of the users within the original MovieLens dataset by injecting uniformly random rates in the range of [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF][START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF] for those users.

In slandering and promoting attacks, one or more users falsely produce negative and positive ratings, respectively, about one or more items [START_REF] Hoffman | A survey of attack and defense techniques for reputation systems[END_REF]. The attacks

w l+1 i = 1 -k 1 T xi -r l+1 2 2 Zhou [20] w l+1 i = 1 T T i=1 x t i -x t σx i r t -r σr Laureti [6] w l+1 i = ( 1 T xi -r l+1 2 2 ) -1 2
can be conducted by either an individual or a coalition of attackers. We evaluate our approach against a promotion attack by considering 20% of the users as the malicious users involved in the attack. In this attack, malicious users always rate 1 except for their preferred movie, which they rate 5.

Let r and r be the reputation vectors before and after injecting false ratings in each scenario (random ratings and promoting attack), respectively. In the proposed reputation system, the vectors are the results of Eq. [START_REF] Mukherjee | Spotting fake reviewer groups in consumer reviews[END_REF]. Table 3 reports the 1-norm difference between these two vectors, ||r -r|| 1 = m j=1 |r j -rj | for our algorithm along with other IF algorithms. Clearly, all of the IF algorithms are more robust than Average. In addition, the PrRTV algorithm provides higher accuracy than other methods for both false rating scenarios. The results can be explained by the fact that the proposed algorithm effectively filters out the contribution of the malicious users.

Rating Resolutions and Users Variances

In this section, we investigate the accuracy of PrRTV over the low resolution ratings and different variance scales using synthetic datasets. The ratings scale is in the range of [1, R], where R is an integer number and R ≥ 2. Also, the standard deviation σ i for user i is randomly selected by a uniform distribution U[0; σ max ], where σ max is a real value in the range of [0, R-1]. We also evaluate a normalized RMS error, RM SE/(R -1) (see [START_REF] Rezvani | An iterative algorithm for reputation aggregation in multi-dimensional and multinomial rating systems[END_REF] for RMS Error) for each experiment. In this section, we investigate the accuracy of our reputation system against various values for both rating resolution R and variance scale σ max .

For the first experiment, we set R = 5 and vary the value of σ max in the range of [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF][START_REF] De Kerchove | Iterative filtering in reputation systems[END_REF]. By choosing such a range at the worst case, a highest noisy user with σ i = σ max = 4 could potentially report a very low reputation for an item with a real reputation of 5, and vice versa. Fig. 1(a) shows the accuracy of the PrRTV algorithm along with the accuracy of the other IF algorithms for this experiment. We observe that PrRTV is the least sensitive to the increasing error level, maintaining the lowest normalized RMS error.

In order to investigate the effect of changing the ratings' resolution, we set σ max = R-1 and vary the value of R in the range of [START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF][START_REF] Morgan | Reputation in online auctions: The market for trust[END_REF], so that the maximum possible users' errors cover the ratings' scale. Fig. 1(b) shows the accuracy of the algorithms for this experiment. As we can see, although the accuracy of the PrRTV algorithm is higher than the accuracy of other IF algorithms, the algorithm provides more sensitivity for the high resolution values. In other words, the accuracy of our reputation system significantly drops as the ratings resolution increases. The reason of this behaviour is that Eq. ( 11) for computing the final rating scores gives more credibility to the options with higher numerical values, particularly when there is a large distance between lowest and highest options in the ratings scales. We plan to extend our reputation aggregation method to provide more robustness for high resolution rating systems.

Accuracy Over HetRec 2011 MovieLens Dataset

In this section, we evaluate the performance of our reputation system based on the accuracy of the ranked movies in the HetRec 2011 MovieLens dataset. This dataset links the movies in the MovieLens dataset with their corresponding web pages at Internet Movie Database (IMDb) 10 and Rotten Tomatoes movie critics systems 11 . Thus, we use the top critics ratings from Rotten Tomatoes as the domain experts for evaluating the accuracy of our approach.

There are 10,109 movies in the HetRec 2011 MovieLens dataset rated by users. The dataset also includes the average ratings of the top and all critics of Rotten Tomatoes for 4645 and 8404 movies, respectively. We consider such average ratings as two ground truth to evaluate the accuracy of our approach and we call them RTTopCritics and RTAllCritics, respectively. In order to clearly compare the results of our reputation system with those provided by RTTopCritics and RTAllCritics, we first classify the movies by randomly assigning every 100 movies in a class. We then compute two average values for each class: the average of reputation values given by our algorithm and the average of rating given by RTTopCritics and RTAllCritics. Now, we use such average values to compare the reputations given by our algorithm with the ratings of RTTopCrit- ics and RTAllCritics. Note that this method is employed only for clarifying this over such large number of movies. Fig. 2(a) and 2(b) illustrate the comparison between the results of our algorithm with the ratings provided by RTTopCritics and RTAllCritics, respectively. The results confirm that the reputation values given by our algorithm is very close to the experts opinions given by RTCritics. Moreover, comparing the results of PrRTV with BasicRTV shows that the PrRTV algorithm provide a better accuracy than the BasicRTV algorithm as its aggregate ratings are more closer to the ratings provided by Rotten Tomatoes critics. As one can see, our algorithm ranks the movies slightly higher than RTCritics ratings for all classes. This can be explained by the fact that the ratings of our algorithm are based on the scores provided by public users through the MovieLens web site. However, both RTTopCritics and RTAllCritics ratings provided by Rotten Tomatoes critics who tend to rank the movies more critically.

Accuracy Over Student Feedback Dataset

In this section, we evaluate the effectiveness of our reputation system using a privately accessed student feedback dataset provided by the Learning and Teaching Unit at UNSW, called CATEI. The dataset consists of 17,854 ratings provided by 3,910 students (221 staffs and 3,690 non-staffs) for 20 movies in an online course presented in UNSW. In the CATEI dataset, students were asked to rate the movies in the range of [START_REF] Allahbakhsh | An iterative method for calculating robust rating scores[END_REF][START_REF] Hoffman | A survey of attack and defense techniques for reputation systems[END_REF][START_REF] Kamvar | The eigentrust algorithm for reputation management in P2P networks[END_REF][START_REF] De Kerchove | Iterative filtering in reputation systems[END_REF][START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF] and for three different categories: Useful (U ), UnderstandContent (UC ), FurtherExplore (FE ). Moreover, the dataset includes the starting and ending times of the watching of the movie for each rating which allow us to compute the watching duration for each rating. We also set the duration sensitivity, β = 0.2 for computing the watching time weight of each rating. As we mentioned in Section 3.2, the rating provenance is obtained as the product of staff weight and watching weigh for each rating.

In the first part of the experiments over the CATEI dataset, we apply the IF algorithms over each rating category separately and then investigate the correlation between the obtained users' weights. We expected to observe high correlation among the weights on different categories. We first obtained all the users' Fig. 3: Users' weights obtained by the IF algorithms over three categories. weights, then sorted them in an increasing order based on the Useful category. Fig. 3 compares the users' weights among three categories obtained by each IF algorithm. Moreover, Table 4 reports the Pearson correlation coefficient among such weight values. One can see in the results that our reputation system provides the highest correlation among the weights for various categories. This can validate the effectiveness of our approach over the CATEI dataset. In Section 3.4, we proposed the idea of aggregation of users' weights obtained for each category to obtain the final reputation values over multi-dimensional rating datasets. A traditional approach is to separately apply the reputation system over each dimension. In order to investigate the effectiveness of the proposed approach, we evaluate the correlation among the reputation values for various categories over the CATEI dataset for these two methods. To this end, we first perform the IF algorithms over each category and compute the correlation among the obtained reputation vectors for each category. After that, we perform the proposed method in Section 3.4, and compute the correlation among the new reputation vectors. Table 5 reports the percentage of increasing such correlation among categories by performing our multi-dimensional reputation method. One can see that our approach improved the average correlation value for all four algorithms. The results also show a significant improvement in the Zhou algorithm. This can be explained by some negative correlations obtained by the algorithm using the traditional reputation computation method. According to several research evidences, as the reliance of the users of online stores on the rating systems to decide on purchasing a product constantly increases, more efforts are put in building up fake rating or reputation scores in order to gain more unfair income [START_REF] Wang | Serf and turf: crowdturfing for fun and profit[END_REF]. To solve this problem, Mukherjee et.al., [START_REF] Mukherjee | Spotting fake reviewer groups in consumer reviews[END_REF] proposed a model for spotting fake review groups in online rating systems. The model analyzes feedbacks cast on products in Amazon online market to find collusion groups. In a more general setup, detection of unfair ratings has been studied in P2P and reputation management systems; good surveys can be found in [START_REF] Sun | Security of online reputation systems: The evolution of attacks and defenses[END_REF]. EigenTrust [START_REF] Kamvar | The eigentrust algorithm for reputation management in P2P networks[END_REF] is a well known algorithm as a robust trust computation system. However, Lian et al. [START_REF] Lian | An empirical study of collusion behavior in the maze P2P file-sharing system[END_REF] demonstrate that it is not robust against collusion. Another series of works [START_REF] Liu | Detection of collusion behaviors in online reputation systems[END_REF][START_REF] Yang | RepTrap: a novel attack on feedback-based reputation systems[END_REF][START_REF] Yang | Dishonest behaviors in online rating systems: cyber competition, attack models, and attack generator[END_REF] use a set of signals and alarms to point to a suspicious behavior. The most famous ranking algorithm of all, the PageRank algorithm [START_REF] Langville | Google's PageRank and Beyond:The Science of Search Engine Rankings[END_REF] was also devised to prevent collusive groups from obtaining undeserved ranks for webpages. Several papers have proposed IF algorithms for reputation systems [START_REF] De Kerchove | Iterative filtering in reputation systems[END_REF][START_REF] Laureti | Information filtering via Iterative Refinement[END_REF][START_REF] Zhou | A robust ranking algorithm to spamming[END_REF]. While such IF algorithms provide promising performance for filtering faults and simple cheating attacks, we recently showed that they are vulnerable against sophisticated attacks [START_REF] Rezvani | Secure data aggregation technique for wireless sensor networks in the presence of collusion attacks[END_REF]. In this paper, we compared the robustness of our approach with some of the existing IF methods.

The method we propose in this paper is different from the existing related work, mainly from its ancestor RTV, from three various aspects. First, the distance between the options is taken into account in this work. Second, reputation scores are in fact multi dimensional. Finally, the provenance of rating scores are considered while giving credit and weight to them. To the best of our knowledge, no existing work considers all of these issues in reputation systems.

Conclusions

In this paper, we proposed a novel reputation system which leverages the distance between the quality levels, provenance of cast rating scores and multidimensional reputation scores to address the problem of robust reputation aggregation. The experiments conducted on both synthetic and real-world data show the superiority of our model over three well-known iterative filtering algorithms. Since the proposed framework has shown a promising behaviour, we plan to extend the algorithm to propose a distributed reputation system.

Fig. 1 :

 1 Fig. 1: Accuracy with different variances and resolutions.

Fig. 2 :

 2 Fig. 2: Average reputations obtained by our algorithms and RTCritics.

Table 1 :

 1 MovieLens 100k dataset statistics.

	Parameter	MovieLens 100k
	Ratings	100,000
	Users	943
	Movies	1682
	# of votes per user	Beta(α = 1.32, β = 19.50)

Table 2 :

 2 Summary of different IF algorithms.

	Name	Discriminant Function
	dKVD-Affine [4]

Table 3 :

 3 1-norm absolute error between reputations by injecting false ratings.

			r -r 1
	Average dKVD-Affine Laureti BasicRTV PrRTV
	Random Ratings 205.32	152.40	171.55 152.75 151.54
	Promoting Attack 579.65	378.29	377.72 894.25 368.81

Table 4 :

 4 Correlation among users' weights over three categories.

		dKVD-Affine Laureti Zhou PrRTV
	U and UC	0.52	0.42 0.58 0.96
	U and FE	0.61	0.40 0.61 0.97
	UC and FE	0.45	0.50 0.63 0.97

Table 5 :

 5 Percentage of increasing correlation among reputations by aggregating the weights obtained through each category.

		dKVD-Affine Laureti Zhou PrRTV
	U and UC	0.70	2.79 2.80 13.90
	U and FE	0.03	8.54 72.12 -0.65
	UC and FE	-0.26	0.12 0.09 -0.73
	Average	0.16	3.81 25.00 4.17

http://www.amazon.com/

http://www.ebay.com/

http://www.ebay.com/gds/

http://grouplens.org/datasets/movielens/

http://grouplens.org/datasets/hetrec-2011/

http://www.imdb.com/

http://www.rottentomatoes.com/critics/