Privacy-Aware Access Control in Social Networks: Issues and Solutions

Chapter
Part of the Advanced Information and Knowledge Processing book series (AI&KP)

Abstract

Access control in online social networks (OSNs) is becoming an urgent need due to the amount of data managed by social networks and their sensitivity. Performing access control in a social network has many differences with respect to performing access control in a traditional data management system, in terms of both the policy language to support and the reference architecture for access control enforcement. Moreover, it is fundamental to also consider privacy issues connected to access control and to devise appropriate privacy-preserving access control systems. The aim of this chapter is to first discuss which are the requirements of privacy-aware access control to OSN resources and then to review the literature in view of the identified requirements. Finally, the chapter discusses future research directions in the field.

9.1 Introduction

Online social networks (OSNs) are platforms that allow people to publish details about themselves and to connect to other members of the network through various relationships. The potentialities of these services are enormous, from knowledge sharing to social search, to establish community of practices1 at the enterprise level, just to mention few of OSN applicability domains. Recently, the popularity of OSNs is increasing significantly. For example, Facebook now claims to have more than 300 million active users.2 Also the amount of shared digital contents is enormous. For instance, considering once again Facebook, it now claims to have more than 2 billion photos and 14 million videos uploaded to the site each month, whereas more than 2 billion pieces of content (web links, news stories, blog posts, notes, photos, etc.) are shared each week.

The existence of this huge amount of data, including person-specific information, creates both interesting research challenges and security and privacy threats. For example, social network data could be used for marketing products to the right customers. At the same time, security and privacy concerns can prevent such efforts in practice [4]. Therefore, many researchers have started to work on improving the access control systems today provided by OSNs. The motivation is that current OSNs implement very basic access control models, by simply making users able to decide which information are accessible by other members by marking a given item as public, private, or accessible by their direct contacts.

In order to give more flexibility, some online social networks enforce variants of these settings, but the principle is the same. For instance, besides the basic settings, Bebo (http://bebo.com), Facebook (http://facebook.com), and Multiply (http://multiply.com) support the option “selected friends”; Last.fm (http://last.fm) the option “neighbors” (i.e., the set of users having musical preferences and tastes similar to mine); Facebook, Friendster, and Orkut (http://friendster.com, http://www.orkut.com) the option “friends of friends”; Xing (http://xing.com) the options “contacts of my contacts” (second degree contacts), and “third” and “fourth degree contacts”; LinkedIn (http://www.linkedin.com) and Multiply the option “my network” (i.e., all the WBSN members who are either directly or indirectly connected to, independently from how far they are). It is important to note that all these approaches have the advantage of being easy to implement, but they lack flexibility. In fact, the available protection settings do not allow users to easily specify their protection requirements, in that they are either too restrictive or too loose (e.g., the option “my network” in LinkedIn).3

The research activity in the field of OSN access control has resulted in several proposals that we survey in Section 9.4. Almost all the proposals appeared so far enforce relationship-based access control, according to which access control requirements are expressed in terms of relationship paths existing in the network and their depth. For example, using relationship-based access control a user can give access to one of his/her photo only to his/her friends and the friends of his/her friends or to all my direct and indirect colleagues, no matter how distant they are from me in the network graph. Furthermore, some of the models support a notion of trust/reputation as a further parameter for access control decisions.

The enforcement of relationship-based access control poses interesting issues regarding privacy protection, which are the main focus of this chapter. A first issue is related to the architecture on support of access control. Clearly a centralized solution where the social network management system (SNMS) is in charge of performing access control and managing all users’ resources and security policies is no more acceptable by SN users since this implies to fully trust the SNMS with respect to the management of user private data. It is today well recognized that decentralization is the future of OSN [23] and this should also apply to access control. Furthermore, enforcing relationship-based access control requires to disclose to the resource owner some paths in the network and associated trust level. This means disclosing all the relationships/trust levels of the links forming the path. However, disclosing a relationship/trust level always means an exposure of personal information. Therefore, there is the need of devising privacy-aware access control mechanisms, able to enforce relationship-based access control by, at the same time, ensuring relationship privacy.

In this chapter we start by understanding which are the main requirements of an access control system for OSNs, by focusing on the privacy issues arising in access control. Then, we review the literature in view of the identified requirements. Finally, we conclude the chapter by outlining future research directions.

9.2 Access Control Requirements

In what follows, we use as running example the OSN depicted in Fig. 9.1. The OSN refers to a network of freelance IT consultants that use the network for a variety of purposes, such as knowledge sharing, advertising new opportunities, finding new partners. The OSN may also involve companies that wish to make use of the services provided by the consultants. Clearly, such companies should have a selective access to OSN resources. Nodes can also form smaller networks or groups (for instance, a set of consultants/companies working on a specific project). In the figure, the OSN is represented as a directed labeled graph, where each node corresponds to a network member and edges denote relationships between two different members. In particular, the initial node of an edge denotes the member who established the relationship, whereas the terminal node denotes the member who accepted to establish the relationship. Each edge is labeled by the type of the established relationship and the corresponding trust level, representing how much the user that established the relationship trust the other user with respect to that specific relationship. The portion of the OSN depicted in Fig. 9.1 consists of three companies, i.e., \(C_1, C_2\), and \(C_{3}\), whereas the remaining nodes represent agents.
Fig. 9.1

A portion of an OSN9.1

The main purpose of an OSN is to establish relationships with other users and exploit such relationships for sharing resources of various nature. Therefore, it is already well accepted that any access control model for OSNs should be relationship based. According to a relationship-based access control model, access control policies are specified in terms of relationships existing in the OSN. This means that the releasing of a resource is conditioned to the fact that the resource requestor has a relationship (either direct or indirect) of a specific type with another OSN member(s). Examples of relationship-based access control policies are as follows: Only my friends can access document doc1 or only the colleagues of my colleagues can access report rep. Additional policies referring to the OSN in Fig. 9.1 are as follows: Only my partners can access the project opportunity I post in the OSN or only my customers can have a sneak preview of the report describing a particular not yet released product. Additionally, also the depth of the path is an important parameter for some access control decisions, since users usually are more inclined to share their resources with users not much far away from them. For example, a user may want to limit the disclosure of one of his/her resources to his/her friends and the friends of their friends or to consultant partners whose distance in the OSN is no more than three. Therefore, the policy language should be able to express constraints on the depth of a path. A further important parameter is represented by trust, which is an orthogonal parameter with respect to the depth of a relationship. For instance, two of my direct friends may have completely different trust and therefore I may want to give access to a resource only to the one with the highest trust and not to the other. Referring to the OSN in Fig. 9.1, consultant A(lice) is a direct partner of both E(ric) and F(red), but the trust she has on the two is different.4 Because of this, A may want to share new job opportunities with E but not with F. In this case, the depth of the relationship is not enough to express this requirement (since both E and F are at distance one from A). Therefore, the policy language should support also constraints on the minimum trust level of a relationship.

Moreover, in an OSN relationships between users and resources may be of different types. As usual, a user may be the owner of a resource, but he/she may also be tagged in a photo of another user. Therefore, a relationship-based access control model should exploit not only the standard user-to-user relationships for access control purposes but also the variety of user-to-resource relationships that the OSN supports.

Apart from the access mode that is granted, the other two main components of an access control policy are the subject and object specification. In the case of an OSN, the subject specification identifies the users to which the policy applies, whereas the object specification identifies the resources covered by the policy. Regarding the subject specification, the policy language has to be flexible enough to identify the users to which a policy applies according to their relationships with resources (e.g., users “tagged” to a photo, “leader” of a project) or to other users (direct friends, colleagues of my colleagues). Moreover, the object specification should make one able to identify resources according to their descriptions (e.g., objects of “type” photo, documents “about” an object of “type” photo), as well as to their URIs.

Up to now, we have focused on the requirements of the access control model and related policy language. However, a further important class of requirements is related to how access control is enforced and by what entities of the OSN. Traditionally, access control is enforced by a trusted software module, called reference monitor, and hosted by the data management system. The reference monitor intercepts each access request and, on the basis of the specified access control policies, determines whether the access can be partially or totally authorized or it must be denied. Therefore, the first architectural choice is related to which entity should host the reference monitor. If we cast our discussion in an OSN the traditional solution described above implies to delegate to the SNMS the role of reference monitor. According to this choice, OSN users completely delegate the control of their data to the SNMS, which stores and enforces all the access control policies on behalf of the network users. Even if this kind of solution is largely accepted, we do not believe that it is the most suited for the OSN scenario. The main reason of this concern is that this solution implies to totally delegate to the SNMS the administration and enforcement of access control policies. This means that users should trust the SNMS regarding the correct enforcement of their policies. However, some recent events have made OSN users aware that the SNMS’s behavior is not always honest and transparent. This is, for instance, witnessed by some privacy concerns related to the collection and delivering of personal data by some of the Facebook’s services [4, 13, 16]. All these events lead us to believe that a centralized access control solution where the SNMS hosts the reference monitor is not the most appropriate one in the OSN scenario. We believe that in the near future OSN participants would like to have more and more control over their access control policies and the way they are enforced. The best solution in this respect is a fully decentralized one, where each OSN user is responsible for policy specification and enforcement. However, each access control solution to be effectively applied must consider also another important dimension, that is, the efficiency of access control. Since, access control is relationship-based, answering an access request may require to verify the existence of specific paths within an OSN. This task may be very difficult and time consuming in a fully decentralized solution. Therefore, a further essential requirement of access control enforcement is to devise efficient and scalable implementation strategies.

The access control requirements discussed so far are summarized in Table 9.1.
Table 9.1

OSN main access control requirements

Component

Requirements

Policy language

Relationship-based:

 

(a) User-to-user relationships:

 

Depth

 

Trust level

 

(b) User-to-resource relationships

Access control enforcement

Not centralized

 

Efficient

9.3 Privacy Issues in OSN Access Control

As we have seen in Section 9.2, the first requirement of any access control model for OSNs is its ability to enforce relationship-based access control. However, relationships are in general sensitive resources whose privacy should be properly guaranteed even if they are instrumental to perform access control. Therefore, the main privacy issues that arise during access control enforcement are those arising by the disclosure of personal relationships. Indeed, establishing a relationship in a community implies, in some sense, an exposure of personal information of the users involved in the relationship, which may give rise to some relevant privacy concerns. For instance, referring to our running example in Fig. 9.1, consultant B(ob) may not want to disclose to consultant F the fact that he works for company C1. One fundamental requirement is therefore that each participant has strong guarantees that relationship privacy is not breached during access control. Clearly, the way this is achieved is highly impacted by the way access control is enforced. For instance, if we assume a centralized architecture where the SNMS hosts the reference monitor, privacy is guaranteed under the assumption that we can fully trust the SNMS. More difficult is to protect relationship privacy if a decentralized architecture is used, according to which access control enforcement is under the responsibility of resource owners and/or requestors (see Section 9.4.2 for a more detailed discussion about these issues). Additionally, relationship may have an associated trust value that must be protected during access control. For instance, with reference to Fig. 9.1, company C1 may not want to disclose the fact that it does not trust very much C2 as a partner (i.e., the trust level assigned to the partnerOf relationship is 0.2). Privacy requirements regarding trust disclosure may be different from that of relationships. For instance, a user may consent to disclose that he/she is a friend of a given user, but he/she may not want to disclose how much he/she trusts that particular user. Therefore, a further requirement is that of protecting relationship trust level during access control.

Another issue which is out of the scope of this chapter but that it is important to mention is related to privacy issues arising during trust computation. Literature shows that there does not exist a unique definition of trust, since it may vary depending on the context (e.g., PKI, P2P, social networks) and for which purposes it is used (e.g., to ensure quality of service, to associate a “value” to opinions/recommendations). This obviously impacts also how trust is computed. In general, the main issues in trust computation concerns which trust paths must be considered in order to obtain an accurate trust value, since multiple paths may exist connecting two entities. Several solutions have been proposed so far, and, usually, they enforce some constraints in order to select just some of the existing paths (see [12] for a discussion on trust computation). However, in scenarios where trust is used as a parameter to enforce access control, we believe that its value should be computed taking into account also the compliance of user actions to the specified access control policies and/or privacy preferences. Therefore, the OSN should have some mechanisms to help a user to precisely estimate the other network participants trust level. Such mechanisms should also preserve user privacy when performing trust computation. For instance, a naive solution to trust computation is to log all the actions a user performs with respect to resources/relationships disclosure and use such information to estimate the compliance of user actions to the specified policies. Clearly, this solution poses serious privacy concerns in that a user may not want to disclose the details of all his/her actions. As such, methods should be devised that are able to precisely compute trust without compromising user privacy. Some proposals exist in this direction. For example, Nin et al. [26] exploit anonymization strategies on the log file, such that details about the performed access control decisions are kept private but, at the same time, it is possible to determine whether the decisions are correct or not, with respect to the specified policies.

9.4 Review of the Literature

In what follows, we review the literature in view of the requirements discussed in the previous section. We start by illustrating the main proposals of access control models/systems appeared so far. Then, we focus on the solutions proposed to enforce access control in a privacy-preserving manner.

9.4.1 Access Control Models

Recently some research proposals have been appeared aiming to overcome the restrictions of the protection mechanisms provided by current online social networks.

For example, Carminati et al. [10, 12] address access control issues arising in online social networks and propose to model access control requirements in terms of access rules specified by the resource owners. More precisely, these access rules denote authorized members in terms of the type, depth, and trust level of the relationships they must have with other network nodes. In [10, 12] authors also propose a client-based approach to enforce access control, according to which the requestor must provide the resource owner with a proof of being authorized to access the requested resource. As access rules constraint relationships, the proof has to show the existence of the required relationships and that these relationships have the required depth and trust level.

In order to generate valid proofs, it is assumed that a “relationship certificate” is associated with each relationship, containing information on the relationship (i.e., users involved, trust, depth, type), which is signed by both the involved users. A relationship certificate can be seen as a proof that between the involved users there exists a direct relationship of a certain type and with a certain trust level. Proofs of indirect relationship can therefore be generated through a set of certificates confirming the existence of a path of a specified type between them. Based on this access control model, authors have also investigated privacy-aware solutions for access control enforcement (see Section 9.4.2 for more details).

In contrast, the proposal illustrated in [2, 19, 29] represents access control authorizations by means of access control lists (ACLs) associated with resources. In particular, these lists, called social ACLs, contain identifiers of authorized users as well as relationships user must have to gain access. Then, similar to [10, 12], to enforce authorizations stated in social ACLs they rely on relationship certificates, here called “social attestations,” which record information about relationships between two users (i.e., identifiers of involved users and relationship types).

A different approach has been proposed in [1]. Here a multi-level access control solution is proposed, according to which users and resources are organized in security levels and accesses are granted based on the relationships between security levels of the requested resource and the requestor. In order to support this access control model, with each user u is associated a reputation value \(r(u)\), computed as the average of the trust ratings specified for u by other users in the social network. To organize resources into security levels, the system automatically assigns to resources created by a user u a security level equal to τ where τ represents the trust level in the range [\(0,r(u)\)] user has selected when he/she logged in the social network. Then, users are authorized to access only resources with a security level equal or less than τ. In [1], authors proposed to enforce multi-level access control according to a challenge-response-based protocol. In particular, for each resource o, the resource owner generates a secret key K, which is then processed by a (\(k,n\)) threshold algorithm [27]. According to this algorithm, a key K can be split into n portions and then reconstructed based only on k portions of it, where \(k < n\). As such, the proposal in [1] requires that the n portions of K are distributed to n trustworthy nodes. Then, if a requestor wishes to access resource o, the resource owner sends him/her the challenge encrypted with K. The requestor has to retrieve the k portions of K from the set of n nodes holding them. Such portions are released only if the requestor satisfies the trust requirements specified by the resource owner. Once the requestor has reconstructed K, he/she responds to the challenge and gains access to the resource.

Another solution from the same authors proposes to determine access control rights based on the distance between the owner and the requestor [30]. According to this solution, users that directly or indirectly are connected to the owner can be classified into three adjacent zones: “acceptance” zones, whose access requests will be immediately accepted; “attestation” zones, whose access requests require a further evaluation to gain access, and “rejection” zones, whose access requests will be immediately rejected. As a consequence, confidentiality requirements on resources are specified in terms of two distances, called trusted distance, delimiting the three zones.

The proposal presented in [3] exploits cryptographic primitives to enforce a group-based access control in OSNs. The underlying idea is that users are able to organize their friends into groups and assign permissions to them by means of ACLs. As this proposal considers a social network model similar to Facebook (i.e., with simple relationships), group generation does not take into consideration relationship types and trust. This means that users generate groups by explicitly adding friends to them. The main contribution of this proposal is indeed in the cryptographic primitives exploited to enforce the authorizations in ACLs. More precisely, authors make use of attribute-based encryption (ABE) [5], according to which (1) both user’s keys and encrypted data are labeled with a set of attributes and (2) user’s keys are defined such to decrypt an encrypted data only if there is a match between its attributes and those of the data. This last feature greatly improves group key management.

The work reported in [17] presents an interesting analysis of the access control mechanism of Facebook, with the aim to formalize it into a more comprehensive access control model for social networks. As a result, Ref. [17] identifies four different types of privacy policies. The access control policies are one of these types. For each resource, the access control policies state who is authorized to access the resource. Other two policy types have been proposed by taking into consideration that in Facebook it is possible to look for new users in the social network by accessing some parts of users’ profiles as well as users’ friend lists (this allows a search by traversing the social graph). As Facebook makes users able to state privacy settings regulating the access to this information, these are also supported by the model proposed in [17]. These are the search policies and the traversal policies, respectively. The last policy type, called communication policy, aims to make users able to state who is authorized to initiate a given type of communication with him/her.

It is interesting to note that the emerging trend in Semantic Web technologies is to provide much richer social network data (e.g., representing relationships among users and resources in detail) [25]. On these semantically enriched social networks, more flexible and expressive protection mechanisms can be devised, as shown by recent work [9, 15]. For example, in [15] authors focus on online communities, by proposing a semantic framework based on OWL – web ontology language – for defining different access rights exploiting the relationships between the individuals and the community. In contrast, Carminati et al. [9] propose an extension of the relationship-based access control model in [10, 12], based on Semantic Web rules [20].

Table 9.2 summarizes the discussion on related work presented in this section. Proposals are organized according to the supported access control requirements (i.e., defined based on type, trust, and depth of relationships).
Table 9.2

Summary of access control model for social networks

Access control model

Decision based on relationship types

Decision based on relationship trust

Decision based on relationship depth

[9, 10, 12]

Yes

Yes

Yes

[1]

No

Yes

No

[30]

No

No

Yes

[2, 19, 29]

Yes

No

No

[3]

No

No

No

[17]

Yes

No

No

Interesting examples of access control-related solutions can also be found in some software available in existing OSNs. Let us consider Facebook, since it is the OSN for which the majority of these tools have been proposed. We can find some third-party applications aiming to enhance confidentiality of user profiles (e.g., Privacy Protector) or messages posted in walls (e.g., Private Wall, Secret Wall, Private Groups), as well as photos/videos and sensitive data (e.g., Private Photo Gallery, Private Video Gallery, FlybyNight [22]). Other applications help users to be aware of which information of their profiles is available to third-party applications according to users privacy settings (for example, Privacy Mirror, 1984, AppAdvisor, PrivAware).5 Finally, some third-party applications provide users with insightful suggestions for properly setting Facebook privacy configurations (for example, Privacy Helper). Based on information accountability, another interesting application is Respect My Privacy that makes users able to clearly communicate how they want their data to be handled in several different scenarios (e.g., commercial, depiction, financial). However, all these tools do not provide a comprehensive solution to OSN access control, rather they provide solutions only for specific issues related to access control (e.g., photos/videos distribution, wall protection).

9.4.2 Privacy-Aware Access Control

It is important to note that up to now, most of the research related to privacy in OSNs have focused on privacy-preserving techniques to mine social network data [21]. The only proposals we are aware of, providing some solutions for privacy-aware access control, are those reported in [7, 8, 11, 14, 24]. These proposals, that we briefly describe in what follows, differ with respect to both the used techniques and the privacy guarantees they provide.

A first distinction among the various proposals is that some of them are policy-based [8, 11], this means that a user can express his/her privacy requirements with respect to the disclosure of his/her relationships to other users. For instance, through a privacy preference a user may specify that a particular relationship in which he/she is involved can be seen only by his/her colleagues. Moreover, some of the proposals address only the problem of relationship protections [24], whereas the others also consider trust protection. Finally, all the proposals adopt cryptographic techniques to avoid leakage of private information referring to relationships and/or trust.

Let us start from policy-based solutions, according to which privacy requirements related to relationship and trust disclosure are specified by means of distribution rules [8, 11]. A distribution rule basically states who can be aware of a given OSN relationship and exploit it for access control purposes. The system proposed in [11] enforces decentralized access control, according to which existing relationships and resources are not stored in a central repository, but by OSN members themselves, who also carry out the tasks related to access control enforcement and privacy protection. The only centralized service is a certificate revocation list, storing information on the revoked relationships. Additionally, access control is client side, this means that the burden of access control enforcement is mainly on the requestor, that has to provide the owner a proof demonstrating that he/she satisfies the access rules applying to the requested resource. Access control is enforced according to the model described in [12] and summarized in Section 9.4.1, which is based on relationship certificates used to generate proofs. Since the solution proposed in [11] is decentralized, relationship certificates are delivered to OSN members according to the specified distribution rules. To avoid inferences of private relationships, relationship certificates are encrypted and the corresponding keys are distributed only to the users authorized according to the specified distribution rules. Details on the protocols for keys and certificates distribution and update are contained in [11]. Unauthorized relationship disclosure may also happen during access control enforcement, due to the fact that a client-side approach is adopted. Indeed, when a member requests a resource, the owner replies by sending him/her the set of access rules regulating the access to that resource. Access rules give information on the relationships the owner is involved in. For instance, if an owner replies to an access request by requesting a proof stating a consultantOf relationship with another user it is very likely that the owner participates in at least one relationship of type consultant-fof, otherwise no OSN member will be authorized to access the requested resource. To avoid this kind of inferences cryptographic techniques are also adopted, according to which the conditions contained into an access rule are encrypted with a key which is shared only by the users involved in the relationship of the type required by the condition.

One of the main drawbacks of managing encrypted certificates and access rules is that the overhead due to key management may be extremely high. For this reason, in [8] an alternative approach is explored according to which access control (i.e., path discovery) is performed through a collaboration of selected nodes in the network. The collaboration is started by the resource owner who, upon receiving an access request, contacts his/her neighbors asking whether they hold a relationship of the type required by the specified access rules with the resource requestor. The path is incrementally built as the request of collaboration is propagated in the network. The process halts either when a path is found or the request for collaboration cannot be further forwarded. Clearly, each node receiving a request for collaboration is aware of the path built so far and its trust level. For this reason, collaboration is driven by the specified distribution rules in that a node is required to collaborate only if he/she satisfies the distribution rules associated with the relationships in the path built so far. By making use of an ad hoc specified data structure, called onion signature, each user in the path can verify whether previous receivers of the path have correctly enforced distribution rules.

The idea of enforcing privacy-aware access control through a collaboration of selected nodes in the network is further explored in [7]. In this chapter, privacy requirements are not expressed through distribution rules. Rather homomorphic encryption is used to collaboratively build an anonymous path, that is, a path that allows the resource owner to verify whether it matches the specified access rules without revealing the identity of the users involved in the path. An analogous data structure is used for trust computation, that is, to make the owner able to compute the trust of a path without knowing the trust values associated with the arcs composing the path. However, this solution suffers from privacy breaches in the case of paths of length 2. This is avoided by inserting into the architecture a trusted entity in charge of verifying whether this inference can arise and informing the users whose privacy may be violated to let them deciding whether to release or not the path to the owner.

Domingo-Ferrer et al. [14] also exploit homomorphic encryption and user collaboration to enforce privacy-aware access control. With difference to [7] they support a restricted version of the policy language in [12], where the maximum depth of a relationship cannot be used as a parameter to perform access control. Therefore, policies such as “Only my friends and the friends of my friends” are not supported. Similar to [7], the proposal makes use of a trusted entity. However, the optimistic TTP proposed in [14] does not mediate each collaboration process, rather it is contacted only in case of conflicts among the users in the network (for instance, when a user suspects that another one contributed with a fake trust level to path discovery or has modified the trust value inserted by another user during the collaboration process). In summary, main differences between [14] and [7] are related to the policy language they support and the different use of the TTP.

A method to discover relationship paths between two users of an OSN without disclosing the relationships in the path is also proposed in [24]. This method, which does not consider the issue of the private computation of relationship trust, can be the basis of privacy-aware decentralized relationship-based access control. The method exploits a private set intersection protocol by which two parties each one holding a set of elements can compute the intersection of the two sets, without knowing the elements in the set belonging to the other party, apart from those in common to the two parties. The method consists of two steps: a token flooding phase and a path discovery phase. The first phase requires that users are online, whereas the second one can be conducted off-line. During the first phase users generate and propagate along the network cryptographic tokens to privately explore the paths originating from him/her up to a pre-defined depth. To better explain how the process works consider a user u in the network. He/she generates a set of tokens, obtained by hashing with a one-way function a random number concatenated with a counter, and delivers one of the generated tokens to each of his/her neighbors. Each user receiving a token repeats the same procedure (concatenation of the counter value and application of the hash function) before forwarding the token to the subsequent users in the network. Each user locally stores the set of received tokens. Additionally, since token generation follows a deterministic process, each originator of a token t can locally compute all the tokens originated from t. Therefore, two users \(u_{1}\) and \(u_{2}\), by running a private set intersection protocol on the set of received and generated tokens, respectively, can privately discover whether they have a common path. If the intersection of the two sets of tokens is not empty, this means that there exists a path between the two. However, in [24] it is showed that this basic scheme is not robust against all the inferences that can be performed on private relationships. More specifically, by following the protocol above described, it is possible to infer the specific node where two private paths intersect. To avoid this, the protocol has been enhanced with a randomization technique for token generation that avoids the above-described privacy breach. The basic idea is that a user at distance \(d \geq 2\) from the originator receives a token randomly selected from the set of tokens generated for users at distance d. Tokens for intermediate nodes are generated by the so-called bridge contacts, that is, users directly connected to the token originator. The bridge contact generates a set of tokens for users at distance d, \(2 \leq d \leq d_{\max}\). Tokens are generated separately for each distance, by considering the degree of each connected node. Each node does not communicate its exact degree, rather it adds to it a positive noise to prevent inferences on the network topology. As a consequence, dummy tokens are generated and sent along the network. Each user at distance 2 receives from the bridge contact one token for distance 2 and a set of tokens for distance 3 proportional to the number of friends. This process is iterated for users at distance d > 2. Each transmitted token is randomly selected from the set of generated tokens.

9.5 Conclusions and Future Research Directions

In this chapter we have first discussed the access control requirements arising in OSNs, with a particular focus on the privacy issues arising during access control enforcement. We have then reviewed the literature in view of the identified requirements.

However, research in this field is still in its infancy and many interesting issues remain to be explored. First of all a satisfactory solution to relationship privacy protection during path discovery has not yet been devised. All the proposals we reviewed in Section 9.4.2 are based on cryptographic stuff and they suffer from some drawbacks, such as the limitation they put in the policy language they support or in the length of the paths that can be supported in practice or the inefficiency of key management upon a modification of the topology of the OSN. Therefore, the design of a general-purpose and efficient method for private path discovery is still an open issue. Another important problem is related to trust protection during access control. All the methods we reviewed in Section 9.4.2 enforcing privacy protection adopt a very simple way of computing trust, that is, the trust between two nodes is given by the trust of any of the path between the two. However, more elaborated ways of trust computation that lead to a more precise measure of trust have been proposed in the literature (see, e.g., [18]), according to which the trust between two nodes is a function of all the paths between them or of some of them, for instance, the shortest paths. Supporting such measure of trust during privacy-aware access control is still an open issue. This is even more difficult if we want to enforce access control in a fully decentralized way, in that the big issue is how a user may compute all the paths between two nodes in an efficient and private way.

Another important research direction is related to policy administration. As we have seen in this chapter, OSN users need a very flexible policy language to express their privacy/confidentiality requirements. However, when a user specifies an access control policy it is not easy to understand exactly the effect of this policy (for instance, in terms of authorized users), nor its privacy implication (for instance, in terms of relationship disclosure), due to the fact that the SN graph may be very big, with thousands of relations that frequently change. Therefore, a very important issue is to devise techniques and tools that help the user in evaluating the risk of unauthorized flows of information that the specification of a policy or its update may cause.

Footnotes

  1. 1.
  2. 2.
  3. 3.

    A more detailed analysis of privacy practices in 45 OSNs can be found in [6]

  4. 4.

    Trust computation is out of the scope of this chapter, we refer the interested reader to [18] for more details on this topic

  5. 5.

    This problem has been addressed also in [28], where an access control framework enabling users to specify how attributes have to be shared with third-party applications have been proposed

Notes

Acknowledgments

The work reported in this chapter is partially funded by the Italian MIUR under the ANONIMO project (PRIN-2007F9437X).

References

  1. 1.
    Ali B., Villegas W., and Maheswaran M. A trust based approach for protecting user data in social networks. In: Proceedings of the 2007 Conference of the Center for Advanced Studies on Collaborative research (CASCON’07), ACM, New York, NY, pp. 288–293, 2007.Google Scholar
  2. 2.
    Tootoonchian Y.G.A., Saroiu S., and Wolman A. Lockr: Better privacy for social networks. In: Proceedings of the T 5th ACM International Conference on emerging Networking EXperiments and Technologies (CoNEXT), Rome, Italy, 2009.Google Scholar
  3. 3.
    Baden R., Bender A., Spring N., Bhattacharjee B., and Starin D. Persona: An online social network with user-defined privacy. In: Proceedings of the ACM SIGCOMM 2009 conference on Data communication, ACM, New York, NY, pp. 135–146, 2009.Google Scholar
  4. 4.
    Berteau S. Facebook’s misrepresentation of Beacon’s threat to privacy: Tracking users who opt out or are not logged in. CA Security Advisor Research Blog, March 2007, http://community.ca.com/blogs/securityadvisor/archive/2007/11/29/facebook-s- misrepresentation- of-beacon-s-threatto- privacy- tracking-users -who-opt -out-or-are-not-logged-in.aspx.
  5. 5.
    Bethencourt J., Sahai A., and Waters B. Ciphertext-policy attribute-based encryption. In: Proceedings of the 2007 IEEE Symposium on Security and Privacy, IEEE Computer Society , Washington, DC, pp. 321–334, 2007.Google Scholar
  6. 6.
    Bonneau J. and Preibusch S. The privacy jungle: On the market for data protection in social networks. In: The Eighth Workshop on the Economics of Information Security (WEIS 2009), 2009.Google Scholar
  7. 7.
    Carminati B. and Ferrari E. Enforcing relationships privacy through collaborative access control in web-based social networks. In: Proceedings of the 5th International Conference on Collaborative Computing: Networking, Applications and Worksharing, IEEE CS Press, Washington, DC, November, 2009.Google Scholar
  8. 8.
    Carminati B., and Ferrari E. Privacy-aware collaborative access control in webbased social networks. In: Proceedings of the 22nd annual IFIP WG 11.3 working conference on Data and Applications Security, Springer, Berlin, pp. 81–96, 2008.Google Scholar
  9. 9.
    Carminati B., Ferrari E., Ramyond H., Kantarcioglu M., and Thuraisingham B. A semantic web based framework for social network access control. In: SACMAT ’09: Proceedings of the 14th ACM symposium on Access Control Models and Technologies, ACM, New York, NY, pp. 177–186, 2009.Google Scholar
  10. 10.
    Carminati B., Ferrari E., and Perego A. Rule-based access control for social networks. In: OTM 2006 Workshops, vol 2 LNCS 4278, Springer, Berlin, pp. 1734–1744, 2006.Google Scholar
  11. 11.
    Carminati B., Ferrari E., and Perego A. A decentralized security framework for web-based social networks. International Journal of Information Security and Privacy, 2(4):22–53, 2008.CrossRefGoogle Scholar
  12. 12.
    Carminati B., Ferrari E., and Perego A. Enforcing access control in web-based social networks. ACM Transactions on Information and System Security (TISSEC), 13(1):6, 2009.CrossRefGoogle Scholar
  13. 13.
    Chen L. Facebook’s feeds cause privacy concerns. The Amherst Student, October 2006, http://halogen.note.amherst.edu/∼astudent/2006–2007/issue02/news/01.html.Google Scholar
  14. 14.
    Domingo-Ferrer J., Viejo A., Sebé F., and González-Nicolás Í. Privacy homomorphisms for social networks with private relationships. Computer Networks, 52(15):3007–3016, 2008.MATHCrossRefGoogle Scholar
  15. 15.
    Elahi N., Chowdhury M.M.R., and Noll J. Semantic access control in web based communities. In: ICCGI ’08: Proceedings of the 2008 the Third International Multi-Conference on Computing in the Global Information Technology (ICCGI 2008), IEEE Computer Society, Washington, DC, pp. 131–136, 2008.Google Scholar
  16. 16.
    EPIC. Social networking privacy, February 2008, http://epic.org/privacy/socialnet/default.html, 2008. Accessed date: 07/06/2010.
  17. 17.
    Fong P.W.L., Anwar M.M., and Zhao Z. A privacy preservation model for facebook-style social network systems. In: Proceedings of the 14th European Symposium on Research in Computer Security (ESORICS 2009), Saint-Malo, France, September 21–23, 2009.Google Scholar
  18. 18.
    Golbeck J.A. Computing and applying trust in web-based social networks. PhD thesis, College Park, MD (Chair-Hendler, James), 2005.Google Scholar
  19. 19.
    Gollu K.K., Saroiu S., and Wolman A. A social networking-based access control scheme for personal content. In: Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP 07), Skamania Lodge Stevenson, WA, USA, 2007.Google Scholar
  20. 20.
    Horrocks I., Patel-Schneider P.F., Boley H., Tabet S., Grosof B., and Dean M. SWRL: A semantic web rule language combining OWL and RuleML. W3C Member Submission, World Wide Web Consortium, May 2004, http://www.w3.org/Submission/SWRL.
  21. 21.
    Liu K., Das K., Grandison T., and Kargupta H. Privacy-preserving data analysis on graphs and social networks. In: Next Generation Data Mining (eds. H. Kargupta, J. Han, P. Yu, R. Motwani, and V. Kumar), CRC Press, Boca Raton, FL, pp. 419–437, 2008.Google Scholar
  22. 22.
    Lucas M.M. and Borisov N. Flybynight: mitigating the privacy risks of social networking. In: Proceedings of the 7th ACM workshop on Privacy in the electronic society, ACM, New York, NY, pp. 1–8, 2008Google Scholar
  23. 23.
    Au Yeung C.M., Liccardi I., Lu K., Seneviratne O., and Berners- Lee T. Decentralization: The future of online social networking. In: W3C Workshop on the Future of Social Networking, Barcelona, January 2009.Google Scholar
  24. 24.
    Mezzour, G., Perrig A., Gligor V., and Papadimitratos P. Privacy-Preserving Relationship Path Discovery in Social Networks. In: Computer Science; Vol. 5888 Proceedings of the 8th International Conference on Cryptology and Network Security (CANS 2009), December 2009.Google Scholar
  25. 25.
    Mika P. Social Networks and the Semantic Web (Semantic Web and Beyond). Springer, New York, NY, 1st edition, 2007.Google Scholar
  26. 26.
    Nin J., Carminati B., Ferrari E., and Torra V. Computing reputation for collaborative private networks. In: COMPSAC ’09: Proceedings of the 2009 33rd Annual IEEE International Computer Software and Applications Conference, IEEE Computer Society, Washington, DC, pp. 246–253, 2009.Google Scholar
  27. 27.
    Shamir A. How to share a secret. Communications of the ACM, 22(11):612–613, 1979.MathSciNetMATHCrossRefGoogle Scholar
  28. 28.
    Shehab M., Squicciarini A.C., and Ahn G-J. Beyond user-to-user access control for online social networks. In: ICICS ’08: Proceedings of the 10th International Conference on Information and Communications Security, Springer, Berlin, pp. 174–189, 2008.Google Scholar
  29. 29.
    Tootoonchian A., Gollu K.K., Saroiu S., Ganjali Y., and Wolman A. Lockr: social access control for web 2.0. In: Proceedings of the First Workshop on Online Social Networks, ACM, New York, NY, pp. 43–48, 2008.Google Scholar
  30. 30.
    Villegas W., Ali B., and Maheswaran M. An access control scheme for protecting personal data. In: Proceedings of the 2008 Sixth Annual Conference on Privacy, Security and Trust, IEEE Computer Society, Washington, DC, pp. 24–35, USA, 2008.Google Scholar

Copyright information

© Springer London 2010

Authors and Affiliations

  1. 1.Department di Informatica e ComunicazioneUniversità degli Studi dell’InsubriaVareseItaly

Personalised recommendations