<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>POIsafe : a Privacy-Conscious System for Retrieval of Points of Interest</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Daniele Riboni</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Linda Pareschi</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Claudio Bettini</string-name>
          <email>bettinig@dico.unimi.it</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Universita degli Studi di Milano, DICo</institution>
          ,
          <addr-line>Milan</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <fpage>17</fpage>
      <lpage>20</lpage>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Services for retrieval of points of interest (POIs) are becoming increasingly
popular due to the widespread di usion of GPS-enabled mobile devices having access
to fast wireless networks. We have developed a context-aware service to share,
manage, and retrieve geo-referenced resource descriptions enriched with
multimedia content [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. The access to such services is prone to potentially serious
privacy issues, since requests include sensitive information or can lead to the
disclosure of sensitive information, and they are often handled by untrusted
parties, or sent through insecure channels. Context data, including user location, is
in some cases sensitive information that users prefer not to be associated with
their identity. In other cases, the interest for speci c resources is considered
sensitive and the issuer of such a request uses a pseudonym not to be identi ed;
however, context data present in the same request or in a sequence of requests
may be used by an adversary to re-identify the issuer. We are not aware of any
context-aware service for retrieval of POIs with an e ective and comprehensive
privacy protection mechanism, and we believe this is a challenging research goal.
In this paper, we focus on one particular kind of context data, location, but we
plan to extend our techniques to tackle the general problem illustrated above.
      </p>
      <p>
        Di erent techniques have been proposed for protecting against the
disclosure of location information in location-based services (LBS). Cryptographic
approaches inspired by Private Information Retrieval (e.g., [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]) provide very
strong guarantees in terms of privacy; however, they determine a relevant
overhead in network and power consumption and service response time, especially
when applied to services that consider a wide set of context data.
Obfuscationbased techniques are based on a perturbation of the user's location. In techniques
based on generalization the exact location is enlarged to a region; in other cases,
a fake user's location is communicated instead of the real one. In particular, the
latter approach is adopted by SpaceTwist [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] to enforce location privacy while
guaranteeing that k-nearest neighbor (kNN) queries are correctly answered even
if the user provides a fake location, at the cost of computation and
communication overhead. Indeed, according to SpaceTwist, the client issues a sequence
of requests from the same fake location asking for more close-by POIs until it
is sure that those provided by the service include the kNN set corresponding
to its real location. Based on the request-response sequence, an adversary can
only identify an area (called twisted space) from which the requests may have
been sent. More recently, a technique (derived from SpaceTwist) to couple
location privacy with identity anonymity, named AnonTwist [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], has been proposed.
Given a density map to estimate the number of people in a given area,
AnonTwist provides a probabilistic guarantee that, even if an adversary has access to
presence information, the twisted space contains at least N individuals; hence,
the request issuer is indistinguishable among at least N individuals. However,
both SpaceTwist and AnonTwist rely on the assumption that the function that
generates the fake location is unknown to the adversary.
      </p>
      <p>In this paper we take into account the realistic case in which the function that
generates the fake location is known to the adversary. In Section 2 we illustrate
a speci c technique to protect privacy under this assumption. In Section 3 we
present POIsafe, an extension of our system for POIs retrieval to enforce location
privacy and identity anonymity as a rst step towards a comprehensive solution
considering other context data. Section 4 concludes the paper.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Enforcing privacy in POIsafe</title>
      <p>
        Even if we are investigating alternative solutions, our current approach is
inspired by AnonTwist [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. However, di erently from AnonTwist and SpaceTwist,
our proposed algorithm assumes that the function for generating fake locations
could be known to the adversary. Under this assumption, by observing the fake
location, the adversary may reconstruct the possible area A from which it
originated. Moreover, based on the request-response sequence, the adversary is able
to understand that the area from which the request originated corresponds to
the intersection I between the twisted space and area A. Hence, the goal of our
technique is to ensure that area I is greater than a speci ed threshold, and that
it includes at least N potential issuers.
      </p>
      <p>In particular, the maximum radius r of perturbation (e.g., 1 Km) and the
minimum number of potential issuers N are chosen according to the user's
preferences about privacy and quality of service (QoS). Then, before issuing a request,
a random distance ranging from 0 to r is chosen, and a random point having
that distance from the real user's location is chosen as the fake location. Note
that with this technique, A is the area contained within the circle having center
in the fake location, and radius r. Then, the client incrementally asks for nearest
POIs until i) the exact kNN set is retrieved, ii) area I is greater than the chosen
threshold, and iii) I contains at least N users according to the density map.</p>
      <p>In general, the farther is the fake location from the real one, the higher is
the user's privacy. However, large perturbations of the real location determine
poor QoS. Indeed, even if the service guarantees to correctly answer the user's
query, a very high number of POIs may be communicated to the client before
obtaining the correct kNN set, determining an increase in communication and
computational costs, and response time. With respect to usability, users can be
provided with an intuitive interface to set their preferences; i.e., a single slider
with response time on the left-hand side and privacy on the right-hand side.
The value of the slider in uences the value of radius r and threshold N . Before
submitting a request, density information is used to control if the value of r is
adequate to provide a su cient level of anonymity with high probability (e.g.,
according to the density map the corresponding area includes a number of users
that doubles threshold N ). In this case, a green signal appears; in the other case,
a red one is used. Note that the red signal does not mean that the technique will
necessarily fail to preserve privacy, but only that anonymity might be at risk.
3</p>
    </sec>
    <sec id="sec-3">
      <title>System architecture</title>
      <p>
        POIsafe is based on a peer-to-peer network of poisafe servers, which are in
charge of managing POIs, and of searching POIs in the peer-to-peer network
on the basis of the user's context and explicit search keywords. The mechanism
of search in the peer-to-peer network has been presented in detail in [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. An
overview of the POIsafe network is shown in Figure 1(a).
      </p>
      <p>Users can access the POIsafe network from a wide range of client
systems, which provide an interface for the user to browse her own POIs hierarchy,
reorganize the hierarchy, add new POIs, search shared POIs in the peer-to-peer
network, and set their preferences, including those regarding privacy. Before
issuing a request, each client system retrieves context information useful for
service adaptation. This information can be retrieved either locally or from an
external context provider. Perturbation of location information and requests
for POIs are executed as illustrated in Section 2. The density map is retrieved
from a trusted density map server. In the previous version of POIsafe, ranking of
POIs was performed only at the server side. However, since in the new version a
fake user's location is communicated to the server, returned POIs are re-ranked
at the client side considering the exact user's location. Moreover, an external
map server is queried by the client system for obtaining maps showing the
position of returned POIs and information for navigation support.</p>
      <p>
        The poisafe server has been developed in Java, and implements the
algorithms for POIs scoring and distributed search presented in [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], the modi ed
AnonTwist algorithm, as well as various facilities for managing and searching
POIs. The architecture adopts Web services for client/server and server/server
communication. At the time of writing we have developed client systems for
laptops and smartphones. In particular, we have developed a novel Android client
(see Figure 1(b)), which takes advantage of the integration with Google Maps.
4
      </p>
    </sec>
    <sec id="sec-4">
      <title>Conclusions and future work</title>
      <p>
        In this paper we presented the extension of an existing system for context-aware
management and retrieval of points of interest. The extension is a rst step
towards a comprehensive privacy solution for this kind of services. In particular,
future work includes a thorough investigation of the formal properties of the
proposed algorithm. Several research issues remain open. In particular, we point
out that the proposed technique may be ine ective if an adversary can observe
histories of requests issued by users in di erent time granules. Indeed, as shown
in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the frequency of a service parameter included in requests, matched with
the presence of candidate issuers, can be exploited to associate a given user with
that service parameter. The integration of techniques to protect against these
kinds of attacks will be the subject of future investigation.
      </p>
    </sec>
    <sec id="sec-5">
      <title>Acknowledgments References</title>
      <p>The authors would like to thank Song Wang and X. Sean Wang for providing a
working implementation of the AnonTwist algorithm.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>C.</given-names>
            <surname>Bettini</surname>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Riboni</surname>
          </string-name>
          .
          <article-title>Context-aware Web Services for Distributed Retrieval of Points of Interest</article-title>
          .
          <source>In Proc. of the 2nd International Conference on Internet and Web Applications and Services</source>
          , page
          <volume>36</volume>
          {
          <fpage>40</fpage>
          . IEEE Computer Society,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>G.</given-names>
            <surname>Ghinita</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Kalnis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Khoshgozaran</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Shahabi</surname>
          </string-name>
          , and
          <string-name>
            <given-names>K.-L.</given-names>
            <surname>Tan</surname>
          </string-name>
          .
          <article-title>Private Queries in Location Based Services: Anonymizers are Not Necessary</article-title>
          .
          <source>In Proc. of SIGMOD</source>
          <year>2008</year>
          , pages
          <fpage>121</fpage>
          {
          <fpage>132</fpage>
          . ACM,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>D.</given-names>
            <surname>Riboni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Pareschi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Bettini</surname>
          </string-name>
          , and
          <string-name>
            <given-names>S.</given-names>
            <surname>Jajodia</surname>
          </string-name>
          .
          <article-title>Preserving Anonymity of Recurrent Location-based Queries</article-title>
          .
          <source>In Proc. of the 16th International Symposium on Temporal Representation and Reasoning. IEEE Computer Society</source>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>S.</given-names>
            <surname>Wang</surname>
          </string-name>
          and
          <string-name>
            <given-names>X.S.</given-names>
            <surname>Wang. AnonTwist: Nearest Neighbor</surname>
          </string-name>
          <article-title>Querying with Both Location Privacy and k-Anonymity for Mobile Users</article-title>
          .
          <source>In Proc. of First International Workshop on Mobile Urban Sensing</source>
          , pages
          <volume>443</volume>
          {
          <fpage>448</fpage>
          . IEEE Computer Society,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>M. L. Yiu</surname>
            ,
            <given-names>C. S.</given-names>
          </string-name>
          <string-name>
            <surname>Jensen</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <string-name>
            <surname>Huang</surname>
            , and
            <given-names>H.</given-names>
          </string-name>
          <string-name>
            <surname>Lu</surname>
          </string-name>
          .
          <article-title>SpaceTwist: Managing the Tradeo s among Location Privacy, Query Performance, and Query Accuracy in Mobile Services</article-title>
          .
          <source>In Proc. of ICDE</source>
          <year>2008</year>
          , pages
          <fpage>366</fpage>
          {
          <fpage>375</fpage>
          . IEEE Computer Society,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>