Lecture 3: Mobile Social Computing

Cristian Borcea
Department of Computer Science
NJIT
 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
2
 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
 (Mobile Social
Computing Applications)

 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
7
 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

8
 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
 MatchType=Hangout
Time: 1-3PM
Match Alert
Match Alert Co-Location: required

MatchType=Hangout
Time: 2-4PM
Co-Location: required

10
 Hungry

Cafeteria

11
 Use People Profiling and
contactMatches  getSocialContacts(requester) People-Place Affinity
potentialTargets  getPeopleAtPlace(“Cafeteria”) modules to identify social
contacts at the Cafeteria
For each user in contactMatches ∩ potentialTargets
pAction  checkPrivacyConstraints(user, requester, “TzEvents”)
If pAction == AllowTzEvents
tzEvent.setTimeConstraints(now) Use Privacy module
to check privacy
tzEvent.setLocationConstraints(“Cafeteria”)
constraints for users
tzEvent.setTargetUser(user)
tzEvent.setDescription(“Tranzact” + request + requester)
registerEvent (tzEvent)

Use Event Manager to

register matches for
delivery
12
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 PROMETHEUS SOCIALLY-

SENSORS AWARE APPS

Loopt

` ` ` ` CallCensor

` ` Foursquare
`

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 Owns Trust ALL PEERS PEER 1

ID Peer Peer <music,0.15>
> > B <music,0.15>
1>
B <f 25 E .1
A --- 1,2
. 0
0. <f ootb ,0 3> ic, 2>
E
i c,
.2
> oo a u si c l,0 >
.
us 0. <fo
us l ,0 tb ll,0
<m a l 0 .2 l l, otb
l all .2 b <m ba
all,
B 1 1,2 <m tba

<football,0.3>
t ,
<football,0.3>

,0 > 0 .2
<music,0.2>

oo ng ot

<music,0.2>
oo .1
> < f i ki <f
o >
<f <h
C 2 1,2,3 A <m .3
> D <m
us A <m 0.3
> D
<f u , 0 > < fo ic, ic,
oo sic, i c .3 o 0. <f us u s .3 >
D 3 2,3,4,5 us ,0 5> <h tb 1> o i <m ll ,0 >
<m tba 0. l l i k a l <m otb c, 0 a
us ll,0 1> < m
t
a
b ,0. 2 ing 0 l , us all, .1> otb .25
i c, . oo g ,0 .3> ic, 0 <fo ing,0
0. 3 > < f i ki n .3 0. .3> ik
E 4 3,4 25
> <h
> 25
>
<h
C F C
F 5 3,5
23
 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

User
Public Key
Private Key

Group
Public Key
Private Key 24
 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
 1. Application sends request to a peer
1st hop 2. Peer forwards request to trusted peer
3. Trusted peer enforces ACPs
4. Trusted peer sends secondary requests
1st hop 2nd hop 5. Trusted peers enforce ACPs & reply
6. Primary peer combines results
7. Primary peer replies to application through
contacted peer with final result

27
 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
 TGM=50, NGMF=0.1 TGM=50, NGMF=0.1
Average percentage of group members identified

Average percentage of non-group members identified

GMF=0.3 GMF=0.3

100% GMF=0.5 100% GMF=0.5

90% GMF=0.7 90% GMF=0.7
80% 80%
GMF=0.9 GMF=0.9
70% 70%
60% 60%
50% 50%
40% 40%
30% 30%
20% 20%
10% 10%
0% 0%
0.1 0.2 0.3 0.1 0.2 0.3

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

 Identified over 96% of members, when meeting

attendance frequency at least 50%
 Less than 1% false positives
34
 User Seen Time
A B 1:00
B A 1:05
INTERNET B C 1:05
A B 1:07
A C 1:07
 Advantages
 Improved location privacy
A
 Low power consumption B
 Practicality due to Bluetooth ubiquity in mobile phones
 Accuracy due to Bluetooth transmission range
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
 0.35

K-Clique GDC
0.3
Percentage of Total Ratings

0.25

0.2

0.15

0.1

0.05

0
Very Bad Bad OK Good Very Good
Rating Category

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