A System for Locating Mobile Terminals with Tunable Privacy

Journal of Theoretical and Applied Electronic Commerce Research, Aug 2007 by Bessler, Sandford

3.1 System extensions to support watcher applications

Until now, we have described how a user can achieve tunable location privacy through the management of own defined zones, in interaction to other users or services.

In some scenarios (see Fig. 1b) the "zones" are however defined by the watcher and have to be "pushed" to the presentity, assumed the latter trusts the watcher. Such use cases arise for example when an employer needs to localize his service-persons, or when a user subscribes in advance to an emergency and information service covering a certain geographical region.

The main requirements for extending the system so it can support the applications above are:

* to be able to inter-operate with the terminal-to-terminal mode,

* to provide the application with a flexible tool to define zones,

* to maintain the control of the presentity over the localization,

* to provide a single interface that ca be used by all applications.

To illustrate the design spectrum of the system, we present two alternatives:

1. The presentity user registers at the application, so the latter can contact her. The presentity can login in the application anytime, select the location zones and downloads them (as GML descriptions). A zone viewer that allows the presentity to verify the locations on a map is available. The application subscribes to the locations checked out by the presentity sending the names in the SUBSCRIBE message as in the former case. This alternative has the disadvantage that it requires the presentity to initiate the dialog and download the zone data. It can however manage the downloaded zones as described in the terminal to terminal case.

2. The presentity registers at the application and basically allows the application to "push" zone information to it. The application uses a third party GIS server to find zones corresponding to public points of interest or defines zones by postal address and name-ID. The name ID is sent in the SUBSCRIBE together with the URI to access the GIS server. The presentity needs to go to the GIS-server, fetch the GML code and eventually check the location visually. The GIS server insures the integrity of the zone information in the location filter. The geo server can be used by many applications, but stores application specific data (zones). The interactions are described in more detail in [7] and are sketched Figure 4 below:

According to the second alternative, the user may revoke a subscription anytime or remove zones like in the terminal to terminal case.

3.2 System extensions to support non-trusted applications

A whole class of services related to m-advertising [12] need to push messages to users located in proximity to shops. We cannot directly use the system above because any query or subscription message initiated by the service needs the address of the mobile terminal, thus making the privacy obsolete and opening the way to spam and tracking threats. The basic scenario corresponds to Fig. 1c. To solve this problem we propose to extend the system as shown in Fig. 5. We can identify now three actors: the mobile user, the non-trusted applications (e.g. shops) and a set of trusted services (advertisement, location, messaging) that could be hosted by the network operator. The advertisement service mediates between shops that publish messages associated to certain location zones and between the consumers that first have to register in order to obtain the advertisement service. This procedure is consistent with the permission marketing principle adopted in m-advertising [5]. In the same way the advertisement service hides the identity of mobile users (represented by contact addresses) from the shops.