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

<music,0.25>

<football,0.3>

<music,0.1>

<football,0.2>

<music,

0.1>

<hiking,0

.25>

<football,0.3>

<music,

0.3>

<fo

otba

ll,0.

3>

<m

usic

,0.2

>

<football,0.3>

<music,

0.25>

<hiking,0.3>

<football,0.3>

<music,0.1>

<hiki

ng,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>

<fo

otba

ll,0.

3>

<m

usic

,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

Group

Public Key

Private Key

User

Public Key

Private 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

20

Social Strength Request Results

Similar performance with 2-hop Neighborhood Requests Search all 2-hop paths from source to destination

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/mobiusnkourtel@mail.usf.edu

26

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

27

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

28

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

29

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

30

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