Databases Reference
In-Depth Information
3 Privacy protection through anonymity
As we illustrated in Section 2, a privacy threat occurs when an attacker is able
to obtain a user's sensitive association. When a LBS requires each request to
contain explicit full identification of the user, the sensitive association can
only be protected by avoiding the explicit and implicit release of the second
component of the association:
private information
. However, most LBS either
do not require full identification or they admit the use of pseudonyms for
billing and/or personalization. In these cases, preserving the anonymity of
the issuer is a successful technique to avoid releasing a sensitive association,
while still providing precise service invocation parameters.
Note that the anonymity problem in LBS has at least two distinguishing
aspects with respect to the analogous problem in the release of data from
databases [17]. First, the fact that each request contains data about the lo-
cation of the user at the time of request, introduces spatio-temporal data as
a new kind of potential
quasi-identifier
, and it is well known that the effec-
tive management of this kind of data requires specific techniques. Second,
anonymity in databases has been studied considering a one-time publication
of a given set of records, while the problem in LBS is inherently dynamic: the
position of users is continuously changing and this has to be taken into ac-
count each time a request has to be anonymized. Moreover, inferencing based
on previously anonymized requests can be used by the attacker.
Anonymity as a LBS privacy protection technique has been only recently
investigated. Several research contributions (among which [9, 16, 11, 3]) have
proposed techniques that aim at enforcing the issuer of a request to be
anony-
mous
, in the sense that an attacker, that can acquire the requests, must not
be able to associate each request to its issuer with likelihood greater than a
threshold value. Unfortunately, a clear understanding of which techniques can
be proved to be
safe
under which conditions is still missing, mostly because
of the lack of an underlying formal model.
3.1 A formal model for anonymity in LBS
In this section we provide a formal model to define attack and defense tech-
niques. The set
R
contains all the possible
original
requests issued by the
users to the LTS and all the possible
generalized
requests that the LTS would
forward to the SP. We also indicate with
I
the set of all users' identities and
with
issuer
(
r
) the identity of the user that issued the request
r
.A
general-
ization
function is used by the LTS to transform an original request into a
generalized one to be forwarded to the SP.
Definition 1.
Given a set R of requests, we say that g
:
R
→
R is a
general-
ization function
.
The purpose of a generalization function is to render requests
safe
from
privacy threats. We claim that the safety of a generalization function can only
