LP-Cach

e: Privacy-aware Cache Model for Location-based Apps

Asma Patel and Esther Palomar

School of Computing and Digital Technology, Birmingham City University, Birmingham, U.K.

Keywords:

Location Privacy, Location-based Services, Smartphones, Caching, Location-based Applications.

Abstract:

The daily use of smartphones along with third-party apps, which involve location data to be continuously

collected, shared and used, have become a signiﬁcant privacy concern. Besides, taking advantage of the rapid

growth of wireless access points, the capability of these location-based services to track users’ lives, even

sometimes with their consent, creates an urgent need for the development of more user-friendly and socially-

accepted approaches to location privacy preservation. In this paper, we introduce a novel privacy-aware model

for location-based apps to overcome the shortcomings related to user privacy during the location calculation

process. By making the user device play a bigger role in the process, our model prevents users from relying

on service providers’ trustworthiness. The model applies a cache-based technique to determine the position

of client devices by means of wireless access points and achieve data minimisation in the current process.

The model also establishes new personalised permission settings for the users while sharing their location

information. We outline possible implementation of the proposal, and preliminary ﬁndings of the work-in-

progress evaluation on the wireless data feasibility and usability that demonstrate deployment viability.

1 INTRODUCTION

The explosive growth of context-aware mobile apps

has leveraged tremendous opportunities for a whole

new class of Location-Based Services (LBS) (Pontes

et al., 2012). Geo-marketing and geo-social net-

working, location-based games, monitoring, assisted

eHealth, and energy consumption 3D maps represent

a small subset of the third-party apps nowadays avail-

able as LBS and can certainly pose a serious threat to

the users’ privacy. (Muslukhov et al., 2012; Shklovski

et al., 2014).

Currently, approaches to privacy settings of user

location on smartphones are based on a binary pro-

cess

. Users are forced to rely on third party ser-

vice providers that in many cases continuously col-

lect, use and share their location data, and in some

cases even prompt the user to give away their posi-

tion on page load (Almuhimedi et al., 2015; Mus-

lukhov et al., 2012; Felt et al., 2012; Shklovski et al.,

Data protection directives and acts (European Commis-

sion, 2016; IETF, 2016) across the globe state that personal

data should not be disclosed or shared with third parties

without consent from subject(s). Such a consent is typi-

cally obtained by mandatory acceptance of the conditions

mentioned in the End User License Agreement (EULA), or

through opt-out possibilities and other regulations(Michael

and Clarke, 2013).

2014). Moreover, both academia and industry agree

on the urgent need of adopting a Privacy-by-Design

(PbD) approach for the development of more user-

friendly and socially-accepted solutions to location

privacy preservation on their mobile products and ser-

vices (Cranor and Sadeh, 2013).

To encounter these challenges, we introduce the

model called Location Privacy Cach

e (LP-Cach

e).

LP-Cach

e envisions beyond the simple grant/deny ac-

cess method and provides the user with advanced

mechanisms to decide the extent of disclosing lo-

cation data with service providers. Several caching

based solutions (Zhu et al., 2013; Amini et al., 2011;

Niu et al., 2015) have been proposed to minimise the

risk of major location privacy threats, but lacking of

deployment feasibility. They rely on unrealistic as-

sumptions such as vast cache data storage require-

ments, or on the app developers modifying the code

to incorporate their cached databases. LP-Cach

e in-

corporates caching technique to determine users’ ge-

ographical location in a privacy preserving manner,

and with minimum cache storage requirements. The

main contributions in this paper are:

• Detailed analysis of the current location computa-

tion process deployed in smartphones when run-

ning location-based apps.

• Deﬁnition of LP-Cach

e and its main implementa-

Patel, A. and Palomar, E.

LP-Cache: Privacy-aware Cache Model for Location-based Apps.

DOI: 10.5220/0005970101830194

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 183-194

ISBN: 978-989-758-196-0

183

tion requirements. The main identiﬁed beneﬁts of

LP-Cach

e are twofold:

– Provides enhanced personalised location pri-

vacy settings that control every installed app

distinctly and protect sharing of user’s private

location with third-party app providers.

– Minimises the amount of wireless access point

data that is being shared within the current ar-

chitecture for computing the device’s location

by means of minimum on-device caching.

• Evaluation of wireless access point data availabil-

ity and consistency, and of the implementation re-

quirements to demonstrate that LP-Cach

e is feasi-

ble without modifying installed apps.

The rest of the paper is organized as follows. Sec-

tion 2 outlines the current location computation pro-

cess and its evaluation. Section 3 reviews the related

work. Section 4 presents the design and architecture

of LP-Cach

e, and Section 5 fully elaborates on design

decisions and possible implementation. We evaluate

the feasibility and usability requirements in Section 6.

Finally, Section 7 concludes and sets future research

plans.

2 CURRENT LOCATION

COMPUTATION PROCESS

In this section, we describe roles and processes

involved in the current architecture for computing

user’s device location.

2.1 Current Architecture

The current location computation architecture to use

location-based apps on smartphones comprises four

main entities: 1. Smartphones with installed apps,

2. App Provider, 3. Network Infrastructure, and 4.

Location Provider. This architecture mainly relies

on third party location providers, e.g., Google Loca-

tion Service (Google Location Service, 2016), Sky-

hook (Skyhook, 2016), and Navizon (Navizon, 2016).

The location provider represents the central database,

which maps the received signatures of nearby wire-

less access points to the geo-coordinates, i.e., lati-

tude and longitude, so handling every geo-location

request. Therefore, the location provider has con-

stant access to the user’s location as well as to the

trajectory data. To respond to any location request,

the location provider maintains a database of sur-

rounding network infrastructure, including WiFi Ac-

cess Points (APs), cellular-towers, and IP addresses,

which must be mapped to their exact geographical co-

ordinates. Compared to GPS and cell-tower based po-

sitioning, WiFi Positioning Systems (WPS) is nowa-

days considered as a very accurate method for loca-

tion calculation (Skyhook, 2016). Location providers

rather use enhanced WPS than GPS, primarily due

to current smart-mobile devices beneﬁt from built-

in WiFi clients that perform faster than most expen-

sive GPS receivers. This enables the service provider

to get user’s precise location at all times and, as a

result, more effective privacy preservation measures

are needed in the current process to mitigate privacy

threats.

WiFi APs continuously announce their existence

in the way of network frames/beacons and transmit

their Service Set Identiﬁer (SSID) and Basic Ser-

vice Set Identiﬁer (BSSID)/MAC addresses. Location

providers use these WiFi APs identifers to create net-

work signatures and map them with geo-coordinates,

also called geolocation. IEEE 802.11 states two stan-

dardised ways to collect beacons from WiFi APs: 1.

Active scanning, and 2. Passive scanning. Location

providers are capable of deploying systems with ei-

ther active scanning, passive scanning, or both to-

gether. Location providers use three different ways

to collect geo-location of WiFi APs:

1. Statically- They collect WiFi beacons by the so

called wardiving process. Basically, they map the

equipped vehicle’s exact geo-coordinates along

with the signal strength of the captured beacons

from surrounded APs.

2. Dynamically- They can collect data from WiFi

APs automatically once the user device uses lo-

cation services, e.g. Maps and Navigation appli-

cations. The user device as conﬁgured to be ge-

olocated acquires unique identiﬁers from the sur-

rounding WiFi APs, even if the network is en-

crypted, and then sends it over to the location

provider in order to perform geolocation calcula-

tion. The collected information is utilised to build

and update the database autonomously, for exam-

ple, by applying crowdsourcing (Zhuang et al.,

2015).

3. User input- They encourage users to manually

input the WiFi APs’ information, i.e., BSSID

and the geo-coordinates, into their databases, e.g.,

Skyhook

to register WiFi APs.

Submit a Wi-Fi Access Point. See http://www.skyhook

wireless.com/submit-access-point (last access in March.

2016).

SECRYPT 2016 - International Conference on Security and Cryptography

184

2.2 Evaluation of Current Location

Computation Process

We conducted a series of experiments on differ-

ent mobile devices installed with Android, Windows

Phone, and iOS operating systems to categorise the

data ﬂow in the current location computation pro-

cess. With the assistance of sniffers, such as Wire-

shark (Wireshark, 2016) and tPacketCapture (tPack-

etcapture, 2016), we captured and analysed sequence

and location data transmission when using location-

based apps, e.g., Navigation and Friend Finder.

Observation. These experiments were designed to

understand whether there is any difference on the lo-

cation calculation process on each of these three mo-

bile operating systems/ platforms. Based on the re-

sults, all of them display common patterns of location

data retrieval. The user device collects the unique

identiﬁers from the surrounding network along with

GPS data, and sends it to the location provider to get

the exact device location. Figure 1 shows the structure

of the WiFi and Cell-tower objects sent to the location

provider. Once calculation is performed, the loca-

tion provider sends to the device the precise location

in the way of a geo-location object containing geo-

coordinates. Figure 2 represents the structure of the

location object received from the location provider.

In short, the app developer over any mobile platform

can utilize this location object to get the user’s geo-

location with no need of focusing on the details of the

underlying location technology. In the following sec-

tion, we give the detailed description of the process

sequence.

Figure 1: Structure of WiFi AP object (left) and cell-tower

object(right) sent to the location provider.

Process Sequence. Figure 3 illustrates the sequence

of processes and messages involved in the current

location computation architecture. Note that, on a

Figure 2: Structure of the location object received from the

location provider.

smartphone, location sharing service settings must be

‘ON’ while using any location-based app. If the lo-

cation sharing is ‘OFF’, then the device prompts for

changing the setting from ‘OFF’ to ‘ON’; otherwise,

user cannot use the service.

3 RELATED WORK

Existing approaches to location privacy preservation

can be classiﬁed into three categories: 1. Mobile Plat-

form, 2. Location Query, and 3. Privacy-aware Net-

work Communication.

3.1 Mobile Platform

A few studies have proposed static and dynamic

methods to detect privacy leaks in mobile platforms.

The former method statistically analyse apps by creat-

ing permission mapping, generating call graphs, and

data ﬂow analysis to report privacy leaks for further

auditing, e.g, AndroidLeaks (Gibler et al., 2012) and

PiOS (Egele et al., 2011) for Android and Apple iOS,

respectively. The latter involves modiﬁcation of ex-

isting mobile platforms, such as TaintDroid (Enck

et al., 2014) and MockDroid (Beresford et al., 2011).

TaintDroid adds taint tracking information to sensi-

tive sources calls from apps, and it tracks location data

ﬂow as it generated through applications during exe-

cution. Whereas, MockDroid relies on instrumenting

Android’s manifest permission mechanism to mock

sensitive data from OS resource, including location

data, which can affect apps’ usability and functional-

ity. LP-Cach

e not only monitors the location sources

but also modify, if required, the generated location

data based on deﬁned user permissions. Fawaz and

Shin (Fawaz and Shin, 2014) apply indistinguisha-

bility into the advertising and analytics libraries as

well as on installed apps as location privacy preser-

vation mechanism; however, it does not give control

on the amount of WiFi and location data that is be-

ing shared with the location provider, indistinguisha-

bility technique increases computational overhead on

smartphones.

LP-Cache: Privacy-aware Cache Model for Location-based Apps

185

Location-based

App

Network and Communication

Infrasturcture

Location ProviderMobile Platform

Return Location Object()

{i.e., Device's Lat. & Long.}

3: Send Session Data ()

{sent info: Wifi AP Object, Cell-tower Object, and GPS Data}

Location-based

App Provider

Return Session Data ()

1: Request Location Object()

{i.e., Device's Lat. & Long.}

Return LBS Query (Response)

Return (Location Object )

4: Compute Device Exact Location()

{i.e., Perform Wifi Triangulation,

Cell-tower Triangulation,

GPS Coordinates Mapping}

5: Request LBS Query() {sent info: Received Location Object, and Query}

2: Request Session Data()

{i.e., Wifi APs , Cell-towers,

and GPS Data}

Figure 3: Sequence diagram of current location computation process.

3.2 Location Query

Apps share location information with the provider

in the form of LBS queries. The transmission of

such queries to the location server may allow at-

tackers to gain access to user location data. Pri-

vacy Enhancing Techniques (PET) like k-anonymity,

dummy locations, region cloaking, location perturba-

tion and obfuscation, and mix-zone pseudonyms have

been applied to different architectures for location

query formation and privacy preservation from LBS

providers (Patel and Palomar, 2014; Wernke et al.,

2014; Khoshgozaran et al., 2011). Most of these tech-

niques rely on theoretical assumptions - like trusted

infrastructure to provide the privacy protection, re-

quiring a group of similar app users to be at the same

time and same place. The main issue with PETs and

cryptographic schemes is that it relies entirely on the

data collection servers to comply with location pri-

vacy.

Caching. Several authors have used caching

scheme along with PETs to build privacy preserving

location based queries. MobiCach

e (Zhu et al.,

2013) applies k-anonymity for caching location

based queries. Similarly, Niu et al. (Niu et al.,

2015) attempt to improve k-anonymity based caching

by adding dummy locations. Both proposals re-

quire trusted infrastructure to maintain privacy.

Cach

e (Amini et al., 2011) maintains a local cach

within the device to reuse the data types available

from applications in future location based queries;

however, storing entire LBS query data increases

the cache storage requirements. Besides, Cach

also requires app developer to modify the way app

access location data. Whereas, LP-Cach

e caches

the network ﬁngerprints and geo-coordinates, which

reduces the storage overhead drastically; it considers

installed apps as black box, and therefore, does not

require app developer to modify the code, it works

as a middleware between the app and the mobile

platform. All these cache-based systems either intent

to generalise or obfuscate the LBS query or minimise

the number of queries sent to the app providers,

but they do not provide privacy from WiFi content

distributors. Besides, mobile devices not only send

vast amounts of location data to app providers but

also to location providers creating different location

privacy shortcomings (Almuhimedi et al., 2015;

Shklovski et al., 2014). In this regard, limited work

has been published on privacy preservation from

the location provider perspective (Damiani, 2011;

Doty and Wilde, 2010). Damiani (2011) proposes a

theoretical approach for privacy-aware geolocation-

based web services to encourage further research to

minimise the amount of location data being shared

with the location provider. This is mainly due to

that the location provider is considered as the only

source to get the user location when developing any

location-based app. In LP-Cach

e, we minimise the

process of wireless AP data collection by the WiFi

content distributors or location providers, and we

control information disclosure within the generated

LBS query (e.g., points of interests (POIs) and nearest

neighbor) since it will be sent to the third-party app

provider.

SECRYPT 2016 - International Conference on Security and Cryptography

186

3.3 Privacy-aware Network

Communication

Besides location queries, device’s IP address can also

reveal user’s private locations. To this regard, anony-

mous communication protocols, e.g., Anonymizer

(Anonymizer, 2016) and TOR (TOR, 2016), deal with

anonymous service usage at the network layer while

communicating over Internet (i.e., the server cannot

infer user’s location via received device’s IP address

along with location query), and they are most promi-

nent and commonly used network layer solutions.

4 LP-CACH

E MODEL

In this section, we describe LP-Cach

e’s threat model,

design goals, architecture and main processes’ se-

quence diagram.

4.1 Threat Model

Apps deliberately collect user’s sensitive data, includ-

ing location and other sensitive information as part of

their operations. User tracking, identiﬁcation and pro-

ﬁling (i.e. personal habits, movement patterns, etc.)

are fundamental threats to location privacy (Felt et al.,

2012; Wernke et al., 2014). Furthermore, the current

direct link of smartphones to the location provider

and the continuous ﬂow of LBS queries that include

device’s exact geo-coordinates over network create a

serious risk to the protection of users’ sensitive infor-

mation, even more challenging, in the presence of a

malicious location provider and via advanced network

snifﬁng practices.

LP-Cach

e computes the exact location within user

device, without service provider’s involvement, and

trusts the device on the storage of sensitive data.

However, the user has still the option of giving con-

sent for app providers or location provider to access

their location. Mobile network providers might, how-

ever, collect user location data via cellular clients. It

is also excluded from our model the option of manu-

ally inserting the location data (e.g. street name, zip

code, post code) within LBS query.

4.2 LP-Cach

e Control Flow

Architecture

LP-Cach

e’s three main design goal are: 1) the third-

party app provider will not be able to infer the de-

vice’s exact location without getting uses’s consent;

2) the user can set distinct privacy preferences for

Network

Infrastructure

Smartphone

Location

Provider

Wifi-AP

Location-based App

Provider

Cell-tower

Private Location

Manager

Location

Receiver

Location Request

Rule Mapper

GPS

Permission Setter (UI)

Hardware

Cellular

GPS WiFi

LP-Caché

Platform

Apps

Caché

Request

Manager

Sensors

Platform Components

Location WiFi Data

Figure 4: LP-Cach

e architecture.

different apps and private places; and 3) the model

works independently without the need of modifying

the app’s code. Figure 4 depicts the block diagram

for LP-Cach

e architecture; its main components are:

Permission Setter is the user interface (UI), which

enables users to set and manage their private

places and apply improved personalised permis-

sions when running installed location-based apps.

Once received the user inputs, pre-set private lo-

cations are sent to the Private Location Manager

module, and permissions are sent to the Rule Map-

per Module.

Request Manager is responsible to intercept the

event of location access calls, and then lead the

app’s control ﬂow to the Private Location Man-

ager module. Besides, it will also be in control of

receiving the processed user location (i.e., could

be either anonymised or altered) from Rule Map-

per, and then delivering it to the app in order to

maintain every session’s control ﬂow.

Private Location Manager module’s main task is to

detect unique identifers of the surrounding WiFi

APs and compare them with the stored net-

work ﬁngerprints to determine whether the user is

within the set of private places. User inputs from

the Permission Setter will create network ﬁnger-

prints for known private locations, which are then

added or updated in the Cach

e database. More-

over, it maintains a binary ﬂag to detect private

places. In the case of a hit the location data is sent

to the Rule Mapper. Otherwise, the location is re-

ceived from the Location Receiver. Whenever the

Private Location Manager receives a new private

place request, the received location is mapped to

LP-Cache: Privacy-aware Cache Model for Location-based Apps

187

the detected network ﬁngerprint and stored in the

Cach

e database.

Rule Mapper dynamically collects and checks set

permissions from Permission Setter. Once the

representative location object is received from the

Private Location Manager, it applies the user per-

missions on the location co-ordinates, alters them

(if required), and outputs the processed location to

the Request Manager module. If the ﬂag is nega-

tive, then it forwards the exact location.

Cach

e is the established on-device cached database,

and it is routinely queried by the Private Loca-

tion Manager module, which can add, update and

delete the cached location data. The locations in

cach

e are those which are to be protected, and

they can also represent regions of space. Each en-

try is recorded along with a network ﬁngerprint

and geo-location that is acquired from the loca-

tion provider.

Location Receiver module receives a location object,

which includes the user device’s geo-coordinates

(as in Figure 2), from location providers and sends

it over to the Private Location Manager for fur-

ther processing.

4.3 Process Sequence

LP-Cach

e modiﬁes the current location resource han-

dling process, however, the involved entities (as in

Section 2) remain the same. Figure 5 illustrates the

sequence of processes and messages involved in LP-

Cach

1. At the event of app requesting the device location,

our service will intercept the request to get the lo-

cation from the cache database instead of sending

the request to the location provider.

2. Upon receiving the location request, our service

will scan the surrounding network infrastructure.

3. Using observed network frames our service will

execute as follows:

(a) Our service compares the collected beacons

with the stored network ﬁngerprints to re-

trieve corresponding stored representative loca-

tion coordinates.

(b) In the case of an unmatched entry on the

database, the LP-Cach

e prompts the user two

options either input the location using UI, or al-

low the query to be sent to location provider

that will calculate and send the current location

coordinates. Note that this will only occur if

the user has set the current location as private

but the geo-coordinates are not cached.

APs will be tracked within the local cache

database for future use.

4. User location coordinates can be altered based on

the privacy settings. LP-Cach

e provides three op-

tions for controlled information disclosure: (1)

Adjust Location Granularity, (2) Obfuscate Loca-

tion, and (3) No Change. Computed location is

populated in the location object and sent to the

app.

5. Once the app obtains the location object, it is

then used by the app provider to send the corre-

sponding reply to LBS query via the standard pro-

gramming interface/API (Android Developer Ref-

erence, 2016).

5 IMPLEMENTATION

REQUIREMENT

In the following sections, we describe LP-Cach

e’s

implementation requirements. LP-Cach

e orchestrates

a mobile platform based location protection ser-

vice to modify the location resource handling pro-

cess. For instrumenting the LP-Cach

e implementa-

tion, Android will be the best choice since it is open

source; however, it can also be implemented on other

permission-based mobile platforms.

5.1 Bootstrapping

LP-Cach

e aims to protect user’s private places. Ini-

tially, LP-Cach

e does not have enough informa-

tion to function, the two main required information

are private places’s network ﬁngerprints and geo-

coordinates. LP-Cach

e cannot collect network ﬁn-

gerprints and geo-cordinates for private places at run-

time, as by the time we have this information, other

installed apps will have access to it. Therefore, when

LP-Cach

e ﬁrst boots and before turning ‘ON’ location

sharing settings, user will have to do the initial setup,

which includes allow WiFi AP scanning, input geo-

cordinates and set privacy choices (see Section 5.4).

In 2013, Google presented a new service API (also

works on older Android versions) for location-based

apps that allows developers to use the new and ad-

vanced Location and Activity API, i.e., they changed

Location Manager to Fused Location Manager,

hence combining sensors, GPS, Wi-Fi, and cellular

data into a single API for location-based applications

(Hellman, 2013). As a result, separating data from

GPS PROVIDER and NETWORK PROVIDER is no longer

straight forward. LP-Cach

e addresses this issue by

SECRYPT 2016 - International Conference on Security and Cryptography

188

Location-based

App

Network and Communication

Infrasturcture

Location ProviderMobile Platform

Return(Location Object)

2: Request Session Data()

Location-based

App Provider

Return Session Data ()

Return (Location Object )

3.4: Update Caché Database (Network_Fingerprint, Location)

4: Apply Pre-set Permissions (Location Object)

1: Request Location Object()

{i.e., Device's Lat. & Long.}

5: Request LBS Query()

Return LBS Query (Response)

3.1: Retreive Device Location (Network_Fingerprint)

Check Cached Database

[else (Check with the user to update private location)]

[if (WiFi AP Beacon Frames = Cached Network Fingerprints)]

3.2: Request Device Location ()

3.3: Compute Device Location()

{i.e., Performs Wifi Triangulation,

Cell-tower Triangulation,

GPS Coordinates Mapping}

Figure 5: Sequence diagram of location computation process using proposed model

preventing app’s location request to reach the Fused

Location Manager that collects and sends the net-

work session data to the location provider. Instead,

the requested location is retrieved from the on-device

cache, and then, it is sent to the requesting app (with

privacy rules applied). Besides, geographic tool

can

be incorporated in the LP-Cache’s UI to get the corre-

sponding geo-cordinates. This will allow LP-Cach

to achieve effective privacy without affecting loca-

tion accuracy, at the same time, prevent from the non-

authorised sharing of device’s exact location and net-

work session data.

5.2 Mobile Platform

For performance evaluation, there are two possible

ways of implementing LP-Cach

e location protection

service. The ﬁrst requires modifying the app’s loca-

tion accessing interfaces and intercepting location up-

dates before they reach the app provider. Whereas, the

second option requires modifying the platform and

changing the location data before reaching the app.

App Code Modiﬁcation. This comprises unpack-

ing the app, rewriting the code to work according

LatLong is a geographic tool. See http://www.latlong.net/

(last access in March. 2016)

to the new rules, and then repackaging it again,

e.g.,(Jeon et al., 2012). However, app repackaging

changes the signature and stops future updates, and

therefore, affects its functionality. Another way to

modify app’s location accessing interfaces is through

the creation of an Android service and allowing apps

to register with it. Then, Apps can use the location

data provided by this service. This approach is easy

to implement but relies heavily on app developers to

modify their app’s code, which is highly infeasible

and unrealistic. Nonetheless, this approach can be

used as simulated testing environment for any devel-

oped service.

Platform Modiﬁcation. For the sake of experimen-

tation, we develop LP-Cach

e via platform modiﬁca-

tion. One of the main task is to add a system service,

where the class belongs to the location APIs; thus, it

is placed in the android.location package, which

detects private locations via APs and can also be used

by other components when calling context. In An-

droid, a context allows an app to interact with the OS

resources. Another task is to make LP-Cach

e com-

municate with location requesting apps. On Android

there are two methods to access user’s location: 1) Lo-

cation Manager Service (Old), and 2) Fused Location

Manager Service (New) that is a part of Google Play

LP-Cache: Privacy-aware Cache Model for Location-based Apps

189

Services. Both methods require the app to request a

callback function to get regular updates by registering

a location listener. The app receives a new location

object when a new location is available, the callback

function is invoked. Modifying these two Google ser-

vices is complicated, but there is a possibility to inter-

cept the location object before it reaches requesting

apps. We will add a static context ﬁeld to the loca-

tion class, which will be populated when the app is

invoked; this will enable us to know which app is cur-

rently requesting the location object, and also com-

municate with the OS (Fawaz and Shin, 2014). The

created location object will have reference to the re-

questing app’s context, and therefore, it can interact

with our external service.

5.3 On-device Cache Database Creation

LP-Cach

e requires ﬁxed wireless APs data (i.e.,

802.11) to create cached database of private locations.

Initially, we decided to focus on WPS since it infers

accurate user location. However, we can later include

other ﬁxed radio sources (e.g., cell-tower unique iden-

tiﬁers).

Network Fingerprinting. We can distinguish two

main types of WPS techniques to determine the po-

sition of client devices in respect to APs (Bell et al.,

2010): 1) Signal trilateration and 2) Fingerprinting.

The former undertakes trilateration of Received Sig-

nal Strength (RSS), Angle of Arrival (AoA), and Time

of Flight (ToF) from observed APs, and the later

involves mapping observed APs signatures with a

stored database. LP-Cach

e uses ﬁngerprinting to cre-

ate cached location database; however, ﬁngerprinting

performance is highly related to the number of APs.

Therefore, in Section 6 we have evaluated WiFi AP

availability and consistency. The detected network

management frames/beacons are mapped with the de-

vice’s representative geo-location to create a network

ﬁngerprint, which is then stored in the local cached

database, an example private location ﬁngerprint is

shown in Equation 1. Moreover, to reduce storage and

computation overhead, our model only caches net-

work ﬁngerprints of private places (e.g., home, work,

frequently visited places or particular stores), and it

relies on user input for initial pre-set up. The user

will have to select the option (via LP-Cach

e UI) to set

current location as private place p

, and then ﬁnger-

print will be recorded. Later, the private place will be

detected automatically with respect to observed bea-

cons.

= [n1], [n2], ..., [nx] → [l

] (1)

Algorithm 1: Location Calculation Algorithm.

Input: n

: Network Frames

Output: l

: Representative Location

1: n

= 0

2: read n

3: while n

6= null do

4: if n

= n

, ∀ i ∈ p then

5: (step 1) retrieve the corresponding l

6: add ﬂag f = (if private 1, else 0)

7: send l

8: else

9: (step 2) request l

from user or location

provider

10: set received l

to corresponding p

11: update c

12: send l

13: end if

14: end while

where p

represent i

private place IDs, n is the

scanned beacon, and l

is a representative location

for that private place. WiFi AP beacon frame n con-

sists of four attributes hSSID, BSSID/MAC address,

Signal-strength, and Timestampi. The private rep-

resentative location l

consists of a tuple hLattitude,

Longitude, and Accuracyi.

On-device Cache-based Location Calculation Al-

gorithm. The detailed steps of privacy-aware geo-

location calculation process are summarised in Algo-

rithm 1. The surrounded beacons n

are scanned and

compared to the list of private WiFi ﬁngerprints n

to detect private place p stored in cached database c.

Further, the representative l

is altered based on set

permissions (see Section 5.4).

5.4 Personalised Permissions for

Location Sharing

A general LBS query consists of different attributes,

e.g., LBS query {POI, Latitude and Longitude, User-

Info}, where included geo-coordinates estimate the

device’s geo-location. To satisfy one of the privacy

property called controlled information disclosure,

we designed enhanced permission mechanism to

control these geo-coordinates before it is sent to app

providers. When using LP-Cach

e, for every installed

app and set private place, the UI provides three

distinct privacy settings: (1) Adjust Location Gran-

ularity, (2) Obfuscate Location and, (3) No Change.

In the ﬁrst option, geo-coordinate truncation method

adjusts location precision level; in the second option,

SECRYPT 2016 - International Conference on Security and Cryptography

190

Algorithm 2: Enhanced Permissions Algorithm.

Input: l

: Representative Location

Output: l

: Processed Location

1: u

= User Input

2: read l, l

, f , u

3: if u

= Adjust Granularity then

4: check granularity level g

5: truncate(l, l

)

6: replace l to l

and l

to l

7: return l

8: else if u

= Obfuscate then

9: randomly generate angle θ

10: obfuscate(l, l

, θ)

11: replace l to l

and l

to l

12: return l

13: else

14: unchanged

15: return l

16: end if

geo-coordinate transformation obfuscate user’s loca-

tion; whereas, in the third option, the exact unchanged

geo-coordinates are sent to the requesting app.

Enhanced Permissions Algorithm. Once LP-

Cach

e receives an invoked location object l

, it alters

the location data according to the enhanced permis-

sion settings and returns processed location l

. The

steps involved in enhanced permission mechanism are

summarised in Algorithm 2, where u

is the set per-

mission, g

is the adjusted location precision level, l

is the latitude, and l

is the longitude.

Geo-coordinates Truncation. The geographical

coordinates looks like 52

◦

28’59.200” N

◦

53’37.0001” W, where the last digits specify more

accurate geo-location. Geo-coordinate truncation

method will enable us to adjust the location precision

level, i.e., by removing last digits and rounding the lo-

cation accuracy from street to city level or even more

general. Generally, for any third party reuse, ser-

vice providers or data collectors assure in the EULA

that this method will be applied on the collected data

since the truncated coordinates increase the ambiguity

level(Aad and Niemi, 2010). On contrary, LP-Cach

applies this method on the user device with user’s per-

mission in order to minimise the user’s sensitive data

collection and privacy concerns.

Geo-coordinates Transformation. For privacy

preservation, position transformation functions such

as scaling, rotation and translation have been used

Table 1: WiFi measurement dataset summary.

Total number of scans 25480

Distinct private locations selected 34

Total APs detected 486

Average APs detected 396

by location data distributors or anonymisers (Lin

et al., 2008; Wernke et al., 2014). In LP-Cach

we use geo-coordinate transformation on the device

to obfuscate user’s private locations. Our service

represents the geo-coordinate transformation using

scaling and rotation, and denotes its parameters as a

tuple hs, θ, (l, l

)i, where s is the scaling factor, θ is

the rotation angle, and (l, l

) are the original coordi-

nates. It applies Equation 2 to generate transformed

or obfuscated geo-cordinates (l

, l

), where angle θ is

randomly generated.

= θ(s.l)

= θ(s.l

)

(2)

6 FEASIBILITY AND USABILITY

ANALYSIS

LP-Cach

e’s actual performance evaluation depends

on the location-based apps performance. In this sec-

tion, we analise the WiFi AP data availability and con-

sistency to measure feasibility of WiFi ﬁngerprinting

method to be included in LP-Cach

e’s implementation.

6.1 WiFi APs Availability and

Consistency

Experimental Set-up. The experimental set-up to

measure WiFi AP data availability and consistency

consists of three steps:

1. Data collection. We collected beacons from

ﬁxed WiFi APs using WiEye (WiEye, 2016) and

Network Info II (NetworkInfoIi, 2016) apps

on Android smartphones that have 802.11a/b/g/n

radio feature so they can operate in both 2.4GHz

and 5GHz bands at 34 different private places for

a period of one month.

2. Location categorisation. App users are more

concern about sharing their private loca-

tions(Almuhimedi et al., 2015); therefore, in our

analysis, we selected three distinct categorise of

private places: 1. Home (i.e., residential place),

2. Work (i.e., commercial place), and 3. Arbitrary

(i.e., any frequently visited place) to determine

categorical distribution pattern of WiFi APs.

LP-Cache: Privacy-aware Cache Model for Location-based Apps

191

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

No. of APs

Place IDs

Max No. of APs

Freq.

Min.

Figure 6: Measured density of detected WiFi APs at private

places.

3. Data analysis. We collected and statistically anal-

ysed the scanned WiFi AP data. Table 1 compiles

the included sample size; whereas, Figure 6 shows

the relative difference between WiFi APs density,

and Figure 7 depicts the relative average accuracy

distribution pattern of detected WiFi APs for each

category.

Observation. For each category of private places,

experiments revealed the following:

Home The results demonstrate that Wiﬁ APs are

ﬁxed and frequent and the difference between

number of constant beacons and minimum num-

ber of similar beacons is comparatively less,

and therefore, it achieved highest accuracy rate.

Moreover, the ratio of SSID to BSSID is 1:1, i.e.,

1 SSID (abc) has 1 BSSID (a0:12:b3:c4:56:78),

this makes ﬁngerprints distinct so improving the

location detection performance.

Work This category has many ﬁxed WiFi APs but

with ﬂuctuating signal strengths, and therefore,

the sequence of available APs changes. However,

the observed ratio of SSID to BSSID is many to

one, i.e., 1 SSID has many BSSIDs; therefore, in

this case, SSIDs along with BSSIDs can be used

as unique identiﬁers to create a ﬁngerprint to de-

tect a private place dynamically.

Arbitrary In this category, the data collector could

select any frequently visited locations, e.g., gym,

shop, or friend’s home. Figure 7 demonstrates that

the outcome of this category is related to the other

two categories, it either shows results similar to

home or work.

The range of average accuracy for all the three cat-

egories of private places falls between 74% to 96%.

0 10 20 30

Avg. Accuracy

No. of APs

Home

Work

Arbitrary

Figure 7: Relative average accuracy distribution pattern of

detected WiFi APs at private places.

Hence, it is evident that smartphones regularly de-

tect similar beacons at frequently visited place, for

place detection at least one beacon should match with

the stored ﬁngerprints. Thus, the results demonstrates

that WiFi ﬁngerprinting can be effectively used as pri-

vate place detection source in LP-Cach

e. Nonethe-

less, to achieve efﬁcient capability for place recog-

nition via beacons place discovering algorithm like

(Kim et al., 2009) can be implemented (in future

work).

6.2 Ongoing Evaluation of Caching

Method

Following WiFi data availability and consistency

analysis, LP-Cach

e’s feasibility evaluation will be ex-

tended to analyse how frequently cache needs to be

updated and what are the trade-offs of cache update

frequency vs location privacy and accuracy in order

to measure further computational and communication

overheads. We also intent to conduct a thorough user

study to determine comfortability of the users to ac-

commodate LP-Cach

e’s functionality. Moreover, we

plan to consider the fundamental caching based tech-

nical challenges such as cache hits and cache misses,

data freshness, data consistency, and estimated band-

width requirements in the further development and

implementation of LP-Cach

e paying special attention

to storage-efﬁcient caching.

7 CONCLUSIONS

Secure gathering and transfer of location data via

smart mobile devices while at the same time preserv-

ing users’ privacy are concerning needs. Research and

industry communities are making joint efforts to iden-

SECRYPT 2016 - International Conference on Security and Cryptography

192

tify the requirements for LBS applications in future

large scale scenarios and addressing end user con-

cerns. Studies based on cryptographic schemes and

PETs have been tested on service provider’s data col-

lection servers but neither are implemented on the

mobile platform, nor on the actual app operation. In

addition, the lack of usability is one of the factors that

hinders the adoption of existing privacy-aware solu-

tions. We presented detailed analysis of the current

location computation process and proposed a novel

privacy-aware model. Both the end users and ser-

vice providers beneﬁts from LP-Cach

e since the on-

device caching technique works on the minimisation

of the user’s private location collection process. With

a personalised permission mechanism, users can man-

age each app and private place distinctly. Immedi-

ate future work focuses on the implementation of the

model to measure the feasibility, usability and efﬁ-

ciency of our approach while interacting with differ-

ent location-based apps.

REFERENCES

Aad, I. and Niemi, V. (2010). NRC data collection and the

privacy by design principles. In PhoneSense.

Almuhimedi, H., Schaub, F., Sadeh, N., Adjerid, I., Ac-

quisti, A., and Others (2015). Your Location has been

Shared 5,398 Times! A Field Study on Mobile App

Privacy Nudging. In Procs. of ACM Conf. on Human

Factors in Computing Systems, pages 787–796. ACM.

Amini, S., Lindqvist, J., Hong, J., Lin, J., Toch, E., and

Sadeh, N. (2011). Cach

e: caching location-enhanced

content to improve user privacy. In Procs. of ACM Int.

Conf. on Mobile Systems, Applications, and Services,

pages 197–210. ACM.

Android Developer Reference (2016).

http://developer.android.com/reference/.

Anonymizer (2016). http://www.anonymizer.com/.

Bell, S., Jung, W. R., and Krishnakumar, V. (2010).

WiFi-based enhanced positioning systems: accuracy

through mapping, calibration, and classiﬁcation. In

Procs. of ACM SIGSPATIAL Int. Workshop on Indoor

Spatial Awareness, pages 3–9. ACM.

Beresford, A. R., Rice, A., Skehin, N., and Sohan, R.

(2011). Mockdroid: trading privacy for application

functionality on smartphones. In Procs. of ACM Work-

shop on Mobile Computing Systems and Applications,

pages 49–54. ACM.

Cranor, L. F. and Sadeh, N. (2013). A shortage of privacy

engineers. IEEE Security & Privacy, (2):77–79.

Damiani, M. L. (2011). Third party geolocation services in

LBS: Privacy requirements and research issues. Trans.

on Data Privacy, 4(2):55–72.

Doty, N. and Wilde, E. (2010). Geolocation privacy and ap-

plication platforms. In Procs. of ACM SIGSPATIAL

Int. Workshop on Security and Privacy in GIS and

LBS, pages 65–69. ACM.

Egele, M., Kruegel, C., Kirda, E., and Vigna, G. (2011).

PiOS: Detecting Privacy Leaks in iOS Applications.

In NDSS.

Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-

G., and Others (2014). TaintDroid: an information-

ﬂow tracking system for realtime privacy monitoring

on smartphones. TOCS, 32(2):5.

European Commission (2016). Protection of personal data.

http://ec.europa.eu/justice/data-protection/.

Fawaz, K. and Shin, K. G. (2014). Location Privacy Pro-

tection for Smartphone Users. In Procs. of ACM

SIGSAC Conf. on Computer and Communications Se-

curity, pages 239–250. ACM.

Felt, A. P., Egelman, S., and Wagner, D. (2012). I’ve got 99

problems, but vibration ain’t one: a survey of smart-

phone users’ concerns. In Procs. of ACM Workshop

on Security and Privacy in Smartphones and Mobile

Devices, pages 33–44. ACM.

Gibler, C., Crussell, J., Erickson, J., and Chen, H. (2012).

AndroidLeaks: Automatically detecting potential pri-

vacy leaks in Android applications on a large scale. In

TRUST 2012, pages 291–307. Springer.

Google Location Service (2016). https://support

.google.com/gmm/answer/1646140?hl=en-GB.

Hellman, E. (2013). Android programming: Pushing the

limits. John Wiley & Sons.

IETF (2016). Geographic Location Privacy.

http://datatracker.ietf.org/wg/geopriv/charter/.

Jeon, J., Micinski, K. K., Vaughan, J. A., Fogel, A., and

Reddy (2012). Dr. Android and Mr. Hide: ﬁne-grained

permissions in android applications. In In Procs. of

ACM Workshop on Security and Privacy in Smart-

phones and Mobile Devices, pages 3–14. ACM.

Khoshgozaran, A., Shahabi, C., and Shirani-Mehr, H.

(2011). Location privacy: going beyond K-anonymity,

cloaking and anonymizers. Knowledge and Informa-

tion Systems, 26(3):435–465.

Kim, D. H., Hightower, J., Govindan, R., and Estrin, D.

(2009). Discovering semantically meaningful places

from pervasive RF-beacons. In Procs. of ACM Int.

Conf. on Ubiquitous Computing, pages 21–30. ACM.

Lin, D., Bertino, E., Cheng, R., and Prabhakar, S. (2008).

Position transformation: a location privacy protection

method for moving objects. In Procs. of the SIGSPA-

TIAL ACM GIS 2008 Int. Workshop on Security and

Privacy in GIS and LBS, pages 62–71. ACM.

Michael, K. and Clarke, R. (2013). Location and tracking of

mobile devices:

Uberveillance stalks the streets. Com-

puter Law & Security Review, 29(3):216–228.

Muslukhov, I., Boshmaf, Y., Kuo, C., Lester, J., and

Beznosov, K. (2012). Understanding users’ require-

ments for data protection in smartphones. In ICDE

Workshop, IEEE Int. Conf. on Secure Data Manage-

ment on Smartphones and Mobiles, pages 228–235.

IEEE.

Navizon (2016). http://www.navizon.com.

NetworkInfoIi (2016). http://play.google.com/store/apps/.

LP-Cache: Privacy-aware Cache Model for Location-based Apps

193

Niu, B., Li, Q., Zhu, X., Cao, G., and Li, H. (2015). En-

hancing Privacy through Caching in Location-Based

Services. In Proc. of IEEE INFOCOM.

Patel, A. and Palomar, E. (2014). Privacy Preservation in

Location-Based Mobile Applications: Research Di-

rections. In Procs. of IEEE Int. Conf. on Availabil-

ity, Reliability and Security (ARES), pages 227–233.

IEEE.

Pontes, T., Vasconcelos, M., Almeida, J., Kumaraguru, P.,

and Almeida, V. (2012). We know where you live:

Privacy characterization of foursquare behavior. In

Procs. of ACM Conf. on Ubiquitous Computing, pages

898–905. ACM.

Shklovski, I., Mainwaring, S. D., Sk

ulad

ottir, H. H., and

Others (2014). Leakiness and Creepiness in App

Space: Perceptions of Privacy and Mobile App Use.

In Procs. of ACM Conf. on Human factors in comput-

ing systems, pages 2347–2356. ACM.

Skyhook (2016). http://www.skyhookwireless.com/.

TOR (2016). http://www.torproject.org/.

tPacketcapture (2016). http://play.google.com/.

Wernke, M., Skvortsov, P., D

urr, F., and Rothermel, K.

(2014). A classiﬁcation of location privacy attacks

and approaches. Personal and Ubiquitous Computing,

18(1):163–175.

WiEye (2016). http://play.google.com/store/apps/.

Wireshark (2016). https://www.wireshark.org.

Zhu, X., Chi, H., Niu, B., Zhang, W., Li, Z., and Li, H.

(2013). Mobicache: When k-anonymity meets cache.

In GLOBECOM, pages 820–825. IEEE.

Zhuang, Y., Syed, Z., Georgy, J., and El-Sheimy, N. (2015).

Autonomous smartphone-based WiFi positioning sys-

tem by using access points localization and crowd-

sourcing. Pervasive and Mobile Computing.

SECRYPT 2016 - International Conference on Security and Cryptography

194