multiparty authorization framework for data sharing in ......access control requirements with...

Multiparty Authorization Framework for Data Sharingin Online Social Networks�

Hongxin Hu and Gail-Joon Ahn

Arizona State University, Tempe, AZ 85287, USA{hxhu,gahn}@asu.edu

Abstract. Online social networks (OSNs) have experienced tremendous growthin recent years and become a de facto portal for hundreds of millions of Internetusers. These OSNs offer attractive means for digital social interactions and in-formation sharing, but also raise a number of security and privacy issues. WhileOSNs allow users to restrict access to shared data, they currently do not provideeffective mechanisms to enforce privacy concerns over data associated with mul-tiple users. In this paper, we propose a multiparty authorization framework thatenables collaborative management of shared data in OSNs. An access controlmodel is formulated to capture the essence of multiparty authorization require-ments. We also demonstrate the applicability of our approach by implementing aproof-of-concept prototype hosted in Facebook.

Keywords: Social network, Multiparty, Access control, Privacy, Data sharing.

1 Introduction

In recent years, we have seen unprecedented growth in the application of OSNs. Forexample, Facebook, one of representative social network sites, claims that it has over500 million active users and over 30 billion pieces of shared contents each month [2],including web links, news stories, blog posts, notes and photo albums. To protect userdata, access control has become a central feature of OSNs [1,3].

A typical OSN provides each user with a virtual space containing profile informa-tion, a list of the user’s friends, and web pages, such as wall in Facebook, where usersand friends can post contents and leave messages. A user profile usually includes infor-mation with respect to the user’s birthday, gender, interests, education and work history,and contact information. In addition, users can not only upload a content into their ownor others’ spaces but also tag other users who appear in the content. Each tag is anexplicit reference that links to a user’s space. For the protection of user data, currentOSNs indirectly require users to be system and policy administrators for regulatingtheir data, where users can restrict data sharing to a specific set of trusted users. OSNsoften use user relationship and group membership to distinguish between trusted anduntrusted users. For example, in Facebook, users can allow friends, friends of friends,specific groups or everyone to access their data, relying on their personal authorizationand privacy requirements.

� This work was partially supported by the grants from National Science Foundation (NSF-IIS-0900970 and NSF-CNS-0831360) and Department of Energy (DE-SC0004308).

Y. Li (Ed.): Data and Applications Security and Privacy XXV, LNCS 6818, pp. 29–43, 2011.c© IFIP International Federation for Information Processing 2011

30 H. Hu and G.-J. Ahn

Although OSNs currently provide simple access control mechanisms allowing usersto govern access to information contained in their own spaces, users, unfortunately,have no control over data residing outside their spaces. For instance, if a user posts acomment in a friend’s space, s/he cannot specify which users can view the comment. Inanother case, when a user uploads a photo and tags friends who appear in the photo, thetagged friends cannot restrict who can see this photo, even though the tagged friendsmay have different privacy concerns about the photo. To address such an issue, pre-liminary protection mechanisms have been offered by existing OSNs. For example,Facebook allows tagged users to remove the tags linked to their profiles. However, re-moving a tag from a photo can only prevent other members from seeing a user’s profileby means of the association link, but the user’s image is still contained in the photo.Since original access control policies cannot be changed, the user’s image continues tobe accessed by all authorized users. Hence, it is essential to develop an effective andflexible access control mechanism for OSNs, accommodating the special authorizationrequirements coming from multiple associated users for collaboratively managing theshared data.

In this paper, we propose a multiparty authorization framework (MAF) to modeland realize multiparty access control in OSNs. We begin by examining how the lack ofmultiparty access control for data sharing in OSNs can undermine the protection of userdata. A multiparty authorization model is then formulated to capture the core featuresof multiparty authorization requirements which have not been accommodated so far byexisting access control systems and models for OSNs (e.g., [6,7,13,14,19]). Meanwhile,as conflicts are inevitable in multiparty authorization specification and enforcement,systematic conflict resolution mechanism is also addressed to cope with authorizationand privacy conflicts in our framework.

The rest of the paper is organized as follows. Section 2 gives a brief overview ofrelated work. In Section 3, we present multiparty authorization requirements and artic-ulate our proposed multiparty authorization model, including multiparty authorizationspecification and multiparty policy evaluation. Implementation details and experimentalresults are described in Section 4. Section 5 concludes this paper.

2 Related Work

Access control for OSNs is still a relatively new research area. Several access controlmodels for OSNs have been introduced (e.g., [6,7,13,14,19]). Early access control so-lutions for OSNs introduced trust-based access control inspired by the developmentsof trust and reputation computation in OSNs. The D-FOAF system [19] is primarily aFriend of a Friend (FOAF) ontology-based distributed identity management system forOSNs, where relationships are associated with a trust level, which indicates the level offriendship between the users participating in a given relationship. Carminati et al. [6]introduced a conceptually-similar but more comprehensive trust-based access controlmodel. This model allows the specification of access rules for online resources, whereauthorized users are denoted in terms of the relationship type, depth, and trust level be-tween users in OSNs. They further presented a semi-decentralized discretionary accesscontrol model and a related enforcement mechanism for controlled sharing of informa-tion in OSNs [7]. Fong et al. [14] proposed an access control model that formalizes

Multiparty Authorization Framework for Data Sharing in Online Social Networks 31

and generalizes the access control mechanism implemented in Facebook, admitting ar-bitrary policy vocabularies that are based on theoretical graph properties. Gates [8]described relationship-based access control as one of new security paradigms that ad-dresses unique requirements of Web 2.0. Then, Fong [13] recently formulated thisparadigm called a Relationship-Based Access Control (ReBAC) model that bases au-thorization decisions on the relationships between the resource owner and the resourceaccessor in an OSN. However, none of these existing work could model and analyzeaccess control requirements with respect to collaborative authorization management ofshared data in OSNs.

Recently, semantic web technologies have been used to model and express fine-grained access control policies for OSNs (e.g., [5,10,21]). Especially, Carminati etal. [5] proposed a semantic web based access control framework for social networks.Three types of policies are defined in their framework, including authorization policy,filtering policy and admin policy, which are modeled with the Web Ontology Language(OWL) and the Semantic Web Rule Language (SWRL). Access control policies regu-late how resources can be accessed by the participants; filtering policies specify howresources have to be filtered out when a user fetches an OSN page; and admin policiescan determine who is authorized to specify policies. Although they claimed that flexibleadmin policies are needed to bring a system to a scenario where several access controlpolicies specified by distinct users can be applied to the same resource, the lack of for-mal descriptions and concrete implementation of the proposed approach leaves behindthe ambiguities of their solution.

The need of joint management for data sharing, especially photo sharing, in OSNshas been recognized by the recent work [4,24,26]. The closest work to this paper isprobably the solution provided by Squicciarini et al. [24] for collective privacy man-agement in OSNs. Their work considered access control policies of a content that isco-owned by multiple users in an OSN, such that each co-owner may separately spec-ify her/his own privacy preference for the shared content. The Clarke-Tax mechanismwas adopted to enable the collective enforcement of policies for shared contents. Gametheory was applied to evaluate the scheme. However, a general drawback of their solu-tion is the usability issue, as it could be very hard for ordinary OSN users to comprehendthe Clarke-Tax mechanism and specify appropriate bid values for auctions. In addition,the auction process adopted in their approach indicates that only the winning bids coulddetermine who can access the data, instead of accommodating all stakeholders’ privacypreferences. In contrast, our work proposes a formal model to address the multipartyaccess control issue in OSNs, along with a general policy specification scheme anda simple but flexible conflict resolution mechanism for collaborative management ofshared data in OSNs.

Other related work include general conflict resolution mechanisms for access con-trol [12,15,16,17,18,20] and learn-based generation of privacy policies for OSNs[11,22,23]. All of those related work are orthogonal to our work.

3 Multiparty Authorization for OSNs

In this section, we analyze the requirements of multiparty authorization (Section 3.1)and address the modeling approach we utilize to represent OSNs (Section 3.2). We also


(a) A shared data item has multiple stakehold-ers

(b) A shared data item is published by a con-tributor

Fig. 1. Scenarios of Multiparty Authorization in OSNs

introduce a policy scheme (Section 3.3) and an authorization evaluation mechanism(Section 3.4) for the specification and enforcement of multiparty access control policiesin OSNs.

3.1 Requirements

OSNs provide built-in mechanisms enabling users to communicate and share data withother members. OSN users can post statuses and notes, upload photos and videos intheir own spaces, and tag others to their contents and share the contents with theirfriends. On the other hand, users can also post contents in their friends’ spaces. Theshared contents may be connected with multiple users. Consider an example where aphotograph contains three users, Alice, Bob and Carol. If Alice uploads it to her ownspace and tags both Bob and Carol in the photo, we call Alice an owner of the photo,and Bob and Carol stakeholders of the photo. All of these users may specify accesscontrol policies over this photo. Figure 1(a) depicts a data sharing scenario where theowner of a data item shares the data item with other OSN members, and the data itemhas multiple stakeholders who may also want to involve in the control of data sharing.In another case, when Alice posts a note stating “I will attend a party on Friday nightwith @Carol” to Bob’s space, we call Alice a contributor of the note and she maywant to make the control over her notes. In addition, since Carol is explicitly identifiedby @-mention (at-mention) in this note, she is considered as a stakeholder of the noteand may also want to control the exposure of this note. Figure 1(b) shows another datasharing scenario where a contributor publishes a data item to someone else’s space andthe data item may also have multiple stakeholders (e.g., tagged users). All associatedusers should be allowed to define access control policies for the shared data item.

OSNs also enable users to share others’ data. For example, when Alice views a photoin Bob’s space and selects to share this photo with her friends, the photo will be in turnposted to her space and she can specify access control policies to authorize her friendsto see this photo. In this case, Alice is a disseminator of the photo. Since Alice mayadopt a weaker control saying the photo is visible to everyone, the initial access con-trol requirements of this photo should be complied with, preventing from the possibleleakage of sensitive information via the procedure of data dissemination. For a morecomplicated case, the disseminated data may be further re-disseminated by dissemi-nator’s friends, where effective access control mechanisms should be applied in each


procedure to regulate sharing behaviors. Especially, regardless of how many steps thedata item has been re-disseminated, the original access control policies should be al-ways enforced to protect the data dissemination.

3.2 Modeling Social Networks

An OSN can be represented by a relationship network, a set of user groups and a collec-tion of user data. The relationship network of an OSN is a directed labeled graph, whereeach node denotes a user, and each edge represents a relationship between users. Thelabel associated with each edge indicates the type of the relationship. Edge direction de-notes that the initial node of an edge establishes the relationship and the terminal nodeof the edge accepts the relationship. The number and type of supported relationshipsrely on the specific OSNs and its purposes. Besides, OSNs include an important fea-ture that allows users to be organized in groups [28,27], where each group has a uniquename. This feature enables users of an OSN to easily find other users with whom theymight share specific interests (e.g., same hobbies), demographic groups (e.g., studyingat the same schools), political orientation, and so on. Users can join in groups with-out any approval from other group members. Furthermore, OSNs provide each memberwith a web space where users can store and manage their personal data including profileinformation, friend list and user content.

We now formally model and define an online social network as follows:

Definition 1 (Online Social Network). An online social network is modeled as a 9-tuple OSN =< U, G, PC, RT, RC, TT, CC, UU, UG >, where

– U is a set of users of the OSN. Each user has a unique identifier;– G is a set of groups to which the users can belong. Each group also has a unique identifier;– PC is a collection of user profile sets, {p1, . . . , pn}, where pi = {pi1, . . . , pim} is the

profile set of a user i ∈ U . Each profile entry is a <attribute: profile value> pair, pij =<attrj : pvaluej >;

– RT is a set of relationship types supported by the OSN. Each user in an OSN may be con-nected with others by relationships of different types;

– RC is a collection of user relationship sets, {r1, . . . , rn}, where ri = {ri1, . . . , rim} is therelationship set of a user i ∈ U . Each relationship entry is a <user: relationship type> pair,rij =< uj : rtj >, where uj ∈ U and rtj ∈ RT ;

– TT is a set of content types supported by the OSN. Supported content types are photo, video,note, event, status, message, link, and so on;

– CC is a collection of user content sets, {c1, . . . , cn}, where ci = {ci1, . . . , cim} is a setof contents of a user i ∈ U . Each content entry is a <content: content type> pair, cij =<contj : ttj >, where contj is a content identifier and ttj ∈ TT ;

– UU is a collection of uni-directional binary user-to-user relations, {UUrt1 , . . . , UUrtn},where UUrti ⊆ U × U specifies the pairs of users in a relationship type rti ∈ RT ; and

– UG ⊆ U × G is a binary user-to-group membership relation;

Figure 2 shows an example of social network representation. It describes relationshipsof five individuals, Alice (A), Bob (B), Carol (C), Dave (D) and Edward (E), alongwith their groups of interest and their own spaces of data. Note that two users may bedirectly connected by more than one edge labeled with different relationship types inthe relationship network. For example, in Figure 2, Alice (A) has a direct relationship


Fig. 2. An Example of Social Network Representation

of type colleagueOf with Bob (B), whereas Bob (B) has a relationship of friendOf withAlice (A). Moreover, in this example, we can notice there are two groups that users canparticipate in: the “Fashion” group and the “Hiking” group, and some users, such asAlice (A) and Edward (E), may join in multiple groups.

3.3 Multiparty Authorization Specification

To enable a collaborative authorization management of data sharing in OSNs, it is es-sential for multiparty access control policies to be in place to regulate access over shareddata, representing authorization requirements from multiple associated users. Our pol-icy specification scheme is built upon the above-mentioned OSN model (Section 3.2).

Recently, several access control schemes (e.g., [6,13,14]) have been proposed to sup-port fine-grained authorization specifications for OSNs. Unfortunately, these schemescan only allow a single controller (the resource owner) to specify access control poli-cies. Indeed, a flexible access control mechanism in a multi-user environment like OSNsis necessary to allow multiple controllers associated with the shared data item to spec-ify access control policies. As we discussed in Section 3.1, in addition to the owner ofdata, other controllers, including the contributor, stakeholder and disseminator of data,also desire to regulate access to the shared data. We formally define these controllers asfollows:

Definition 2 (Owner). Let d be a shared data item in the space of a user i ∈ U in thesocial network. The user i is called the owner of d, denoted as OW i

d.

Definition 3 (Contributor). Let d be a shared data item published by a user i ∈ U insomeone else’s space in the social network. The user i is called the contributor of d,denoted as CBi

d.

Definition 4 (Stakeholder). Let d be a shared data item published in the space of auser in the social network. Let T be the set of tagged users associated with d. A useri ∈ U is called a stakeholder of d, denoted as SHi

d, if i ∈ T .


Fig. 3. Hierarchical User Data in OSNs

Definition 5 (Disseminator). Let d be a shared data item disseminated by a user i ∈ Ufrom someone else’s space to her/his space in the social network. The user i is called adisseminator of d, denoted as DSi

d.

In the context of an OSN, user data is composed of three types of information: Userprofile describes who the user is in the OSN, including identity and personal informa-tion, such as name, birthday, interests and contact information. User relationship showswho the user knows in the OSN, including a list of friends to represent the connectionswith family members, coworkers, colleagues, and so on. User content indicates whatthe user has in the OSN, including photos, videos, statuses, and all other data objectscreated through various activities in the OSN. Formally, we define user data as follows:

Definition 6 (User Data). The user data is a collection of data sets, {d1, . . . , dn},where di = pi ∪ ri ∪ ci is a set of data of a user i ∈ U representing the user’s profilepi, the user’s relationship list ri, and the user’s content set ci, respectively.

User data in OSNs can be organized as a hierarchical structure, whose leaves representthe instances of data, and whose intermediate nodes represent classifications of data.Figure 3 depicts a hierarchical structure of user data where the root node, user data, isclassified into three types, profile, relationship and content. The content is further di-vided into multiple categories, such as photo, video, note, event, status, etc. In this way,access control policies can be specified over both data classifications and instances. Es-pecially, access control policies specified on classifications can be automatically propa-gated down in the hierarchy. For instance, if access for the parent node photo is allowed,access for all children nodes of photo is also allowed. As a consequence, such a hierar-chical structure of user data can be used to improve the expressiveness of access controlpolicies and simplify the authorization management.

To summarize the aforementioned features and elements, we introduce a formal def-inition of multiparty access control policies as follows:

Definition 7 (Multiparty Access Control Policy). A multiparty access control policy isa 7-tuple P =< controller, ctype, accessor, atype, data, action, effect >, where


– controller ∈ U is a user who can regulate access to data;– ctype ∈ {OW, CB, SH, DS} is the type of the controller (owner, contributor,

stakeholder, and disseminator, respectively);– accessor is a set of users to whom the authorization is granted, representing with

a set of user names, a set of relationship types or a set of group names. Note thatpatterns are allowed to specify any set by using the the wildcard (*) instead of aspecific name;

– atype ∈ {UN, RN, GN} is the type of the accessor specification (user name,relationship type, and group name, respectively);

– data ∈ di ∪ TT ∪ DT is a data item dij ∈ di, a content type tt ∈ TT , or a datatype dt ∈ DT = {profile, relationship, content}, where i ∈ U ;

– action = view is an action being authorized or forbidden;1 and– effect ∈ {permit, deny} is the authorization effect of the policy.

Note that different representations of accessor in our policy specification scheme havedifferent semantics. If the accessor is represented with a set of user names {u1, . . . , un},the semantics of this user name set can be explained as u1 ∨ . . .∨un, which means thatany user contained in the user name set is treated as an authorized accessor. On the otherhand, if the accessor is expressed as a set of relationship types {rt1, . . . , rtn} or a setof group names {g1, . . . , gn}, the semantics of the relationship type set or group nameset are interpreted as rt1 ∧ . . . ∧ rtn or g1 ∧ . . . ∧ gn. Examples of multiparty accesscontrol policies are as follows:

1. p1 = (Alice, OW, {friendOf}, RN, < statusId, status >, view, permit):Alice authorizes her friends to view her status identified by statusId. In this pol-icy, Alice is an owner of the status.

2. p2 = (Bob, CB, {colleageOf}, RN, photo, view, permit): Bob authorizes hiscolleagues to view all photos he publishes to others’ spaces. In this policy, Bob isa contributor of the photos.

3. p3 = (Carol, ST, {friendOf, colleageOf}, RN, < photoId, photo >, view,permit): Carol authorizes users who are both her friends and her colleagues toview one photo photoId she is tagged in. In this policy, Carol is a stakeholder ofthe photo.

4. p4 = (Dave, OW, {Bob, Carol}, UN, < eventId, event >, view, deny): Davedisallows Bob and Carol to view his event eventId.

5. p5 = (Edward, DS, {fashion, hiking}, GN, < videoId, video >, view,permit): Edward authorizes users who are in both groups, fashion and hiking,to view a video videoId that he disseminates. In this policy, Edward is a dissemi-nator of the video.

3.4 Multiparty Policy Evaluation

In our proposed multiparty authorization model, each controller can specify a set ofpolicies, which may contains both positive and negative policies, to regulate access of

1 We limit our consideration to view action. The support of more actions such as post,comment, tag, and update does not significantly complicate our approach proposed in thispaper.


Fig. 4. Conflict Identification for Multiparty Policy Evaluation

the shared data item. Two steps should be performed to evaluate an access request overmultiparty access control policies. The first step checks the access request against poli-cies of each controller and yields a decision for the controller. Bringing in both positiveand negative policies in the policy set of a controller raises potential policy conflicts.In the second step, decisions from all controllers responding to the access request areaggregated to make a final decision for the access request. Since those controllers maygenerate different decisions (permit and deny) for the access request, conflicts mayoccurs again. Figure 4 illustrates potential conflicts identified during the evaluation ofmultiparty access control policies. In order to make an unambiguous final decision foreach access request, it is crucial to adopt a systematic conflict resolution mechanism toresolve those identified conflicts during multiparty policy evaluation.

Policy Conflict Resolution in One Party. In the first step of multiparty policy evalua-tion, policies belonging to each controller are evaluated in sequence, and the accessorelement in a policy decides whether the policy is applicable to a request. If the user whosends the request belongs to the user set derived from the accessor of a policy, the pol-icy is applicable and the evaluation process returns a response with the decision (eitherpermit or deny) indicated by the effect element in the policy. Otherwise, the responseyields NotApplicable. In the context of OSNs, controllers generally utilize a posi-tive policy to define a set of trusted users to whom the shared data item is visible, anda negative policy to exclude some specific untrusted users from whom the shared dataitem should be hidden. Some general conflict resolution strategies for access controlhave been introduced [12,15,16]. For example, deny-overrides (this strategy indicatesthat “deny” policy take precedence over “allow” policy), allow-overrides (this strat-egy states that “allow” policy take precedence over “deny” policy), specificity-overrides(this strategy states a more specific policy overrides more general policies), and recency-overrides (this strategy indicates that policies take precedence over policies specifiedearlier). We can adopt these strategies to resolve policy conflicts in our conflict reso-lution mechanism when evaluating a controller’s policies. Since some strategies, suchas specificity-overrides and recency-overrides are nondeterministic, and deny-overridesstrategy is too restricted in general for conflict resolution, it is desirable to combinethese strategies together to achieve a more effective conflict resolution. Thus, a strategychain can be constructed to address this issue, which has been discussed in our previouswork [17,18].


Resolving Multiparty Privacy Conflicts. When two users disagree on whom theshared data item should be exposed to, we say a privacy conflict occurs. The essen-tial reason leading to the privacy conflicts is that multiple controllers of the shared dataitem often have different privacy concerns over the data item. For example, assume thatAlice and Bob are two controllers of a photo. Each of them defines an access controlpolicy stating only her/his friends can view this photo. Since it is almost impossiblethat Alice and Bob have the same set of friends, privacy conflicts may always existconsidering multiparty control over the shared data item.

A naive solution for resolving multiparty privacy conflicts is to only allow the com-mon users of accessor sets defined by the multiple controllers to access the data. Un-fortunately, this strategy is too restrictive in many cases and may not produce desirableresults for resolving multiparty privacy conflicts. Let’s consider an example that fourusers, Alice, Bob, Carol and Dave, are the controllers of a photo, and each of themallows her/his friends to see the photo. Suppose that Alice, Bob and Carol are closefriends and have many common friends, but Dave has no common friends with themand also has a pretty weak privacy concern on the photo. In this case, adopting the naivesolution for conflict resolution may turn out that no one can access this photo. Never-theless, it is reasonable to give the view permission to the common friends of Alice,Bob and Carol.

A strong conflict resolution strategy may provide a better privacy protection. In themeanwhile, it reduces the social value of data sharing in OSNs. Therefore, it is impor-tant to consider the tradeoff between privacy and utility when resolving privacy con-flicts. To address this issue, we introduce a flexible mechanism for resolving multipartyprivacy conflicts in OSNs based on a voting scheme. Several simple and intuitive strate-gies can be derived from the voting scheme as well.

Our voting scheme contains two voting mechanisms, decision voting and sensitivityvoting. In the decision voting, an aggregated decision value from multiple controllerswith respect to the results of policy evaluation is computed. In addition, each controllerassigns a sensitivity level to the shared data item to reflect her/his privacy concern.Then, a sensitivity score for the data item can be calculated as well through aggregat-ing each controller’s sensitivity level value. Based on the aggregated decision valueand the sensitivity score, our decision making approach provides two conflict resolu-tion solutions: automatic conflict resolution and strategy-based conflict resolution. Abasic idea of our approach for automatic conflict resolution is that the sensitivity scorecan be utilized as a threshold for decision making. Intuitively, if the sensitivity scoreis higher, the final decision is likely to deny access, taking into account the privacyprotection of high sensitive data. Otherwise, the final decision is very likely to allowaccess. Hence, the utility of OSN services cannot be affected. In the second solution,the sensitivity score of a data item is considered as a guideline for the owner of shareddata item in selecting an appropriate strategy for conflict resolution. Several specificstrategies can be used for resolving multiparty privacy conflicts in OSNs. For example,owner-overrides (the owner’s decision has the highest priority), full-consensus-permit(if any controller denies the access, the final decision is deny), majority-permit (thisstrategy permits a request if over 1/2 controllers permit it), strong-majority-permit (thisstrategy permits a request if over 2/3 controllers permit it), and super-majority-permit(this strategy permits a request if over 3/4 controllers permit it).


Owner

Control

Privacy Policy

Decision Aggregation

Sensitivity Setting

Strategy Selection

Contributor

Control

Privacy Policy

Sensitivity Setting

Stakeholder

Control

Privacy Policy

Sensitivity Setting

Strategy

Repository

Sensitivity Aggregation

Decision Making

Requests

Final Decisions

Recommendation

Privacy PolicyDisseminator

Control

Decision

Fig. 5. System Architecture of Decision Making in MController

Conflict Resolution for Disseminated Data. A user can share others’ contents withher/his friends in OSNs. In this case, the user is a disseminator of the content, and thecontent will be posted in the disseminator’s space and visible to her/his friends or thepublic. Since a disseminator may adopt a weaker control over the disseminated contentbut the content may be much sensitive from the perspective of original controllers ofthe content, the privacy concerns from the original controllers of the content shouldbe always complied with, preventing inadvertent disclosure of sensitive contents. Inother words, the original access control policies should be always enforced to restrictaccess to the disseminated content. Thus, the final decision for an access request tothe disseminated content is a composition of the decisions aggregated from originalcontrollers and the decision from the current disseminator. In order to eliminate the riskof possible leakage of sensitive information from the procedure of data dissemination,we leverage the restrictive conflict resolution strategy, Deny-overrides, to resolveconflicts between original controllers’ decision and the disseminator’s decision. In sucha context, if either of those decisions is to deny the access request, the final decision isdeny. Otherwise, if both of them are permit, the final decision is permit.

4 Prototype Implementation and Evaluation

To demonstrate the feasibility of our authorization model and mechanism, we imple-mented a Facebook-based application called MController for supporting collaborativemanagement of shared data. Our prototype application enables multiple associated usersto specify their authorization policies and privacy preferences to co-control a shareddata item. We currently restrict our prototype to deal with photo sharing in OSNs. Ob-versely, our approach can be generalized to handle other kinds of data, such as videosand comments, in OSNs as long as the stakeholders of shared data can be identifiedwith effective methods like tagging or searching.


Fig. 6. MController for Owner Control on Facebook

MController is deployed as a third-party application of Facebook, which is hostedin an Apache Tomcat application server supporting PHP and MySQL database. MCon-troller application is based on the iFrame external application approach, adopting theFacebook REST-based APIs and supporting Facebook Markup Language (FBML),where Facebook server acts as an intermediary between users and the application server.Facebook server accepts inputs from users, then forwards them to the application server.The application server is responsible for the input processing and collaborative manage-ment of shared data. Information related to user data such as user identifiers, friend lists,user groups, and user contents are stored in the MySQL database.

Once a user installs MController in her/his Facebook space, MController can accessuser’s basic information and contents. In particular, MController can retrieve and listall photos, which are owned or uploaded by the user, or where the user was tagged.Then, the user can select any photo to define the privacy preference. If the user is notthe owner of selected photo, s/he can only edit the privacy setting and sensitivity settingof the photo. Otherwise, if the user is an owner of the photo, s/he can further configurethe conflict resolution mechanism for the shared photo.

A core component of MController is the decision making module, which processesaccess requests and returns responses (either permit or deny) for the requests. Fig-ure 5 depicts a system architecture of the decision making module in MController. Toevaluate an access request, the policies of each controller of the targeted content are en-forced first to generate a decision for the controller. Then, the decisions of all controllersare aggregated to yield a final decision as the response of the request. During the pro-cedure of decision making, policy conflicts are resolved when evaluating controllers’


Fig. 7. Performance of Policy Evaluation Mechanism

policies by adopting a strategy chain pre-defined by the controllers. In addition, multi-party privacy conflicts are resolved based on the configured conflict resolution mecha-nism when aggregating the decisions of controllers. If the owner of the content choosesautomatic conflict resolution, the aggregated sensitivity value is utilized as a thresholdfor making a decision. Otherwise, multiparty privacy conflicts are resolved by applyingthe strategy selected by the owner, and the aggregated sensitivity score is considered asa recommendation for the strategy selection. Regarding access requests to the dissemi-nated contents, the final decision is made by combining the disseminator’s decision andoriginal controllers’ decision through a deny-overrides combination strategy.

A snapshot of MController for owner control is shown in Figure 6, where an ownerof a photo can assign weight values to different types of controllers of the shared photo,and select either automatic or manual mechanism for conflict resolution. If the ownerchooses manual conflict resolution, s/he can further select an appropriate conflict res-olution strategy referring to the recommendation derived from the sensitivity score ofthe photo. Note that MController currently requires all controllers of a shared photoshould define their privacy preferences before applying our authorization mechanismto evaluate the requests. Otherwise, the photo is only visible to the controllers. Sincea user may be involved in the control of hundreds of photos, manual input of the pri-vacy preferences is a time-consuming and tedious task. As part of our future work, wewould study inference-based techniques [11] for automatically configuring controllers’privacy preferences.

To evaluate the performance of the policy evaluation mechanism in MController,we changed the number of the controllers of a shared photo from 1 to 20. Also, weconsidered two cases for our evaluation. In the first case, each controller has only onepositive policy. The second case examines two policies (one positive policy and onenegative policy) of each controller. Figure 7 shows the policy evaluation cost whilechanging the number of the controllers. For both cases, the experimental results showthat the policy evaluation cost increased slightly with the increase of the number of the


controllers. Also, we can observe that MController performs fast enough to handle evena large number of controllers for collaboratively managing the shared data.

5 Conclusion and Future Work

In this paper, we have proposed a novel authorization framework that facilitates collabo-rative management of the shared data in OSNs. We have given an analysis of multipartyauthorization requirements in OSNs, and formulated a multiparty access control model.Our access control model is accompanied with a multiparty policy specification schemeand corresponding policy evaluation mechanism. Moreover, we have described a proof-of-concept implementation of our approach called MController, which is a Facebookapplication, along with performance analysis.

As our future work, we will incorporate a logic-based reasoning feature into our ap-proach to provide a variety of analysis services for collaborative management of theshared data. Also, we are planning to conduct extensive user studies to evaluate the us-ability of our proof-of-concept implementation, MController. In addition, as effectiveautomated algorithms (e.g., facial recognition [9,25]) are being developed to recog-nize people accurately in contents such as photos and then generate tags automatically,access and privacy controls will become even more problematic in the future. Conse-quently, we would extend our work to explore more sophisticated and effective solutionsto address emerging security and privacy challenges for sharing various data in OSNs.

References

1. Facebook Privacy Policy, http://www.facebook.com/policy.php/2. Facebook Statistics,

http://www.facebook.com/press/info.php?statistics3. Myspace Privacy Policy,

http://www.myspace.com/index.cfm?fuseaction=misc.privacy/4. Besmer, A., Lipford, H.R.: Moving beyond untagging: Photo privacy in a tagged world. In:

Proceedings of the 28th International Conference on Human Factors in Computing Systems,pp. 1563–1572. ACM, New York (2010)

5. Brands, S.A.: Rethinking public key infrastructures and digital certificates: building in pri-vacy. The MIT Press, Cambridge (2000)

6. Carminati, B., Ferrari, E., Perego, A.: Rule-based access control for social networks. In:Meersman, R., Tari, Z., Herrero, P. (eds.) OTM 2006 Workshops. LNCS, vol. 4278, pp. 1734–1744. Springer, Heidelberg (2006)

7. Carminati, B., Ferrari, E., Perego, A.: Enforcing access control in web-based social networks.ACM Transactions on Information and System Security (TISSEC) 13(1), 1–38 (2009)

8. Carrie, E.: Access Control Requirements for Web 2.0 Security and Privacy. In: Proc. of Work-shop on Web 2.0 Security & Privacy (W2SP), Citeseer (2007)

9. Choi, J., De Neve, W., Plataniotis, K., Ro, Y., Lee, S., Sohn, H., Yoo, H., Neve, W., Kim,C., Ro, Y., et al.: Collaborative Face Recognition for Improved Face Annotation in PersonalPhoto Collections Shared on Online Social Networks. IEEE Transactions on Multimedia,1–14 (2010)

10. Elahi, N., Chowdhury, M., Noll, J.: Semantic Access Control in Web Based Communities.In: Proceedings of the Third International Multi-Conference on Computing in the GlobalInformation Technology, pp. 131–136. IEEE, Los Alamitos (2008)

http://www.facebook.com/policy.php/

http://www.facebook.com/press/info.php?statistics

http://www.myspace.com/index.cfm?fuseaction=misc.privacy/


11. Fang, L., LeFevre, K.: Privacy wizards for social networking sites. In: Proceedings of the19th International Conference on World Wide Web, pp. 351–360. ACM, New York (2010)

12. Fisler, K., Krishnamurthi, S., Meyerovich, L.A., Tschantz, M.C.: Verification and change-impact analysis of access-control policies. In: ICSE 2005: Proceedings of the 27th Interna-tional Conference on Software Engineering, pp. 196–205. ACM, New York (2005)

13. Fong, P.: Relationship-Based Access Control: Protection Model and Policy Language. In:Proceedings of the First ACM Conference on Data and Application Security and Privacy.ACM, New York (2011)

14. Fong, P., Anwar, M., Zhao, Z.: A privacy preservation model for facebook-style social net-work systems. In: Backes, M., Ning, P. (eds.) ESORICS 2009. LNCS, vol. 5789, pp. 303–320. Springer, Heidelberg (2009)

15. Fundulaki, I., Marx, M.: Specifying access control policies for XML documents with XPath.In: Proceedings of the Ninth ACM Symposium on Access Control Models and Technologies,pp. 61–69. ACM, New York (2004)

16. Jajodia, S., Samarati, P., Subrahmanian, V.S.: A logical language for expressing authoriza-tions. In: IEEE Symposium on Security and Privacy, Oakland, CA, pp. 31–42 (May 1997)

17. Jin, J., Ahn, G., Hu, H., Covington, M., Zhang, X.: Patient-centric authorization frameworkfor sharing electronic health records. In: Proceedings of the 14th ACM Symposium on Ac-cess Control Models and Technologies, pp. 125–134. ACM, New York (2009)

18. Jin, J., Ahn, G.J., Hu, H., Covington, M.J., Zhang, X.: Patient-centric authorization frame-work for electronic healthcare services. Computers & Security 30(2-3), 116–127 (2011)

19. Kruk, S., Grzonkowski, S., Gzella, A., Woroniecki, T., Choi, H.: D-FOAF: Distributed iden-tity management with access rights delegation. In: Mizoguchi, R., Shi, Z.-Z., Giunchiglia, F.(eds.) ASWC 2006. LNCS, vol. 4185, pp. 140–154. Springer, Heidelberg (2006)

20. Li, N., Wang, Q., Qardaji, W., Bertino, E., Rao, P., Lobo, J., Lin, D.: Access control policycombining: theory meets practice. In: Proceedings of the 14th ACM Symposium on AccessControl Models and Technologies, pp. 135–144. ACM, New York (2009)

21. Masoumzadeh, A., Joshi, J.: Osnac: An ontology-based access control model for social net-working systems. In: IEEE International Conference on Privacy, Security, Risk and Trust,pp. 751–759 (2010)

22. Shehab, M., Cheek, G., Touati, H., Squicciarini, A., Cheng, P.: User Centric Policy Man-agement in Online Social Networks. In: 2010 IEEE International Symposium on Policies forDistributed Systems and Networks, pp. 9–13. IEEE, Los Alamitos (2010)

23. Squicciarini, A., Paci, F., Sundareswaran, S.: PriMa: an effective privacy protection mech-anism for social networks. In: Proceedings of the 5th ACM Symposium on Information,Computer and Communications Security, pp. 320–323. ACM, New York (2010)

24. Squicciarini, A., Shehab, M., Paci, F.: Collective privacy management in social networks. In:Proceedings of the 18th International Conference on World Wide Web, pp. 521–530. ACM,New York (2009)

25. Stone, Z., Zickler, T., Darrell, T.: Autotagging Facebook: Social network context improvesphoto annotation. In: IEEE Computer Society Conference on Computer Vision and PatternRecognition Workshops, CVPRW 2008, pp. 1–8. IEEE, Los Alamitos (2008)

26. Wishart, R., Corapi, D., Marinovic, S., Sloman, M.: Collaborative Privacy Policy Authoringin a Social Networking Context. In: 2010 IEEE International Symposium on Policies forDistributed Systems and Networks, pp. 1–8. IEEE, Los Alamitos (2010)

27. Wondracek, G., Holz, T., Kirda, E., Kruegel, C.: A practical attack to de-anonymize socialnetwork users. In: 2010 IEEE Symposium on Security and Privacy, pp. 223–238. IEEE, LosAlamitos (2010)

28. Zheleva, E., Getoor, L.: To join or not to join: the illusion of privacy in social networks withmixed public and private user profiles. In: Proceedings of the 18th International Conferenceon World Wide Web, pp. 531–540. ACM, New York (2009)

multiparty authorization framework for data sharing in ......access control requirements with...

Documents