"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
A new approach for sharing location info
1. Where Are They Now – safe
location sharing.
A new model for location sharing
services
Dmitry Namiot
Lomonosov Moscow State University
Manfred Sneps-Sneppe
Ventspils University College
ruSMART 2012
2. What are we talking about?
• “Where are you” is one of the most often asked
question during the communications. 600 billion text
messages per year in the US
• Sharing location info is one of the popular functions
for LBS applications
• Mostly – via sharing location info through social
networks. Could be either direct settings or “check-
ins”
• One of the biggest concerns for all location-based
services is user’s privacy. The biggest problem for
LBS adoption.
Dmitry Namiot http://servletsuite.blogspot.com
3. Existing solutions
• Access restriction: only part of the social graph
can see location
• Location obfuscation. It could be social graph
dependent too.
• K-anonymity
• The central store knows all. It is trusted source in
the existing models.
• Can we share location info without the central
server?
Dmitry Namiot http://servletsuite.blogspot.com
4. Geo Messages
• Lets you add signature
with location info to
messages (email, SMS)
• It is peer to peer sharing
• Difficulty to operate if
you have many peers
Dmitry Namiot http://servletsuite.blogspot.com
5. WATN
Where Are They Now
• Key moment for privacy related problems: central
store with IDs and location info
• WATN – share location information without the
entity that knows all
• Developed and implemented as mobile web
application (HTML5)
• HTML5 is significant here
Dmitry Namiot http://servletsuite.blogspot.com
6. WATN
• Distributed database: identification and location
should be separated
• Social graph and anonymous location info
should be saved server-side
• Identification info should be saved locally
• Each participant should have own copy of
identification database
• There is no global ID for the participant
Dmitry Namiot http://servletsuite.blogspot.com
7. WATN
• Run:
a) get unique ID or read it from local storage
b) perform check-in (save location info)
• Share:
a) send a link with own ID. It is an ordinary
message (outside of this application)
b) two IDs for ‘share location’ link
Dmitry Namiot http://servletsuite.blogspot.com
9. WATN
• Server keeps two things.
a) location info with meaningless IDs. Just a set of
current coordinates for users (presented via own IDs)
ID1 -> (latitude, longitude)
ID2 -> (latitude, longitude)
ID3 -> (latitude, longitude) etc.
b) social graph – who is sharing location to whom:
ID1-> (ID2, ID3)
ID3 -> (ID1) etc.
Dmitry Namiot http://servletsuite.blogspot.com
11. WATN
• Client side: keeps legend
ID1 -> (name or nick)
ID2 -> (name or nick)
• Data flow:
a) request social graph by ID
b) obtain data from server (JSON)
c) map data against locally saved legend and replace
IDs with nick names
Dmitry Namiot http://servletsuite.blogspot.com
13. Conclusion
• A new approach for sharing location information
• There is no central server with IDs for all
participants
• Separated location info and identity
• Shortly: peer to peer location sharing system with
distributed database for location info and identity
Dmitry Namiot http://servletsuite.blogspot.com