1. Prometheus: User-Controlled P2P Social Data Management for 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 ACM/IFIP/USENIX 11 th International Middleware Conference, 2010

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

3. 3 Problems with Current Social Information Management  Application specific: Need to input data for each new application Cannot benefit from information aggregation 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

4. 4 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

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

6. 6 How is the Social Graph Populated?  Social sensors report edge information to Prometheus: 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

7. 7 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

8. 8 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 User ID Owns Peer Trust Peer A---1,2 B1 C21,2,3 D32,3,4,5 E43,4 F53,5

9. 9 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 Group Public Key Private Key User Public Key Private Key

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

11. 11 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

12. 12 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

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

14. 14 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

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

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

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

18. 18 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

19. 19 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

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

21. 21 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

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

23. 23 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

24. 24 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

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