Lecture 3: Mobile Social Computing Cristian Borcea

Department of Computer Science

NJIT

2

Improve social connectivity on-line

Stay in touch with friends

Make new friends

Find out information about events and places

Mobile versions: on-line social networking anytime,

anywhere

More than just social networking anytime,

anywhere

New applications benefit from real-time location

and place information

In the near future, they will benefit from other types of

sensing/context information

Smart phones are the ideal devices

Always with us

Internet-enabled

Locatable (GPS or other systems) 3

People-centric Are any of my friends in the cafeteria now?

Recommend interesting groups based on common geo-social patterns

Place-centric Which are the places where CS students hang out?

Geo-tagged multimedia content associated to nearby places

System-centric Smart phones understand social context and silence themselves

during important meetings

Safely and automatically exchange data among mobile devices by

inferring trust from social relations

What software infrastructure is required to support such

applications? 4

Introduction

MobiSoC middleware

Mobius P2P middleware

Prometheus service for social data management

Social group identification

GPI

GDC

5

Common centralized platform for capturing, managing, and sharing the social state of a physical community Discovers emergent geo-social patterns and uses them to augment

the social state

6

7

Manages

History of social relations

Associations between people

and places

Emergent community

patterns

Real-time community

information

API for app development

Sharing done according to

user-specified privacy

constraints

(Mobile Social Computing Applications)

8

Apps split between thin clients running on mobiles and services running on servers

App clients communicate synchronously with the services and receive asynchronous events from MobiSoC

Advantages Faster execution

Energy efficiency

Improved trust

App services register privacy

statements on behalf of the users

Access control objects: conditions under

which a statement applies

Information objects: restricted information

Action objects: action to be taken in case

secondary entity tries to access information

defined by information object

MobiSoC verifies statements when

necessary

9

10

Match Alert

MatchType=Hangout Time: 1-3PM

Co-Location: required

MatchType=Hangout Time: 2-4PM

Co-Location: required

Match Alert

11

Cafeteria

Hungry

12

contactMatches getSocialContacts(requester)

potentialTargets getPeopleAtPlace(“Cafeteria”)

For each user in contactMatches ∩ potentialTargets

pAction checkPrivacyConstraints(user, requester, “TzEvents”)

If pAction == AllowTzEvents

tzEvent.setTimeConstraints(now)

tzEvent.setLocationConstraints(“Cafeteria”)

tzEvent.setTargetUser(user)

tzEvent.setDescription(“Tranzact” + request + requester)

registerEvent (tzEvent)

Use Event Manager to register matches for delivery

Use People Profiling and People-Place Affinity modules to identify social contacts at the Cafeteria

Use Privacy module to check privacy constraints for users

13

Runs on trusted servers

Service oriented architecture over Apache Tomcat

Core services written in JAVA

API is exposed to app services using KSOAP

▪ KSOAP is J2ME compatible and can be used to communicate with

clients

Client applications developed using J2ME on WiFi-enabled

Windows-based smart phones

Location engine: modified version of Intel’s Placelab

Works indoors and outdoors (WiFi fingerprinting)

Accuracy 10-15 meters

14

Introduction

MobiSoC middleware

Mobius P2P middleware

Prometheus service for social data management

Social group identification

GPI

GDC

15

Mobile devices interact with centralized services Not scalable

Lack of flexibility in service provisioning

Big brother scenarios

Mobile devices interact via ad hoc communication Limited functionality due to network partitioning

Lack of trust

Mobile devices interact directly over the Internet Difficult to provide persistent services due to limited resources

(especially battery power, but also CPU and bandwidth)

16

Decentralized 2-tier middleware Users put together their PCs and mobile devices to create a

community infrastructure

P2P tier: provides support for mobile applications Offer persistent services (core or user-deployed)

Manage social state and data

Adapt to geo-social context to improve performance and enable

energy efficiency in the Mobile tier

P2P advantage over cloud: free & could provide better privacy

Mobile tier: runs mobile applications Interact with services provided by the P2P tier

Collect geo-social information using ad hoc communication and share

it with the P2P tier 17

Centralized alternative Global view of social state, easy to infer emergent patterns across all

users

“Big brother” issue

Mobius alternatives Share everything – same with centralized for inferring patterns (but

slower) & worse for privacy

Don’t share anything (social data stored only on user’s devices) -

identify individual patterns & best privacy

Share within community – identify patterns for community & could be

better than centralized for privacy

18

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

19

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

SENSORSSOCIALLY-

AWARE APPS

CallCensor

Foursquare`

`` `

`

`

`

PROMETHEUS

Loopt

20

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,

co-location from mobile phones

21

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

22

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>

<foot

ball,0.

2>

<mus

ic,0

.1>

<hiking

,0.2

5>

<foot

ball,0.

3>

<mus

ic,0

.3>

<fo

otb

all,

0.3

>

<m

usic

,0.2

>

<foot

ball,0.

3>

<mus

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

<foot

ball, 0

.2>

<mus

ic, 0

.1>

<hiking,0.25><football,0

.3><music,0.3>

<football,0.2>

<fo

otb

all,

0.3

>

<m

usic

,0.2

>

<football,0.2>

<football,0.1>

E

23

24

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 graph

Group

Public Key

Private Key

User

Public Key

Private Key

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

25

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 26

27

1st hop

2nd hop 1st 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

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 28

FreePastry Java implementation

with support for

DHT (Pastry)

P2P storage (Past)

Multicast (Scribe)

Social graph management

implemented in Python

29

Introduction

MobiSoC middleware

Mobius P2P middleware

Prometheus service for social data management

Social group identification

GPI

GDC

30

Informally: groups of people who meet face to face

Formal definition: Homans’ sociology book “The Human

Group”

Groups can be used in social or socially-aware

applications

Data forwarding in delay-tolerant ad hoc networks

Recommender systems: recommend concerts to people who go to concerts together

Enhance place semantics for group meeting places using group member profiles (if known)

How to detect groups automatically? 31

Group attendance is variable

People may be merely passing near a group, not

remaining part of it

Group members spend different lengths of time

with the group

Sampling frequency and user mobility can affect

data completeness

32

Identifies previously unknown social groups and their

associated places

Clusters user mobility traces across time and space

Relies on repeated user co-presence at the same place to determine

group members and meeting places

Intuition: group members have a much higher degree of co-presence than non-group members

Experimental results

Mobility traces from 20 users carrying smart phones over one month

period

Identified all groups and places (place accuracy < 10 meters)

33

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0.1 0.2 0.3

Ave

rag

e p

erc

en

tag

e o

f g

rou

p m

em

be

rs id

en

tifie

d

RCP - Required degree of co-presence between X and Y w.r.t. TGM

TGM=50, NGMF=0.1

GMF=0.3

GMF=0.5

GMF=0.7

GMF=0.9

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0.1 0.2 0.3

Avera

ge p

erc

enta

ge o

f non

-gro

up m

em

bers

identifie

d

RCP - Required degree of co-presence between X and Y w.r.t. TGM

TGM=50, NGMF=0.1

GMF=0.3

GMF=0.5

GMF=0.7

GMF=0.9

Identified over 96% of members, when meeting attendance frequency at least 50%

Less than 1% false positives 34

Advantages

Improved location privacy

Low power consumption

Practicality due to Bluetooth ubiquity in mobile phones

Accuracy due to Bluetooth transmission range

User Seen Time

A B 1:00

B A 1:05

INTERNET

A B 1:07

A B

C

B C 1:05

A C 1:07

35

1. Transform raw Bluetooth records into meeting records between pairs of users

2. Discover and record all combinations of users appearing at the same meeting (user clusters)

3. Resolve differences in user perspectives on shared clusters

4. Select all significant clusters and output as user groups

36

Compare GDC and K-Clique

K-Clique uses a time threshold to select graph edges

Experiments

Collected data from mobile phones carried by 100+

volunteer students on campus for one month

Run GDC and K-Clique on collected data

▪ Also tested on Reality Mining data from MIT [Ref 6]

Ask users to rank groups using Likert Scale

▪ 1 to 5; 5 is best

37

GDC groups rated 30% better than K-Clique’s GDC groups are guaranteed to meet

Not all K-Clique groups meet

Some GDC groups are rated poorly because members don’t know their names

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

Very Bad Bad OK Good Very Good

Percenta

ge o

f Tota

l R

ati

ng

s

Rating Category

K-Clique GDC

38

Executed on the phones without server support Phones decide when and what data to exchange

▪ Exchange over Internet or ad hoc

Benefits Better privacy

▪ Avoid “Big Brother” scenario

▪ Ability to control message exchange on a per-case basis

Resiliency: no bottleneck & no single point of failure

Flexibility: each user controls how often to run

D-GDC

Used as social sensor in Prometheus

39

Select next hop based on social group knowledge Membership in the same group(s) with destination

Higher degree (i.e., more socially connected)

▪ Global

▪ Local 40

1. http://cs.njit.edu/~borcea/papers/monet.pdf

2. http://cs.njit.edu/~borcea/papers/selfman08.pdf

3. http://cs.njit.edu/~borcea/papers/middleware10.

pdf

4. http://cs.njit.edu/~borcea/papers/ijmndi08.pdf

5. http://cs.njit.edu/~borcea/papers/sca-

socialcom10.pdf

6. http://reality.media.mit.edu/

7. http://dl.acm.org/citation.cfm?id=1374652

41

1. Two decades of mobile computing

2. Infrastructure support for mobility

3. Mobile social computing

4. People-centric sensing

Smart phone sensing

Activity recognition on smart phones

Vehicle sensing

5. Programming mobile ad hoc networks

6. Vehicular computing and networking

7. Privacy and security in mobile computing

42