Enabling Collaborative Data Sharing in Google+

Transcription

1 Enabling Collaborative Data Sharing in Google+ Hongxin Hu Delaware State Univerity, Dover, Delaware, Gail-Joon Ahn and Jan Jorgenen Arizona State Univerity, Tempe, Arizona, Abtract Mot of exiting online ocial network, uch a Facebook and Twitter, are deigned to bia toward information dicloure to a large audience. Google recently launched a new ocial network platform, Google+. By introducing the notion of circle, Google+ enable uer to electively hare data with pecific group within their peronal network, rather than haring with all of their ocial connection at once. Although Google+ can help mitigate the gap between the individual expectation and their actual privacy etting, it till only allow a ingle uer to retrict acce to her/hi data but cannot provide any mechanim to enforce privacy concern over data aociated with multiple uer. In thi paper, we propoe an approach to facilitate collaborative privacy management of hared data in Google+. We extend and formulate a multiparty acce control model, named MPAC+, to capture the eence of collaborative authorization requirement in Google+, along with a multiparty policy pecification cheme and a policy enforcement mechanim. We alo dicu a proof-of-concept prototype of our approach and decribe ytem evaluation and uability tudy of our prototype. I. INTRODUCTION A typical OSN allow uer to create connection to friend, thereby haring with them a wide variety of peronal information. Thee connection, however, rarely ditinguih between different type of relationhip. Even within a network of friend, uer may want to regulate the haring of information with different people baed on their different relationhip. Unfortunately, mot of exiting OSN could not provide effective mechanim to ufficiently addre how to organize people and how to utilize relationhip for privacy etting. For example, Facebook ha introduced an optional feature called Friend Lit which allow u to group friend and pecify whether a piece of data hould be viible or inviible to a particular friend lit. However, tudie have conitently hown that uer truggle to adopt thi feature for managing their friend and cutomizing their privacy etting [10]. To addre uch an iue, Google recently launched a new ocial network ervice, namely Google+, by utilizing circle a it fundamental deign feature for orting connection and enabling uer to electively hare the information with their friend, family, colleague, etc, intead of haring with all of their connection [9]. Depite the fact that Google+ can help mitigate the gap between the uer expectation and their actual privacy etting, it till only allow a ingle uer to regulate acce to information contained in their own pace but cannot provide control over data reiding outide their pace. For intance, if a uer pot a comment in a friend pace, /he cannot pecify who can view the comment. Furthermore, when a uer upload a photo and tag friend who appear in the photo, the tagged friend cannot govern who can ee thi photo, even though the tagged friend may have different privacy concern about the photo. In another example, the firt privacy flaw in Google+ wa identified in [1] and thi flaw implie that any content hared with a particular circle could be rehared with anyone by omeone from thoe circle. Thi problem wa fixed by Google+ by diabling limited content to be harable publicly. However, thi olution till cannot prevent uer who can acce the hared content from dieminating the content to anyone in their circle, which may violate the original content owner privacy control. Hence, it i eential to develop an effective and flexible acce control mechanim for Google+, accommodating the pecial authorization requirement coming from multiple aociated uer for managing the hared data collaboratively. In thi paper, we attempt to explore a ytematic method to enable collaborative management of hared data in Google+. A multiparty acce control model i formulated for Google+ to capture the core feature of multiparty authorization requirement which have not been accommodated in mot of exiting acce control ytem for OSN o far (e.g., [2], [3]). In particular, we introduce the notion of circle and trut into our model, which ignificantly extend our multiparty authorization framework for Facebook-tyle ocial network [5], [7]. In addition, our model contain a multiparty policy pecification cheme, a well a a policy evaluation mechanim, which deal with policy conflict by keeping the balance between the need for privacy protection and the uer deire for information haring. Moreover, we provide a prototype implementation of our authorization mechanim, and our experimental reult demontrate the feaibility and uability of our approach. The ret of the paper i organized a follow. In Section II, we articulate our propoed MPAC+ model, including MPAC+ policy pecification and MPAC+ policy evaluation. The detail about prototype implementation and experimental reult are decribed in Section III. We conclude thi paper and dicu our future direction in Section IV. II. MULTIPARTY ACCESS CONTROL FOR GOOGLE+ A. MPAC+ Model An OSN ytem, uch a Google+, typically contain a et of uer, a et of uer profile, a et of uer content, and a et of uer relationhip (circle in Google+). Exiting OSN

2 including Google+ do not provide effective mechanim to upport collaborative privacy control over hared data. Several acce control cheme (e.g., [2], [3]) have been recently introduced to upport fine-grained authorization pecification for OSN. Unfortunately, thee cheme alo only allow a ingle controller, the reource owner, to pecify acce control policie. Indeed, in addition to the owner (the uer owning the content in hi/her pace) of content, other controller, including the contributor (the uer publihing the content in omeone ele pace), takeholder (the uer tagged and aociated with the content) and dieminator (the uer haring the content from omeone ele pace to hi/her pace) of content, need to govern the acce of the hared data a well due to poibly different privacy concern. In real life, uer naturally group their connection (the people they know) into ocial circle, and alo aign them different prioritie called trut. Social circle and trut among connection can help a uer determine how to interact with other uer. The circle in Google+ can directly reflect the feature of ocial circle in real life of a uer. However, the concept of trut cannot be explicitly repreented in exiting OSN including Google+. Obviouly, even uer in a ame circle may repreent different degree of trut, and uer trutworthine can be alo leveraged to determine who are authorized to acce a reource. For example, a uer may want to dicloe buine document to only co-worker who are with high trut level. Thu, in our multiparty acce control model called MPAC+, we aume uer can explicitly pecify how much they trut other by aigning each of them a trut level when they group their connection into circle in OSN. We now formally define our MPAC+ model a follow: U = {u 1,..., u n } i a et of uer of the OSN. Each uer ha a unique identifier; C = {c 1,..., c m } i a et of circle created by uer in the OSN. Each circle i identified by a unique identifier a well; O = {o 1,..., o p } i a et of content in the OSN. Each content alo ha a unique identifier; P = {p 1,..., p q } i a et of uer profile item in the OSN. Each profile item i a <attribute: profile-value> pair, p i =< attr i : pvalue i >, where attr i i an attribute identifier and pvalue i i the attribute value; UC = {uc 1,..., uc tr } i a collection of uer circle et, where uc i = {uc i1,..., uc i } i a et of circle created by a uer i U, where uc ij C; UP = {up 1,..., up v } i a collection of uer profile et, where up i = {up i1,..., up iw } i the profile of a uer i U, where up ij P ; CT = {OW, CB, SH, DS} i a et of controller type, indicating OwnerOf, ContributorOf, StakeholderOf, and DieminatorOf, repectively; CO = {CO ct1,..., CO ctx } i a collection of binary uer-to-content relation, where CO cti U O pecifie a et of < uer, content > pair with a controller type ct i CT ; T L = {tl 1,..., tl y } i a et of upported trut level, which are aumed to be in the cloed interval [0,1] in our model; CUT C U T L i a et of 3-tuple < circle, uer, trut level > repreenting uer-to-circle memberhip relation (MemberOf ) with aigned trut level; controller : O CT 2 U, a function mapping each content o O to a et of uer who are the controller of the content with the controller type ct CT : controller(o : O, ct : CT ) = {u U (u, o) CO ct }; uer own circle : U 2 C, a function mapping each uer u U to a et of circle created by thi uer: uer own circle(u : U) = {c C ( uc u UC)[c uc u ]}; circle contain uer : C 2 U, a function mapping each circle c C to a et of uer who are the member of thi circle: circle contain uer(c : C) = {u U (c, u, ) 1 CUT }; uer extended circle : U 2 C, a function mapping each uer u U to a et of circle of the uer circle: uer extended circle(u : U) = {c C ( u circle contain uer(c ) c uer own circle(u))[c uer own circle(u )]}; trut level : C, U T L, a function returning the trut level of a uer-to-circle memberhip relation: trut level(c : C, u : U) = {tl T L (c, u, tl) CUT }; B. MPAC+ Policy Specification Our policy pecification cheme i contructed baed on the propoed MPAC+ model. In our model, each controller of a hared reource can pecify one or more rule a a policy that can govern who can acce the reource. Acceor Specification: Acceor are a et of uer who are granted to acce the hared data. In Google+, acceor can be pecified with a et of circle. In addition, a we dicued previouly, trut level can be ued a contraint on determining authorized uer in our model. We formally define the acceor pecification a follow: Definition 1: (Acceor Specification). Let ac C {All Circle} {Extended Circle} { } be a pecific circle c C, all circle or extended circle of the controller who define the policy, or everyone (*) in the OSN. Let tl min T L and tl max T L be, repectively, the minimum trut level and the maximum trut level that the uer in ac mut have. The acceor pecification i defined a a et, {a 1,..., a n }, where each element i a tuple < ac, tl min > for poitive rule (with permit effect) or < ac, tl max > for negative rule (with deny effect). Data Specification: In Google+, uer can hare their content, profile, even circle with other. To facilitate effective policy conflict reolution for multiparty acce control, we introduce enitivity level for data pecification, which are aigned 1 * i to indicate any value of the trut level within the tuple.

3 by the controller to the hared data. A uer judgment of the enitivity level of the data i not binary (private/public), but multi-dimenional with varying degree of enitivity. Formally, the data pecification i defined a follow: Definition 2: (Data Specification). Let dt O C P be a data item. Let l be a enitivity level, which i a rational number in the range [0,1], aigned to dt. The data pecification i defined a a tuple < dt, l >. Acce Control Policy: To ummarize the above-mentioned policy element, we give the definition of MPAC+ acce control rule a follow: Definition 3: (MPAC+ Rule). A MPAC+ rule i a 5-tuple R =< controller, ctype, acceor, data, effect >, where controller U i a uer who can regulate the acce of data; ctype CT i the type of the controller; acceor i a et of uer to whom the authorization i granted, repreenting with an acce pecification defined in Definition 1. data i repreented with a data pecification defined in Definition 2; and effect {permit, deny} i the authorization effect of the rule. Note that the emantic of acceor pecification, {a 1,..., a n }, in a rule can be explained a the conjunction of element in acceor pecification, a 1... a n, which mean that only common uer in the acceor et defined by the element in acceor pecification are treated a authorized uer. Alo, one controller may define more than one rule in her/hi policy for a hared reource. In thi cae, uer who atify any rule in the policy are conidered a authorized uer for the reource. Suppoe a controller can leverage five value: 0.00 (none), 0.25 (low), 0.50 (medium), 0.75 (high), and 1.00 (highet) to repreent both enitivity level and trut level, the following i an example rule: Example 1: Alice authorize uer who are in both her Friend circle and her Colleague circle with at leat a medium trut level to acce a photo named funny.jpg he i tagged in, where Alice conider the photo with a high enitivity level and he i a takeholder of the photo: r 1 = (Alice, SH, {< F riend, 0.50 >, < Colleague, 0.50 >}, < funny.jpg, 0.75 >, permit). C. MPAC+ Policy Evaluation In our MPAC+ model, we adopt three tep to evaluate an acce requet over multiparty acce control policie a hown in Figure 1. The firt tep check the acce requet againt the policy pecified by each controller and yield a deciion for the controller. In our MPAC+ model, controller can leverage a poitive rule to define a et of circle to whom the hared reource i viible, and a negative policy to exclude ome pecific circle from whom the hared reource hould be hidden. A trategy called deny-override, which indicate that deny rule take precedence over permit rule, i adopted to achieve uch an exceptional feature in our policy Fig. 1. P ermit/ D eny P ermit/ D eny MPAC+ Policy Evaluation Proce. evaluation mechanim. In the econd tep, deciion from all controller in repone to the acce requet are aggregated to make a collaborative deciion for the acce requet. Since thee controller may generate different deciion (permit and deny) for the acce requet, conflict may occur. The ubequent ection will addre our approach for reolving uch conflict in detail. In addition, if the target of the acce requet i a reource dieminated by a dieminator, the third tep i needed for policy evaluation. In thi cae, the dieminator may pecify a conflicting privacy control over the dieminated content with repect to the original controller of the content. In order to eliminate the potential dicloure rik of enitive information from the procedure of data diemination, we again leverage the retrictive conflict reolution trategy, Deny-override, to reolve conflict between original controller deciion and the dieminator deciion. The proce of conflict reolution i to make a deciion to allow or deny the requeter acce to the hared data. In general, allowing a requeter to acce the content may caue privacy rik, but denying a requeter to acce the content may reult in haring lo. We adopt a privacy conflict reolution mechanim to balance privacy protection and the uer deire for information haring through quantitative analyi of privacy rik and haring lo [6]. Meauring Privacy Rik: The privacy rik of an acce requet i an indicator of potential threat to the privacy of controller in term of the hared content: the higher the privacy rik of an acce requet, the higher the threat to controller privacy. Our baic premie for the meaurement of privacy rik for an acce requet are the following: (a) the lower the trut level of the requetor who require the acce requet, the higher the privacy rik; (b) the lower the number of controller who allow the requetor to acce the content, the higher the privacy rik; (c) the tronger the general privacy concern of controller, the higher the privacy rik; and (d) the more enitive the hared data item, the higher the privacy rik. In order to meaure the privacy rik of an acceor i, denoted a PR(i), we can ue following equation to aggregate the privacy rik of i due to different denied controller. P R(i) = (1 tl i ) pc j l j (1) j controller d (i) where, tl i denote the average trut level of the acceor i;

4 function controller d (i) return all denied controller of an acce requet i; pc j denote the general privacy concern of a denied controller j; and l j denote the enitivity level of the hared content explicitly choen by a denied controller j. Meauring Sharing Lo: When the deciion of privacy conflict reolution for an acce requet i deny, it may caue loe in potential content haring, ince there are controller expecting to allow the requetor to acce the data item. Similar to the meaurement of the privacy rik, four factor are adopted to meaure the haring lo for a requetor. Compared with the factor ued for quantifying the privacy rik, the difference i that we only conider allowed controller for evaluating the haring lo of an acceor. The haring lo SL(i) of an acceor i i the aggregation of haring lo with repect to all allowed controller a follow: SL(i) = tl i k controller a (i) (1 pc k ) (1 l k ) (2) where, function controller a (i) return all allowed controller of a requetor i. Conflict Reolution: The following equation can be utilized to make the deciion (permitting or denying an acce requet) for privacy conflict reolution. { Permit if αsl(i) βp R(i) Deciion = (3) Deny if αsl(i) < βp R(i) where, α and β are preference weight for the privacy rik and the haring lo, 0 α, β 1 and α + β = 1. III. IMPLEMENTATION AND EVALUATION A. Prototype Sytem Implementation We implemented a proof-of-concept ocial network application to demontrate collaborative management of photo, called Sigma ( tool). The intent of the application i to allow uer to collaboratively hare photo in Google+ baed on our approach. However, contrained by current lack of development API for Google+, our implementation i a Facebook application uing Facebook uer data to imulate an environment like Google+. Figure 2 how the architecture of Sigma. The application i hoted on an external web erver, but ue Facebook graph API and Facebook Query Language to retrieve uer data. A minimal amount of data i kept on the erver itelf, but our application allow uer to ave their etting and check acce to their photo baed on the reult of the multiparty policy evaluation. Sigma conit of two major part, a circle management module and a photo management module. The circle management module, hown in Figure 3 (c), allow uer to ort their friend into circle baed on their exiting Facebook friend lit. It alo allow them to et trut level by friend or by circle. For the performance purpoe in uing the application, etting the trut level for a circle applie it to all individual L o g in P e rm i io n A p ro v e Fig. 2. F rie n d C irc le Sytem Architecture of Sigma. uer in that circle in our current implementation. In a reallife implementation, the function of circle trut level would depend on the type of circle. If it i a trut-baed circle, trut level may be ued a an indication of which uer to place in that circle. If it i a group-baed circle, it might diplay an average trut level of all the uer. In the photo management module of Sigma, Figure 3 (a) depict the policy etting. Three option are preented and then joined by union for the ultimate policy. The controller indicate a et of circle and/or uer who may acce the photo, a et of circle of which the interection of uer may acce the photo, and a et of circle and/or uer who may not acce the photo. The controller may alo optionally indicate a minimum trut level for a permit policy or a maximum trut level for a deny policy to additionally retrict photo haring. If the controller i the owner of elected photo, /he can adjut the weight to balance privacy protection and data haring of the photo. In addition, ince maliciou uer may tag themelve to a photo and pecify privacy policie to influence the haring of the photo, the photo owner can verify the tagged uer and ha the ability to diable fake takeholder to control the photo in the privacy etting. To allow the uer of the prototype application to check the impact of collaborative control againt their privacy etting, uer are able to check friend acce to the photo in Sigma a hown in Figure 3 (b). B. Prototype Sytem Evaluation 1) Uer Study: We conducted a uer tudy to tet the uability of Sigma. 2 We had 42 uer ue the application and anwer a urvey to indicate their preference in ocial network. We recruited through Univerity mailing lit, Google+ and Facebook. Of our repondent, 71.4% were 18-24, 21.4% were 25-34, and 7.1% were year old. Some quetion were ranking quetion, where uer were aked to rank certain thing by preference. Repone were then aigned a weight of (n-r) where n i the total number of data item to rank and r i the rank aigned. Therefore, rating omething 2 S e tin g T r u t

5 intereted in a photo (the number of controller i greater than one). We can etimate from the data that, in owned photo, there i on average at leat two tagged uer for every five photo. More importantly, about 15% of owned photo have at leat two tagged uer, and about 5% have three or more. Thi mean in an only-owner-control approach for privacy management, a izable number of uer i being ignored in determining privacy etting for thoe photo. We alo aked uer to rank their preference for variou part of our ytem a they tried it out. For a uer management ytem, uer ranked their preference a hown in Table I. Uer ranked the ability to indicate trut almot a important a implicity, meaning they reacted very poitively to thi feature of our ytem. TABLE I IMPORTANCE OF FEATURES IN USER MANAGEMENT. Fig. 3. Sigma Interface. 3 out of 5 give a core of 2. Repone from all uer are then totaled for comparion. Prior to uing Sigma: Part of the purpoe of the uer tudy wa to undertand the demand for a collaborative data management ytem that balance privacy protection with data haring. When aked whether privacy or haring wa more important, half of repondent rated them a equally important (with 32.1% finding chooing privacy and 17.9% chooing haring), o we know both are neceary when determining an approach to data management in OSN. When aked to rank preference when tagged in a photo, uer indicated that protecting their privacy wa the mot important to them (a core of 79), with haring with friend and protecting other uer privacy were ranked cloer to each other (53 and 41, repectively). Aked to rank preference when a uer own a photo, they indicated protecting their own privacy and haring cloely (92 and 81), with protecting tagged uer privacy (65) till omewhat important and allowing tagged uer to hare with their friend (42) lat. When a uer i tagged, we can ee that protecting their own privacy i important. Since in a normal ocial network a tagged uer ha little protection compared to the owner, we can interpret thi a a deire for more control over tagged photo, ince the current approach allow the owner to override control. When a uer own a photo, they conider privacy protection and haring lo about equal, but they conider protecting tagged uer privacy important a well (a core of 65 indicate that ome uer ranked it a at leat the 2nd mot important). After Uing Sigma: We collected ome Facebook uage tatitic to determine the need for collaborative photo management. We define need a the preence of more than one party Rate the feature of thi or a imilar uer Weighted Score management ytem in order of importance Simplicity 146 Ability to indicate trut 115 Automatically orting friend 93 Viual interface 90 Recommending trut level for friend 76 Recommending circle placement 68 We then again aked uer to rank preference in haring, but for three cenario: when the uer i a takeholder, when the uer i an owner, and in general when collaboratively controlling a photo (Table II). In all three ituation, the uer ranked protecting one own privacy a the mot important. Thi may eem obviou, but it i important to note that thi ugget they find protecting one privacy a a takeholder equally important to protecting one privacy a an owner (upporting the need for collaborative control). Uer indicated that when they were tagged, having an equal ay to the owner wa leat important, o if the owner ha more control in the ytem (uch a etting weight in our ytem) it i permiible a long a the takeholder have a ay. In general and a an owner, uer indicated that owner control wa econd-mot important, which further upport the need for ome additional owner control like our in a collaborative approach. TABLE II IMPORTANCE OF FEATURES IN COLLABORATIVE SHARING. Rate the following in order of importance when Weighted Score collaboratively haring a photo Tagged Protecting my privacy 99 Ability to prevent uer from viewing photo 83 Ability to allow uer to view photo 76 Sharing 59 Having an equal ay to the owner 58 Owned Protecting my privacy 95 Having complete control 89 Preventing fake tagged uer from controlling 72 Sharing 61 In General Protecting privacy 80 Giving the owner control 72 Giving tagged uer control 52 Allowing uer to hare 46 2) Effectivene Evaluation: To evaluate the effectivene of our approach, we compare the outcome, on a ingleacceor bai, of a policy et in Google+ to a policy et in

6 Sigma. The metric we ue for evaluation i the total Privacy Rik (PR) plu the total Sharing Lo (SL) from all controller baed on the outcome of the acce attempt. We evaluate the outcome in a few cae. The outcome i a meaurement of average expected privacy rik and haring lo (which ue average trut level and average enitivity level). It hould be noted, however, that higher trut or lower enitivity would imply lower the magnitude of the final meaurement and lower trut or higher enitivity would imply increae the magnitude of the final meaurement, but the comparion till hold. Additionally, ince we are evaluating on a ingle-acceor bai, number of friend or circle allowed or denied do not affect the reult. One cae i trivial: in both Google+ and Sigma, if all uer agree on the ame privacy etting, there are no conflict to reolve. The reult i 0 PR and 0 SL in either Google+ or Sigma. Thi i conidered the bet cae. The ret of the cae and evaluation reult are hown in Figure 4. Fig. 4. Privacy Rik and Sharing Lo in Google+ and Sigma in Six Cae. Cae 1 i in Google+ (or any owner-override ituation) where all of the takeholder in a photo diagree with the owner. Thi i a wort-cae for Google+. Thi can be compared with Cae 6, which i the ame acce deciion in Sigma. In Google+ the privacy rik or haring lo grow with each non-owner controller, a hi or her deciion i being violated. In Sigma, thi i only lightly different from the bet-cae cenario. In Cae 2-5, half of the takeholder agree with the owner. In Cae 2, the owner allow in Google+ and in Cae 3 the owner denie in Sigma. In Cae 4 the owner denie in Google+ and in Cae 5 the owner allow in Sigma. Thi can be conidered an average cae. In thee cae, Sigma core increae at the ame rate a Google+. Thi how that Sigma i at leat a good a Google+, until one conider the fact that thi average cae for Google+ i actually the wort cae for Sigma. It i important to note that the rate of PR or SL a number of controller increae i at mot 1/2 in Sigma. Thi i due to the fact that the maximum proportion of controller whoe preference are being violated i 1/2, ince (given the ame enitivity and trut etting) more than 50% controller in agreement determine the deciion. In Google+, thi i not the cae. In fact, PR or SL will increae for every new controller who diagree with the owner ince the deciion i never changed. Thi i why Cae 2 and 4 increae at the ame rate a Sigma maximum rate in Cae 3 and 5 every econd controller diagree with the owner. Thu, Sigma wort cae i at leat a effective at giving uer preference a Google+ and can only be better in other cae. IV. CONCLUSION AND FUTURE WORK In thi paper, we have propoed a novel mechanim for collaboratively controlling the hared data in Google+. A multiparty acce control model ha been formulated. A proofof-concept implementation of our olution called Sigma and the ytem evaluation of our approach have been dicued a well. A part of our future work, we will implement and evaluate our approach in Google+ platform once Google releae the Google+ application development API. In addition, we would tudy inference-baed technique [11] for both marter circle management and automatic configuration of privacy preference in Google+. Moreover, we plan to conduct model and policy analyi [4], [8] for multiparty acce control in OSN. ACKNOWLEDGMENTS Thi work wa partially upported by the grant from National Science Foundation (NSF-IIS and NSF- CNS ). REFERENCES [1] The firt google+ privacy flaw, /google-plu-privacy-flaw/#axzz1cxeoa9LS. [2] B. Carminati, E. Ferrari, and A. Perego. Enforcing acce control in webbaed ocial network. ACM Tranaction on Information and Sytem Security (TISSEC), 13(1):1 38, [3] P. Fong. Relationhip-Baed Acce Control: Protection Model and Policy Language. In Proceeding of the Firt ACM Conference on Data and Application Security and Privacy. ACM, [4] H. Hu and G. Ahn. Enabling verification and conformance teting for acce control model. In Proceeding of the 13th ACM ympoium on Acce control model and technologie, page ACM, [5] H. Hu and G. Ahn. Multiparty authorization framework for data haring in online ocial network. In Proceeding of the 25th annual IFIP WG 11.3 conference on Data and application ecurity and privacy, page Springer-Verlag, [6] H. Hu, G. Ahn, and J. Jorgenen. Detecting and reolving privacy conflict for collaborative data haring in online ocial network. In Proceeding of the 27th Annual Computer Security Application Conference, ACSAC 11, page ACM, [7] H. Hu, G. Ahn, and J. Jorgenen. Multiparty acce control for online ocial network: model and mechanim. IEEE Tranaction on Knowledge and Data Engineering, pp(99), [8] H. Hu, G. Ahn, and K. Kulkarni. Anomaly dicovery and reolution in web acce control policie. In Proceeding of the 16th ACM ympoium on Acce control model and technologie, page ACM, [9] S. Kairam, M. Brzozowki, D. Huffaker, and E. Chi. Talking in circle: elective haring in google+. In Proceeding of the 2012 ACM annual conference on Human Factor in Computing Sytem, page ACM, [10] Y. Liu, K. Gummadi, B. Krihnamurthy, and A. Milove. Analyzing Facebook Privacy Setting: Uer Expectation v. Reality. In Proceeding of the 2011 annual conference on Internet meaurement (IMC 11). ACM, [11] A. Squicciarini, S. Sundarewaran, D. Lin, and J. Wede. A3p: adaptive policy prediction for hared image over popular content haring ite. In Proceeding of the 22nd ACM conference on Hypertext and hypermedia, page ACM, 2011.