Prometheus: User-Controlled P2P Social Data Management for Socially-aware Applications

ACM/IFIP/USENIX 11th International Middleware Conference, 2010 Prometheus: User-Controlled P2PSocial Data Managementfor Socially-aware Applications Nicolas Kourtellis, Joshua Finnis, Paul Anderson, Jeremy Blackburn, Cristian Borcea*, Adriana Iamnitchi Department of Computer Science and Engineering, USF *Department of Computer Science, NJIT

Social and Socially-aware Applications Applications may contain user profiles, social networks, history of social interactions, location, collocation

Problems with Current Social Information Management • Application specific: • Need to input data for each new application • Cannot benefit from informationaggregation across applications • Typically, data are owned by applications: users don't have control over their data • Hidden incentives to have many "friends": social information not accurate

Our Solution: Prometheus • P2P social data management service: • Receives data from social sensors that collect application-specific social information • Represents social data as decentralized social graph • Exposes API to share social information with applications according to user access control policies

Outline • Motivation • Social Graph Management • API and Access Control • Prototype Implementation • Evaluation over PlanetLab • Summary • Future Work

How is the Social Graph Populated? • Social sensors report edge information to Prometheus: <ego, alter, activity, weight> • Applications installed by user on personal devices • Aggregate & analyze history of user's interactions with other users • Two types of social ties: • Object-centric: use of similar resources • Examples: tagging communities on Delicious, repeatedly being parts of the same BitTorrent swarms • People-centric: pair-wise or group relationships • Examples: friends on Facebook, same company name on LinkedIn, collocation from mobile phones

Social Graph Representation • Multi-edged, directed, weighted, labeled graph • Each edge → a reported social activity • Weight → interaction intensity • Directionality reflects reality • Allows for fine-grain privacy • Prevents social data manipulation

Decentralized Graph Storage • Each user has a set of trusted peers in the P2P network • Peers it owns & peers owned by trusted users • Each user’s sub-graph stored on all its trusted peers • Improved availability in face of P2P churn • P2P multicast used to synchronize information among trusted peers

Encrypted P2P Storage • Sensor data stored encrypted in P2P network • Improves availability and protects privacy • Sensors encrypt data with trusted group public key & sign with user private key • Trusted peers retrieve user data, decrypt it, & create social graph User Public Key Private Key Group Public Key Private Key

Prometheus Application Interface • Five social inference functions: • Boolean relation_test (ego, alter, ɑ, w) • User-List top_relations (ego, ɑ, k) • User-List neighborhood (ego, ɑ, w, radius) • User-List proximity (ego, ɑ, w, radius, distance) • Double social_strength (ego, alter) • Ego & alter don’t have to be directly connected • Normalized result: consider ego’s overall activity • Search all 2-hop paths

Application Example: CallCensor • Socially-aware incoming call filtering • Ring/vibrate/silence phone based on current social context and relationship with caller • Invokes • proximity() to determine current social context • social_strength() to determine relationship with caller

1st hop 1st hop 2nd hop 2nd hop Request Execution: social_strength() • Application sends request to a peer • Peer forwards request to trusted peer • Trusted peer enforces ACPs • Trusted peer sends secondary requests • Trusted peers enforce ACPs & reply • Primary peer combines results • Primary peer replies to application through contacted peer with final result

Access Control Policies • User specifies ACPs upon registration • ACPs stored on user’s trusted peer group • Update them at any time • Changes propagated through multicast mechanism • Applied for each inference request • Control relations, labels, weights & locations Example: Alice’s ACPs relations: hops-2 hiking-label: lbl-hiking work-label: lbl-work general-label: --- weights: --- location: hops-1 blacklist: user-Eve

Prototype Implementation • FreePastry Java implementation with support for • DHT (Pastry) • P2P storage (Past) • Multicast (Scribe) • Social graph management implemented in Python

Evaluation over PlanetLab • Goals: • Assess performance under realistic network conditions (peers distributed around the world) • Assess performance at large scale using realistic workloads with large number of users • Assess the effect of socially-aware mapping of users onto trusted peers on system’s performance • Validate Prometheus with socially-aware application under real-time constraints (CallCensor) • Metric: end-to-end response time

Large-Scale Evaluation Setup • 100 PCs around the globe • RTT~200-300ms • 1000 users: synthetic social graph • Random vs. socially-aware trusted peer assignment • 10 & 30 users assigned per peer • Workloads for: • Social sensor inputs based on Facebook study • Neighborhood requests based on Twitter study • Social strength requests based on BitTorrent study • Applied a timeout of 15 seconds to fulfill a 1-hop request in PlanetLab

Neighborhood Request Results • Socially-aware assignment of users onto peers results in faster response time • Message overhead reduced by an order of magnitude • Replication for improved availability does not induce high overhead

Social Strength Request Results • Similar performance with 2-hop Neighborhood Requests • Search all 2-hop paths from source to destination

CallCensor Evaluation Setup • CallCensor implemented and tested on Nexus Android phone • 100 users: real social graph • Volunteer students from NJIT • Two social sensors • Collocation from Bluetooth • 45 & 90 minutes threshold • Friendship from Facebook • 3 USA PlanetLab peers • Socially-aware trusted peer assignment

CallCensor Results • Met real-time performance constraint: response arrives before call forwarded automatically to voicemail

Summary • Users of Prometheus: • Decide what personal social data are collected by installing/configuring social sensors • Cooperate to store and manage their social data in a decentralized fashion • Own and control access to their data • Prometheus enables: • Socially-aware applications that utilize social data collected from multiple sources • Accurate social world representation through multi-edged, labeled, directed and weighted graph • Improved performance through socially-aware P2P system design

Future Work • Improve Prometheus performance • Network optimizations • Caching of inference request results • Develop new social sensors • Develop new socially-aware applications & services • Study tolerance to malicious attacks • Exposure of social information to intermediate peers during request execution • Manipulation of social connections to alter the structure of the social graph

Thank you!This work was supported by NSF Grants:CNS 0952420, CNS 0831785, CNS 0831753http://www.cse.usf.edu/dsg/mobiusnkourtel@mail.usf.edu

Why P2P? • 1st alternative: Free Centralized Service • No incentives or business model for free storage and service of encrypted data • 2nd alternative: Cloud • Cost for transferring and storing data • Tradeoff between privacy & inference functionality • 2nd alternative: mobile phones • Limited energy and computation power • Not always online (service unavailability) • Not always synchronized, for fast and efficient inference support

Prometheus vs. Facebook? • Both collect social information of users from multiple sources but: • Facebook is limited to input from Facebook-controlled sources • Prometheus accepts input from any user-defined social source (sensor) • User-control of social information • Prometheus allows full user-control: • Storage of data • Exposure of data to users, applications & services • Facebook allows very limited user-control: • Exposure of data to users, applications & services* • Always at odds with its business model

Updating the Social Graph • Social data for each user stored as append-only file in P2P network • Atomic appends using lock file for synchronization • Trusted peers periodically check for new inputs for a user • May have inconsistent data for short time periods • Not major problem: social graphs do not change frequently • After authentication, new input is merged with the social graph of the relevant user

Social Sensors: Challenges • Identifying activity tags: • Mine text for keywords (emails, sms, blogs,...) • Reverse geo-coding to find where (co)located • Predefined labels or dictionaries and ontologies • Quantifying interactions (assigning weights): • Frequency, duration, time in-between interactions • Familiar strangers versus active social interactions

Related Work • SONAR: aggregation of social information only within an enterprise context (emails, IM, etc) to improve information flow • RE: 2-hop relationships to automatically populate email white-lists; • Prometheus: can extract social knowledge from larger portions of the graph than direct or 2-hop neighborhood • Social information and requests can cross application boundary contexts • Persona: Attribute based encryption of data for sharing between apps while applying fine-grained access policies from users • PeerSoN: direct data exchange between users’ devices • Prometheus: trusted peers reliably store & exchange social data • Vis-á-Vis: store data on Virtual Independent Servers on the cloud to deal with churn • Prometheus: social incentives in trusted peer selection to reduce churn • MobiSoc: logically centralized -> “big brother concerns” • Prometheus: fully decentralized on P2P network • MobiClique: Delay tolerant networking middleware for disseminating social information

Prometheus: User-Controlled P2P Social Data Management for Socially-aware Applications