=Paper=
{{Paper
|id=Vol-371/paper-1
|storemode=property
|title=Implementing Privacy as Symmetry in Location-aware Systems
|pdfUrl=https://ceur-ws.org/Vol-371/CAT08_PKetal.pdf
|volume=Vol-371
}}
==Implementing Privacy as Symmetry in Location-aware Systems==
https://ceur-ws.org/Vol-371/CAT08_PKetal.pdf
Implementing Privacy as Symmetry in
Location-aware Systems
Anders Kofod-Petersen, Espen Klæboe, Jørgen Jervidalo, Kjetil Aaltvedt,
Magnus Romnes, and Trond Martin Nyhus
Department of Computer and Information Science,
Norwegian University of Science and Technology,
7491 Trondheim, Norway
anderpe@idi.ntnu.no,{espenkl|jervidal|kjetilue|romnes|trondmn}@stud.ntnu.no
Abstract. Social network services on the internet are moving from a
traditional web-based service into ubiquitous computing environments.
With this migration these services will also benefit from the context-
awares that ubiquitous computing offers. Applications that sense the
environment and act proactively, requires an immaculate attention to
users’ privacy. The work presented here approaches privacy by employing
the principle of minimum asymmetry to a mobile social network service.
We demonstrate how this principle can be implemented on a simple
location-aware application running on standard mobile telephones in a
traditional GSM network.
1 Introduction
The number and popularity of digital social networks have been steadily in-
creasing over the last few years. Privacy and trust are important issues in these
social aware applications. The importance will increase tremendously when so-
cial aware applications are moved into mobile or pervasive applications. When
applications assume responsibility from the user and act proactively, as perva-
sive applications do by definition, the control over what information is shared
and to whom becomes paramount.
One important approach to maintain privacy and trust in pervasive applica-
tions is the principle of minimal asymmetry, which in short states that the ability
to obtain information should be coupled with the sharing of information. The
work presented here demonstrates how how this principle can be applied in a
mobile social-aware application. The application implements location-awareness
on standard mobile phones in running in a GSM network.
The rest of the paper is organised as follows: First, an overview of related
work concerning privacy in ubiquitous computing is presented. This is followed
by a description of the systems design and implementation. The paper ends with
a summary and pointers to future work.
2 Related Work
Social systems that link people to people, and people to geographical places are
referred to as P3 systems [1]. P3 systems can be divided into two difference
categories: people-centered and place-centered. An example of a people-centered
system might be one where a user has a contact list, where the contacts show
up in different colours (green, yellow, red) depending on their proximity. Jones
and Grandhi presented a survey executed at various places in Manhattan with
more that 500 participants. Among other things, they discovered that 84% of the
participants were willing to share their location data (anonymously) to get in-
formation about crowding and occupancy in public places. They concluded that
a large population considered P3 systems to be sufficiently beneficial to disclose
their position. The fact that this percentage of the population were willing to
give away their position in exchange for a service that they considered beneficial
is an important insight when modelling context-aware systems, and perhaps even
more important when systems are to reason about what (contextual) information
they can share and to whom.
With regard to privacy in context-aware systems, Langheinrich [2] describes
why privacy is of particular importance in ubiquitous computing with four prop-
erties: ubiquity, computers are everywhere; invisibility, computers disappear from
the scene; sensing, sensors are becoming more precise; and memory amplification,
storing of large amount of (sensed) data.
Many of the privacy issues in context-aware systems are related to the is-
sue of mutual awareness. One part of this problem is about disembodiment and
dissociation. When we encounter people in the real world we can receive infor-
mation in many ways, such as position, voice level, face expression and direction
of gaze. In ubiquitous environments these communication channels are likely to
be less effective. In real life people live by the intuitive principle that if you
cannot see me, I cannot see you. Due to the potential large number of sensors in
an ubiquitous environment, this is not always true. Users may not always know
exactly what information they are conveying, in what form, if it is permanent,
and to whom they are sending [3].
Jiang et al. [4] discusses the principle of minimum asymmetry when deal-
ing with privacy issues in ubiquitous computing. This principle goes a long way
towards handling the apparent asymmetric relationship between sender and re-
ceiver of information, as described by Bellotti et al. [3]. Jiang et at. argue that
a privacy-aware system should minimise the asymmetry of information between
data owners and data users. For an example, if a user does not wish to share his
location he cannot expect others to share their location with him (regardless of
their wish). The main principle is that [4, p. 7] (original emphasis):
A privacy aware system should’ minimize the asymmetry of infor-
mation between data owners and data collectors and data users,
by:
– Decreasing the flow of information from data owners to data col-
lectors and users
– Increasing the flow of information from data collectors and users
back to data owners
When decreasing the flow of information from the data owner the user main-
tains a higher degree of control over the system. Increasing information flow
from the data collector provides better feedback to the user. Examples of mech-
anisms that adhere to this principle are: anonymising or pseudonymising, which
approaches privacy by allowing users to act in total anonymity or through a
consistent avatar that cannot be coupled with a real person. Further, plausible
deniability allows the user to plausible deny that he did not wish to interact
with a particular person, at a given time [5]. Finally, reciprocity is the essential
property for building trust and deep relationships. Sharing too little or too much
information might have a negative effect on relations to one’s peers. Balancing
the amount on information flowing between peers are very important to main-
tain a balance in any relationship. Social systems often approaches this by for an
example only allowing you to see the status of the people whom you allow to see
your status. To receive better feedback from the system it might log all access
to one’s position data, notify the user when somebody requests a position, and
give clear feedback on what information is stored [4].
Lederer et al. [6] argues that feedback and control is “the designer’s oppor-
tunity to empower those processes (understanding and action), and they are the
user’s opportunity to practice them.” The authors exemplify pitfalls in design of
systems maintaining privacy using their personal experience. The pitfalls can be
divided into two main groups: feedback and control. The feedback pitfalls are: ob-
scuring potential information flow, where systems do not explicitly describe the
possible disclosures it can make; and obscuring actual information flow, where
a system might not explicitly make clear what information is actually disclosed.
The control pitfalls are: emphasising configuration over action, where configura-
tion overshadows the privacy management actually needed to adapt to a user’s
ordinary use of the system; lacking coarse-grained control, where a system of-
fers too many choices and not just simple on/off choices; and Inhibiting existing
practice, where a system forces some required practice onto a user, and does not
adapt to the user’s practice.
As aforementioned, digital social networks have recently emerged, and along
with them several communication protocols and representational models. Among
these are: XHTML Friends Network (XFN), Friend of a Friend (FOAF) and Ex-
tensible Messaging and Presence Protocol (XMPP) commonly known as Jabber.
XFN1 is a decentralised markup language that captures social connectivity.
This language can represent different forms of social connectivity, such as the
level of friendship, professional relations, geographical proximity, family ties and
romantic aspects. XFN maintains some privacy related limitations, such as the
fact that many personal attributes cannot be assigned by others. Some examples
of these include: gender, race and age. This limitation is founded in the fact that
a user describes a relation to another person from that user’s perspective, and
1
http://gmpg.org/xfn/
not the friend. Since a “friendship” in XFN is directional relationship managed
solely by the user who initiates a relation, the principle of minimal asymmetry
seems hard to maintain.
FOAF2 is like XFN a modelling language used to represent social relations.
FOAF have chosen RDF, a more expressive language that XHTML chosen by
XFN. FOAF is currently an immature language, which does not explicitly cover
issues such as control of data within a community of trust, guaranty of facts and
general privacy of data.
XMPP3 , or Jabber as it is commonly know, is a message protocol for instant
messaging services [7,8]. The Jabber specification defines a XML streaming pro-
tocol that covers not only instant messaging but also issues such as presence. As
the XML protocol is extensible, the core functionality such as authentication,
privacy mechanisms and chatting are easily extensible.
3 Design and Implementation
Find Per Anton (hereby referred to as ”the application”) is a location-aware
instant messaging application developed for mobile phones. It utilises the un-
derlying TCP/IP-network capabilities (such as GRPS, UMTS and Wi-Fi) of the
mobile phone and will supplement a similar application based on Wi-Fi tech-
nology [9]. The localisation service is obtained from the third party provider
Geomatikk4 and all transmissions between the server and the client uses the
XMMP protocol.
The idea is to have the opportunity to sort your friends in groups, locate
one friend or a whole group on the map and also be able to send messages to
contacts or whole groups. The application provides feedback about the locations
of the peers of a user by indicating their proximity using colours ranging from
red to green and by showing their position on a map. An example of how the
map service might look can be seen in Fig. 1.
Table 1. Presence states allowed by the XMPP standard.
Name: Description:
offline The entity or resource is not connected to the server.
chat The entity or resource is actively interested in chatting.
away The entity or resource is temporarily away.
dnd The entity or resource is busy (dnd = ”Do Not Disturb”).
xa The entity or resource is away for an extended period (xa = ”eXtended
Away”).
2
http://www.foaf-project.org/
3
http://www.xmpp.org/
4
http://www.geomatikk.no/
Fig. 1. An example of the map service running on a mobile device
As mentioned above the application design builds on the XMPP standards
[7,8]. Unfortunately, XMPP does not enforce the principle of minimum assym-
metry, which is a requirement for the application. For this reason, a deviation
was made between the original specification and the application design by only
supporting a subset of the XMPP subscription states. The subscription states
supported by the original XMPP specification can be seen in Table 2. Every
subscription state except None and Both was omitted from the application de-
sign because they contradict the principle of minimum asymmetry by allowing a
user to receive information without releasing information himself. In the XMPP
standard, adding a contact is refered to as subscribing to a contact and a contact
list is refered to as a roster list, so we will use these terms from now on.
In order to establish a subscription, both users must agree to share presence
information and location information with the other part. This requirement
allows the application to enforce the principle of minimum asymmetry. The
presence information contains the current status of the user, which may be away,
chat, dnd, xa or offline. A detailed description of the presence status can be
found in Table 1. The location information contains the longitude and latitude
of a user, and will appear graphically as a position on a map. This way a user
can physically locate the position of any of his contacts, in return for being
discoverable himself. A user can temporarily make himself invisible to others,
but he is then no longer entitled to receive any location information, until he
Table 2. Subscription states supported by the XMPP standard, described from the
user’s perspective.
Name: Description:
”None” Contact and user are not subscribed to each other, and
neither has requested a subscription from the other.
”None + Pending Out” Contact and user are not subscribed to each other, and
user has sent contact a subscription request but contact
has not replied yet.
”None + Pending In” Contact and user are not subscribed to each other, and
contact has sent user a subscription request but user has
not replied yet.
”None + Pending Out/In” Contact and user are not subscribed to each other, con-
tact has sent user a subscription request but user has
not replied yet, and user has sent contact a subscription
request but contact has not replied yet.
”To” User is subscribed to contact (one-way).
”To + Pending In” User is subscribed to contact, and contact has sent user
a subscription request but user has not replied yet.
”From” Contact is subscribed to user (one-way).
”From + Pending Out” Contact is subscribed to user, and user has sent contact
a subscription request but contact has not replied yet.
”Both” User and contact are subscribed to each other (two-way).
makes himself discoverable again, as discussed by Jiang et. al [4]. When he makes
himself invisible, he will appear as offline to his contacts, just as if he had turned
off his mobile phone.
When a user cancels a subscription, the contact is not notified. The contact
is removed from the user’s roster list, but the user is only shown as offline
on the contact’s roster list, thus preserving minimum asymmetry and plausible
deniability.
In Listing 1.1, we show a simplified pseudo code example of how a user adds a
subscriber (contact) to his roster list in the application. The client sends a request
for a new subscription to the server, using the method newSubscription(). The
server checks the current subscription state for the subscriber. In an initial state,
there will not exist any relations between the user and the contact, so the server
will store the new subscription state (None) and send a subscription request to
the contact. If the contact accepts the subscription request, his client will send
a subscription request to the server, again using the same newSubscription()-
method. This time, when the server receives the request, there already exists a
relation between the user and the contact, so the server sets the subscription
states to Both for the user and the contact, adds them to the respective roster
lists and pushes the new roster lists to both clients. The symmetrical subscrip-
tion state Both is the only state where positioning, presence notifications or
messaging is allowed.
Listing 1.1. Implementation Pseudo Code (Add a Friend)
// [ CLIENT ] User 1 r e q u e s t s t o add User 2 a s a f r i e n d :
function addFriend ( newcontact )
{
// Send a r e q u e s t f o r a new s u b s c r i p t i o n t o t h e s e r v e r :
s e r v e r . n e w S u b s c r i p t i o n ( c u r r e n t u s e r , newcontact )
}
// [SERVER] R e c e i v i n g n o t i f i c a t i o n about new s u b s c r i p t i o n
function n e w S u b s c r i p t i o n ( u s e r , c o n t a c t )
{
i f c o n t a c t . hasAccepted ( u s e r )
// S e t s t h e s u b s c r i p t i o n s t a t e f o r both p a r t i e s and
// add ’ u s e r ’ t o ’ c o n t a c t ’ s r o s t e r l i s t :
s e t S u b s c r i p t i o n S t a t e ( c o n t a c t , u s e r , BOTH)
s e t S u b s c r i p t i o n S t a t e ( u s e r , c o n t a c t , BOTH)
addToRoster ( c o n t a c t , u s e r )
e l s e i f c o n t a c t . hasDenied ( u s e r )
// Don ’ t make t h e u s e r ask t h e c o n t a c t f o r p e r m i s s i o n
// any more :
s e t A s k F o r A c c e p t a n c e ( u s e r , c o n t a c t , FALSE)
else
// As l o n g a s t h e c o n t a c t i s u n d e c e i d e d o r has r e f u s e d ,
// we u s e NONE. However , u s e r has c o n t a c t on h i s r o s t e r
// l i s t
s e t S u b s c r i p t i o n S t a t e ( u s e r , c o n t a c t , NONE)
addToRoster ( u s e r , c o n t a c t )
// Ask User 2 ( c o n t a c t ) t o a c c e p t s y m m e t r i c a l s u b s c r i p t i o n
// t o User 1
as kF or Acc ep ta nce ( c o n t a c t )
}
// [ CLIENT ] User 2 ( c u r r e n t u s e r ) r e c e i v e s s u b s c r i p t i o n
// r e q u e s t from User 1 ( c o n t a c t )
function o n S u b s c r i p t i o n R e q u e s t E v e n t ( c o n t a c t )
{
// Show GUI a s k i n g f o r a c c e p t a n c e
i f accepted
// User 2 a c c e p t e d a s y m m e t r i c a l s u b s c r i p t i o n t o User 1
server . newSubscription ( currentuser , contact )
}
// [ CLIENT ] User 1 r e c e i v e s updated
function onRosterUpdateEvent ( )
{
redrawRoster ( )
}
When a user wants to remove a subscriber from his roster list, we must not
only enforce the principle of minimum asymmetry, but also retain privacy for
the user. In other words, the removal has to be done in a discrete way. Pseudo
code showing how this is handled in the system, can be seen in Listing 1.2.
The user’s client calls the deleteSubscription()-method on the server, which
removes the specified subscriber from the user’s roster list. Note that the user
is not removed from the subscriber’s roster list. Instead the removed contact’s
subscription state to the user is set to None on the server. This will result in the
user to always appear offline to the contact.
By applying these methods to the application, we achieve minimum asym-
metry both with respect to presence information and location information.
Listing 1.2. Implementation Pseudo Code (Remove a Friend)
// [ CLIENT ] : User 1 wants t o d e l e t e User 2 ( c o n t a c t )
function d e l e t e S u b s c r i p t i o n ( c o n t a c t )
{
server . deleteSubscription ( currentuser , contact )
}
// [SERVER ] : User 1 wants t o d e l e t e User 2 ( c o n t a c t )
function d e l e t e S u b s c r i p t i o n ( u s e r , c o n t a c t )
{
// Remove c o n t a c t from u s e r ’ s r o s t e r :
removeFromRoster ( u s e r , c o n t a c t )
// S e t u s e r ’ s s u b s c r i p t i o n s t a t e t o NONE i n c o n t a c t ’ s
// r o s t e r . Contact w i l l s e e u s e r a s o f f l i n e .
s e t S u b s c r i p t i o n S t a t e ( c o n t a c t , u s e r , NONE)
// Send a new r o s t e r t o u s e r w i t h o u t c o n t a c t i n i t .
sendUpdatedRoster ( u s e r )
}
4 Summary and Further work
The work presented here has demonstrated how the principle of minimum asym-
metry can be applied as a means of maintaining privacy in a mobile social ap-
plication. The service uses the XMPP protocol to exchange messages between
different users. However, the XMPP standard does not conform to the principle
of minimum asymmetry. By using a subset of the standard, we show how we can
enforce mutual subscriptions and thus minimum asymmetry.
A similar system has been developed for the Wi-Fi environment in Wireless
Trondheim [9]. This system has primarily been developed to investigate any
behavioural changes in the users when they know the location of their peers and
they know that their peers know their location 5 . We expect to conduct similar
experiments on a larger scale, using the implemented system described in this
paper. The experiment will be conducted using the GSM mobile network in
Norway.
Acknowledgements
Parts of this work has been supported by Accenture Innovation Lab Norway. We
would like to extend our thanks to Per Anton Gransæther for his assistance.
References
1. Jones, Q., Grandhi, S.A.: P3 systems: Putting the place back into social networks.
IEEE Internet Computing 9 (2005) 38–46
2. Langheinrich, M.: Privacy by design – principles of privacy-aware ubiquitous sys-
tems. In Abowd, G.D., Brumitt, B., Shafer, S.A., eds.: Proceedings of the Third
International Conference on Ubiquitous Computing (UbiComp 2001). Number 2201
in Lecture Notes in Computer Science, Springer Verlag (2001) 273–291
3. Bellotti, V., Sellen, A.: Design for privacy in ubiquitous environments. In Michelis,
G.D., Simone, C., Schmidt, K., eds.: Proceeding of the Third European Confer-
ence on Computer-Supported Cooperative Work (ECSCW ’93), Kluwer Academic
Publishers (1993) 77–92
4. Jiang, X., Hong, J.I., Landay, J.A.: Approximate information flows: Socially-based
modeling of privacy in ubiquitous computing. In Borriello, G., Holmquist, L.E.,
eds.: Proceedings of the 4th International Conference on Ubiquitous Computing
(UbiComp 2002). Volume 2498 of Lecture Notes in Computer Science., Springer
Verlag (2002) 176–193
5. Raento, M., Oulasvirta, A.: Privacy management for social awareness applications.
In Floréen, P., Lindén, G., Niklander, T., Raatikaine, K., eds.: Workshop on Context
Awareness for Proactive Systems (CAPS 2005), HIIY Publications (2005) 105–114
6. Lederer, S., Hong, I., Dey, K., Landay, A.: Personal privacy through understanding
and action: five pitfalls for designers. Personal and Ubiquitous Computing 8 (2004)
440–454
7. Saint-Andre, P.: Extensible Messaging and Presence Protocol (XMPP): Core. RFC
3920 (2004)
8. Saint-Andre, P.: Extensible Messaging and Presence Protocol (XMPP): Instant
Messaging and Presence. RFC 3921 (2004)
9. Andresen, S., Krogstie, J., Jelle, T.: Lab and research activities in wireless trond-
heim. In: Proceedings of IEEE International Symposium on Wireless Communica-
tion Systems, IEEE Computer Society (2007) 385–389
5
This research is currently being prepared for publication