Persona: An Online Social Network with User-Defined Privacy

Overview

With nearly half a billion users, online social networks are popular destinations for interaction, communication and collaboration between friends and associates. OSNs, like Facebook (with its more than 250 million users) are built on a three components based architecture: users, service provider and applications.

The users are the core of social networks; they build the fabric for the communication by establishing friendship relations with other users, exchanging messages, creating “interest groups”, posting photos as well as other digital contents. Honest users do not leak friend’s information but compromised machines could. Recent reports reveal the presence of social networks’ attacks that are trying to compromise users’ accounts using both fishing attacks and social worms. Furthermore, social networks are the new target of botnets with already thousands of social networks compromised accounts. Malware authors can use a compromised account to stealthily monitor user’s friends’ activities to gather sensitive information.

Service providers are the engine of the social networks. They offer hardware and software which define the infrastructure and produce the functionality of these social networks. Service providers do not charge users for their services but ask the users to voluntary donate the “Intellectual Property“ of their shared shares.

Facebook application platform alone hosts nearly 52,000 applications, and many of these provide some way of content-sharing service; for example, offering recommendations between friends for everything, ranging from music and books to restaurants, websites, and travel recommendations. By their nature, these social content-sharing applications walk a thin line between promoting content sharing and protecting the individual privacy of users. While sharing content increases the overall utility of the service, most users would probably disagree of having their identity be associated with all of the content that they share.

Having said that, the privacy issues in social network are an actual and challenging problem which is becoming more and more sensible and valuable to the user’s public opinion, mainly due to the increasing popularity of these social networks.

Persona presents the design of a new infrastructure for developing OSNs with user privacy guarantees. The users, in Persona, can choose the privacy level to associate to each piece of contents they share in the OSN. In order to provide the privacy, Persona hides user data with a cryptographic technique so that the data owner can explicitly decide which users are allowed to access to his/her data. Because the data are encrypted, in Persona, the Service provider and applications do not have access to those data unless the owner decides to grant them access to these data.

Strengths

Persona proposes a solution to a key issue in actual social networks, which can be formulated with the following question: “how can user privacy be achieved in OSNs ?”.
Persona presents a cryptographic-based solution to protect privacy sensitive data in OSNs. Furthermore, Persona gives to users the choice to determine several level of object-based privacy; indeed, the users define the rules over who may access their data.
Persona also demonstrates that the proposed design maintains all the functionality of the today social networks giving detailed examples of how to implement walls, chats, status update, news feed and other applications. Moreover, Persona presents the opportunity to develop new applications which treat sensitive private data, like medical records, so that a patients and her/his doctors can share a common and private web space to work on a collaborative diagnosis.

Weaknesses

The biggest concern, in believing that Persona could be implemented, is related to the absolute absence of incentives for service providers and applications in contributing in the develop of this solution. Today, online social networks have the unique income from advertisements. Shading all the contents produces zero knowledge about users’ habit and interest, and consequently, zero incentives from investors to target advertisement on these networks.

In order to make Persona strongly privacy-functional, each user, in the social network, has to manage each piece of information (i.e, single data or a set of data) separately, and explicitly defining the entities (i.e, set of users or applications) that can have access to that data. Strongly active users (the one that contribute for the majority of interaction is social network ) are forced to spend a certain amount of extra time to define the privacy access policy for that piece of data. The user laziness is a well-known fact, so it could be interesting to quantify how much extra time a user should spend to provide privacy to his/her data, as well as to estimate the percentage of users willing to do it. Contrariwise to this manually privacy protecting strategy, it could be interesting to explore some automatic technique which, after a bootstrap phase, is able to identify the right privacy level that an object has to receive based on the user previous history.
Each piece of data in Persona is accessible only to a set of users identified by a particular attribute. It is reasonable to believe that the set of users identified by an attribute (for example family) could need some workings from time to time; when only a subsection of those members are allowed to see a particular data (i.e a user wants to inform only his/her cousins of a crazy party and not his/her parents/ants), the data owner has to continuously modify membership groups or create new groups. Persona lead to believe that the user only need one time groups definition, on the other hand it seems clear that users could require often manipulation of groups membership. These membership manipulation, object-based, could produce unexpected load for the data owner.

This paper proposes an architecture called Persona in order to provide privacy to users in online social networks. They encrypt private content and prevents of user’s application through authentication. As they say, the idea of persona is to put the privacy policies in the hands of the user, letting the user decide who have access to each piece of information. They implemented persona with Facebook profile data. Results show small performance overhead.

Strengths

As online social networks are becoming repository of personal data, privacy is certainly an important topic. This work provides a novel approach to problem and it is a nice reference for further research in this topic.

Comments/Questions

- The evaluation section is missing some important analysis. I would suggest the authors to do a complete evaluation section to a journal extension. As example, every time a user leaves a group, all the other users need to receive a new key. Even with synthetic data this should be evaluated in the paper. What happens if a lot of users start enter and leave communities?

- They say that the system provides the SAME functions of the existing online social networks with additional privacy benefits. But, third party applications would need to be modified to work with persona (as they also say in the end of the paper).

- One interesting question that I heard during the presentation was: OSN can use the information available in OSNs for advertises or whatever. Why OSNs would deploy an architecture that disables that?

The paper presents a new online social network that provides privacy benefits when it comes to share personal data. This problem is particularly relevant these days because we are moving great part of our life and interactions from the physical to the online world(work, entertainment, stay in touch with people, etc).

The proposed architecture takes advantage of attribute-based cryptography and public key cryptography to ensure data confidentiality and enable secure sharing of contents with entire groups defined by the user itself.

The study is really complete as it includes the implementation of a prototype as well as performance tests in different scenarios. Also, although they have implemented a new OSN, the paper shows the feasibility to integrate it with currently deployed OSNs.

The key strengths of the presented architecture lie on:
*user-centricity: the user is the only one deciding about where she stores the content and who can view it
*confidentiality: every content selected by the user to be confidential is protected via encryption, so only the intended persons or applications could view it.
*usability: managing friend relationships, creating groups and granting rights seems to be an easy task aided by the browser extension they designed. Also, all the encryption and decryption processes are made by this extension in a transparent manner. It would be nice to view how this plugin works.

On the other side, this research opens new questions that could be object for further investigation. Nothing stops users from copying, storing or publishing information of a friend who had communicated with him (as remarked in the previous comment). The same occurs with applications: when a OSN user decides to grant access to some personal information (e.g. the case of the "Search application" mentioned in the paper), this information could be used in a malicious way or disclosed/shared without consent.

In the first case, is less relevant because users can establish relationships based on real world knowledge, I mean, having a previous notion of trust in the person. But, what guarantees do we have that an application which has been provided with ABE keys to access our data will maintain these data private? This is definitely a line to explore. Maybe providing meta-information to the users about how well-reputed or trusted is an application could help in the process of decision-making (?).

Also, it would be nice to explore the revocation issue and complete the study with performance analysis in situations when users are removed or added to a group.

Summarizing, this is an interesting and novel work about privacy in OSNs which sets the bases for further research. From my point of view, the needs for these models to start growing are, among others, appropriate divulgation of privacy enhancing technologies and its benefits, as well as social education for people to be conscious of online privacy risks.

Summary

The paper addresses the privacy problem in Online Social Nets (OSNs). It contextualizes the problem in the current dissemination of private information with users having little or no support from the OSNs sites to protect their data (an interesting reference for the disclosure of information by OSNs is also a paper in the WOSN workshop, "On the Leakage of Personally Identifiable Information Via Online Social Networks"). The approach that the authors take is to provide a framework that enables data encryption while maintaining a flexible way to access and distribute the information through the contact list.

The main idea is to use Attribute Based Encryption (ABE) to protect the data. ABE allows to encrypt data with a public key and a set of conditions (attributes) that only holders of secret keys that comply to those conditions can decrypt. These attributes can be text strings ("friend","work-colleague") or comparable values (friend-since=20090817, security-clearance=8). The conditions set on the encryption phase are logic based (and/or) that on decryption test the attributes (is she a friend for more than 2 months? ("friend" AND "friend-since<today-2 months"). It is then possible to "give" secret keys to a contact with the attributes deemed relevant. When encrypting the conditions can be set based on those attributes. A nice presentation on ABE is here.

Based on this concept the authors propose a framework where OSN users would form relationships based on the issuing of private ABE keys with the attributes that describe the relationship. When posting data, users would encrypt the content to the intended recipient's group based on the attributes that define the relationships.

The paper recognizes the performance cost of ABE and it uses symmetric keys for the content encryption and thus ABE is only used to establish the relationships (giving the ABE secret key) and to disseminate the symmetric keys (encrypt/decrypt using ABE) to the intended recipients. A cache for the symm key is also used to further increase perf. Asymmetric crypto is also used to distribute the ABE secret keys to users.

The authors describe the API developed that allows to DefineRelationship(user1,attribs,user2), DefineTransitiveRelationship based on groups defined by other user ("friends-of-bob"), AssignRightsToIdentity and AssignRightsToGroup.

These last two interfaces, relate to Access Control Lists (ACLs) that are used to control access to the resources in the system. A resource is viewed as a generic object (non-data) pertaining to the OSN being used (Facebook wall or space storage).

As such all data objects are encrypted content and the location of the encrypted key to assess the content. The key is encrypted with the ABE keys.

The paper also describes the evaluation done on a set of Facebook profiles to assess the performance impact of Persona. For this the authors built a Firefox plugin that would deal with the references in pages accessed and fetch the encrypted data and recover keys to decrypt the data and present it to the user. As part of this they also develop a generic Doc application that can be tuned to be a Facebook Wall, chat, etc while providing the said advantages.

Comments

The paper addresses a very important problem (albeit the importance depends on who you ask). The solution is interesting and provides a good framework for distributed OSN solutions (such as the one proposed also in WOSN workshop, Privacy, Cost, and Availability Tradeoffs in Decentralized OSNs).

The framework is flexible on the definition of groups (able to be very fine or coarse) while providing a reasonable scalable crypto solution (inherent to the ABE construct).

One thing that I found attractive was that the framework is mostly transparent to the user. It will search for contacts (framework gets the public key when establishing a relationship), set the relationship type (framework issues the ABE secret key based on the attribs), post data to their applications while specifying the intended groups (framework encrypts using the appropriate key), etc. The user mostly has knowingly generate the keys at start and choose which attributes can access the data posted.

Notably this relies, as most other approaches (see also in WOSN, Privacy Preserving Social Networking Over Untrusted Networks) , on a social trust base (nothing stops users from posting the decrypted content on their own, including any keys). But that is a granted assumption on OSNs (or is it??).

The need for a central box (the OSN provider?) or a problematic key distribution problem is inherent in the approach as users will need public keys from other users they want to connect to (they assume that in a distributed system, it would be similar to giving your skype account (whereas the public key would go along)).

Performance does not seem to be a major issue; load times could be better but graph 2.a and the difference between cool and warm load seems to imply that the network transfer of keys is not an issue and graph 2.c shows small decrypt/verify times. These two facts may be pointing to some performance issues on the page rendering itself and on the firefox plugin (??). A comparison to normal facebook pages load time could be interesting.

Another performance hit is the promotion/demotion of a relationship. Changing the relationship (adding/removing attributes: "she is now/no longer my friend") will imply that the ABE secret key needs to be reissued. Which raises the revocation problem. Removing someone from "friend" implies that the sym key for "friend" group must be reissued. Also adding a new "friend" implies he can read old messages (this can be somewhat circumvented with a time attribute for getting the key, which implies some re-keying). As such forward and backward secrecy may not be very simple to achieve.

ACLs and the control to the resources may prove not very scalable if taken to a very fine detail.

Some minor points:

• is there any evaluation on posting data? (where the encryption, creating ABE keys has more impact)
• what is the normal group size in Facebook (as this has impact on the ABE)?
• are the plugin and facebook apps mentioned available?

Some typos:

• in Algorithm 2:
  • 1st APK should be u1.AMSK
  • 2nd and 3rd APKs should be contextualized with u2.
• in Algorithm 2:
  • it is not clear what owner is. Is it the user? It does not seem so has on a example further down StorageServer is used.
  • TPK should be contextualized with u2.

A question made during the paper presentation, asked how could someone be found on the OSN through a search function (when the data is private), is answered with the ability to provide ABE keys to the applications themselves. Apps are dealt in the same manner as other users in terms of getting access to the data. If the issue of "if apps can access it, is it still private?" is set aside, there is underlying the question regarding the usage of OSNs and what is privacy in this context, do users understand it, do users want or need it? (an article by Masiello raises some of these questions on the Security&Privacy magazine).

In summary, the paper proposes what in my view is an interesting approach to take forward on providing privacy on these public networks. I feel that conceptually it is more suited to distributed systems (as the business case (as asked in the presentation) is not very clear)) where there is no central company controlling, although this can pose more problem technically.

(this public review was done as part of the grant program for SIGCOMM09)