Recent Internet applications, such as online social networks and user-generated content sharing, produce an unprecedented amount of social information, which is further augmented by location or collocation data collected from mobile phones. Unfortunately, this wealth of social information is fragmented across many different proprietary applications. Combined, it could provide a more accurate representation of the social world, and it could enable a whole new set of socially-aware applications. We introduce Prometheus, a peer-to-peer service that collects and man- ages social information from multiple sources and implements a set of social inference functions while enforcing user-defined access control poli- cies. Prometheus is socially-aware: it allows users to select peers that manage their social information based on social trust and exploits naturally- formed social groups for improved performance. We tested our Prometheus prototype on PlanetLab and built a mobile social application to test the performance of its social inference functions under real-time constraints. We showed that the social-based mapping of users onto peers improves the service response time and high service availability is achieved with low overhead.
Prometheus: User-Controlled P2P Social Data Management for Socially-aware Applications. Nicolas Kourtellis, Joshua Finnis, Paul Anderson, Jeremy Blackburn, Cristian Borcea, Adriana Iamnitchi. ACM/IFIP/USENIX 11th International Middleware Conference, 2010
9953056974 Young Call Girls In Mahavir enclave Indian Quality Escort service
Prometheus: User-Controlled P2P Social Data Management for Socially-aware Applications
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 11th 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
SOCIAL
SENSORS
SOCIALLY-
AWARE APPS
CallCensor
Foursquare`
`` `
`
`
`
PROMETHEUS
Loopt
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:
<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. 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
B 1 1,2
C 2 1,2,3
D 3 2,3,4,5
E 4 3,4
F 5 3,5
ALL PEERS
A
C F
EB
D
<music,0.15>
<m
usic,0.25>
<football,0.3>
<m
usic,0.1>
<football,0.2>
<m
usic,0.1>
<hiking,0.25>
<football,0.3>
<m
usic,0.3>
<football,0.3>
<music,0.2>
<football,0.3>
<m
usic,0.25>
<hiking,0.3>
<football,0.3>
<m
usic,0.1>
<hiking,0.2>
PEER 1
A
C
B
D
<music,0.15>
<m
usic,0.25>
<football, 0.3>
<m
usic, 0.1>
<football, 0.2>
<m
usic, 0.1>
<hiking,0.25>
<football,0.3>
<music,0.3>
<football,0.2>
<football,0.3>
<music,0.2>
<football,0.2>
<football,0.1>
E
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()
1st hop
2nd hop1st 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
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 10,000 20,000 30,000
CDF
End-to-end response time (msecs)
Neighborhood Requests (10 users/peer)
random - 1hop
random - 2hop
random - 3hop
social - 1hop
social - 2hop
social - 3hop
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 10000 20000 30000
CDF
End-to-end response time (msecs)
Neighborhood Requests (30 users/peer)
random - 1hop
random - 2hop
random - 3hop
social - 1hop
social - 2hop
social - 3hop
20. 20
Social Strength Request Results
Similar performance with 2-hop Neighborhood Requests
Search all 2-hop paths from source to destination
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
0 10000 20000
CDF
Average end-to-end response time (msecs)
Social Strength Requests
random - 10 users per peer
random - 30 users per peer
social - 10 users per peer
social - 30 users per peer
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