prometheus: user-controlled p2p social data management for socially-aware applications
TRANSCRIPT
Prometheus: User-Controlled P2PSocial 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 11th International Middleware Conference, 2010
2
Social and Socially-aware Applications
Applications may contain user profiles, social networks, history of social interactions, location, collocation
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
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
SOCIAL SENSORS
SOCIALLY-AWARE APPS
CallCensor
Foursquare`
`` `
`
`
`
PROMETHEUS
Loopt
5
Outline
Motivation Social Graph Management API and Access Control Prototype Implementation Evaluation over PlanetLab Summary Future Work
6
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
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
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,2B 1 1,2C 2 1,2,3D 3 2,3,4,5E 4 3,4F 5 3,5
ALL PEERS
A
C F
EB
D
<music,0.15>
<music,0.25>
<football,0.3>
<music,0.1>
<football,0.2>
<music,
0.1>
<hiking
,0.25>
<football,0
.3>
<music,
0.3>
<foo
tbal
l,0.3
>
<mus
ic,0
.2>
<football,0
.3>
<music,
0.25>
<hiking,0.3>
<football,0.3>
<music,0.1>
<hiking
,0.2>
PEER 1
A
C
B
D
<music,0.15>
<music,0.25>
<football, 0.3>
<music, 0.1>
<football, 0
.2>
<music,
0.1>
<hiking,0.25><football,0.3>
<music,0.3>
<football,0.2>
<foo
tbal
l,0.3
>
<mus
ic,0
.2>
<football,0.2>
<football,0.1>
E
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
GroupPublic KeyPrivate Key
UserPublic KeyPrivate Key
10
Outline Motivation Social Graph Management API and Access Control Prototype Implementation Evaluation over PlanetLab Summary Future Work
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
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
Request Execution: social_strength()
1st hop
2nd hop1st hop
2nd hop
1. Application sends request to a peer2. Peer forwards request to trusted peer3. Trusted peer enforces ACPs4. Trusted peer sends secondary requests5. Trusted peers enforce ACPs & reply6. Primary peer combines results7. Primary peer replies to application
through contacted peer with final result
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 & locationsExample: Alice’s ACPsrelations: hops-2hiking-label: lbl-hikingwork-label: lbl-workgeneral-label: ---weights: ---location: hops-1blacklist: user-Eve
15
Outline Motivation Social Graph Management API and Access Control Prototype Implementation Evaluation over PlanetLab Summary Future Work
16
Prototype Implementation FreePastry Java implementation with support for
DHT (Pastry) P2P storage (Past) Multicast (Scribe)
Social graph management implemented in Python
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
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
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
0 10,000 20,000 30,0000
0.10.20.30.40.50.60.70.80.9
1
Neighborhood Requests (10 users/peer)
random - 1hop
random - 2hop
random - 3hop
social - 1hop
social - 2hop
social - 3hop
End-to-end response time (msecs)
CD
F
0 5000 10000 15000 20000 25000 30000 350000
0.10.20.30.40.50.60.70.80.9
1
Neighborhood Requests (30 users/peer)
random - 1hop
random - 2hop
random - 3hop
social - 1hop
social - 2hop
social - 3hop
End-to-end response time (msecs)C
DF
20
Social Strength Request Results
Similar performance with 2-hop Neighborhood Requests Search all 2-hop paths from source to destination
0 10000 200000.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
Social Strength Requests
random - 10 users per peer
random - 30 users per peer
social - 10 users per peer
social - 30 users per peer
Average end-to-end response time (msecs)
CD
F
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
CallCensor Results
Met real-time performance constraint: response arrives before call forwarded automatically to voicemail
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
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
Thank you!
This work was supported by NSF Grants:CNS 0952420, CNS 0831785, CNS 0831753
http://www.cse.usf.edu/dsg/[email protected]