movewithme: location privacy preservation for smartphone...

IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 15, 2020 711

MoveWithMe: Location Privacy Preservationfor Smartphone Users

Jian Kang , Doug Steiert, Dan Lin , and Yanjie Fu

Abstract— With the prevalence of smartphones, mobilewebsites have been more and more popular. However, manymobile websites collect the location information which greatlyincreases users’ risks of being tracked unexpectedly. The cur-rent location access control setting is not sufficient since itcannot prevent the service providers which have been grantedlocation-access permissions from tracking the users. In thispaper, we propose a novel location privacy preservation mobileapp, called MoveWithMe, which automatically generates decoyqueries to hide the real users’ locations and intentions whenthey are using location-based mobile services. Unlike the existingworks on dummy trajectories which may be easily discoveredby attackers through data analysis, the uniqueness of the Move-WithMe app is that our generated decoys closely behave likereal humans. Each decoy in our system has its own movingpatterns, daily schedules, and social behaviors, which ensuresits movements to be semantically different from the real user’strace and satisfying geographic constraints. Thus, our decoyscan hardly be distinguished even by advanced data miningtechniques. Another advantage of the MoveWithMe app is that itguarantees the same level of user experience without affecting theresponse time or introducing extra control burdens. Decoys moveindependently in the back end and automatically submit queriesto the same service provider whenever the user does so. Ourproposed MoveWithMe app has both iOS and Android versionsand has been tested on different brands of smartphones againstvarious location-based services, such as Yelp and TripAdvisor.Experimental results demonstrate its practicality, effectiveness,and efficiency.

Index Terms— Location privacy, location-based service, smart-phone, mobile app.

I. INTRODUCTION

SMARTPHONES are a driving force in many actions thatwe do every day, and the number of smartphone owners

has increased tremendously. Meanwhile, the number of mobilephone applications and websites have also exponentially risenalongside the growth of smartphone usage. A popular array ofservices that are combined with mobile websites are known as

Manuscript received October 11, 2018; revised March 22, 2019 andMay 22, 2019; accepted July 2, 2019. Date of publication July 11, 2019;date of current version September 24, 2019. This work was supported bythe National Science Foundation under Project DGE-1914771 and ProjectCNS-1651455. The associate editor coordinating the review of this manuscriptand approving it for publication was Dr. Anna Squicciarini. (Correspondingauthor: Jian Kang.)

J. Kang, D. Steiert, and D. Lin are with the Electrical Engineering & Com-puter Science Department, University of Missouri, Columbia, MO 65211 USA(e-mail: [email protected]; [email protected]; [email protected]).

Y. Fu is with the Department of Computer Science, Missouri University ofScience and Technology, Rolla, MO 65401 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/TIFS.2019.2928205

Location Based Services (LBSs). While many users typicallydo not explicitly recognize these services being used, they arealso unaware of the risks that are associated with them. Suchloose control on location data by existing mobile websiteshas caused different types of privacy threats. To name a few,an adversary who learns the locations that a person visited maygain clues of that person’s daily movement pattern, hobbies,political affiliations, and medical problems.

To mitigate risks to users’ location privacy when they arevisiting location-based services on their smartphones, severalstrategies have been proposed. One typical approach is toadd an access control mechanism to control the locationdisclosure to the selected service providers such as the loca-tion privacy settings in iOS and Android systems. However,such access control approaches [1] do not prevent serviceproviders which have been granted location access permissionsfrom tracking the users. In order to provide better privacyprotection, some approaches [2] have been proposed basedon the spatial-temporal cloaking or k-anonymity. The basicidea is to let the user submit a bigger region instead ofthe exact location to the service provider when requestinglocation-based services. In this way, the service providermay only have some rough ideas about where the user isaround but is not able to pinpoint the user’s exact location.However, the existing spatial-cloaking-based approaches havelimited protections against the attacks that exploit aggregatedinformation collected via continuous queries to obtain themoving trends and even narrow down possible places thata user has visited. Another common approach for locationprivacy preservation is to generate dummy trajectories. How-ever, existing algorithms for dummy generations [3]–[7] arestill vulnerable to attacks that employ data mining techniquessuch as the sequential pattern mining as reported in [4]. This isbecause the dummies are mostly randomly generated with verylittle consideration of the real-world geographical constraintsand behavior patterns. Moreover, existing works lack theconsiderations of the user experience on how to adopt theselocation privacy preservation mechanisms in the real worldsettings.

To overcome the aforementioned limitations, in this paper,we present a novel location-privacy preservation mobile app,called MoveWithMe. It is called MoveWithMe since it auto-matically generates a number of decoys to move with the userlike real human beings and serve as distractions to the serviceproviders. In the MoveWithMe system, each decoy has itsown moving patterns, favorite places, daily schedules, social

1556-6013 © 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

Authorized licensed use limited to: University of Missouri Libraries. Downloaded on March 26,2020 at 16:32:19 UTC from IEEE Xplore. Restrictions apply.

https://orcid.org/0000-0002-0841-9039

https://orcid.org/0000-0002-3062-8240

712 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 15, 2020

Fig. 1. An Example Scenario in the MoveWithMe System.

behaviors, etc. Based on the user’s privacy needs, the initialnumber of decoys, the decoys’ social and travel patterns,and their personalized profiles can be varied. Unlike previousdummy-based approaches which only generate dummies inthe nearby region and the same city where the real user islocated, our decoys may be in the same city as the user, orin different cities of different countries in order to furtherconfuse the attackers about the locations of the real user. Thefactors such as GPS error and changing of speed are alsoconsidered. In this way, the user’s privacy is protected sincethe attackers or service provider will not be able to identifythe real user’s trajectories out of all the decoys’ trajectoriesto profile the real user. Figure 1 depicts the real user (sayBob)’s trajectory in New York City who uses the Move-WithMe system to help generate four decoys’ trajectories inthree different cities in different countries. With the activatedMoveWithMe system running in the background, the decoyscontinuously move throughout the day as real humans. In theexample, Decoy1 will follow a postman’s daily routine andmay visit many houses, Decoy2 is a lawyer who may visitclients during the day, and Decoy3 and Decoy4 will movebased on their profiles as a teacher and a student, respectively.As time passes, when Bob has been to his research lab anda fast food restaurant, his decoys may have visited residentialareas, other schools, hotels, pizza places, parks, etc. WheneverBob visits a location-based service website such as Yelp,the MoveWithMe will intercept Bob’s request before it goesout to the location-based service, mix Bob’s request with othersimulated requests from the four decoys, and then send fiverequests altogether to Yelp. Even if Bob continuously accessthe same location-based service, the service provider will stillhave a hard time to discover Bob’s locations out of fivetrajectories that demonstrate different moving patterns, jobs,social behaviors, etc. In order to prove the effectiveness of theprivacy protection offered by MoveWithMe, we show in ourexperiments that the users’ real trajectories are well hiddenamong decoys’ trajectories since they are not only impossi-ble to be distinguished from decoys’ trajectories visually byhumans, but also hard to be distinguished by advanced datamining techniques that the attackers or service providers mayuse. Our contributions are summarized as follows:

• Compared with existing dummy generation algorithms,our algorithms to the generation of decoys are funda-mentally different and much more sophisticated. In oursystem, the decoys are not only geographically different

but also semantically different from the real user’s tra-jectories. Moreover, to closely mimic real humans, ourgenerated decoys not only follow real humans’ socialbehavior profiles but also integrate a variety of uncertaintythat could happen in the real human trajectories. Forexample, among a consistent set of frequent places to bevisited by a decoy throughout days and weeks, we alsoconsider reasonable changes of moving speed and staytime, possible GPS errors, and occasionally change ofbehavior such as change of restaurants for lunch.

• Compared with most of the existing location privacypreservation approaches, our system is more practical.We have built the prototype of the proposed MoveWithMesystem in both iOS and Android systems. The Move-WithMe app guarantees the same level of user experiencewithout affecting the response time or introducing extracontrol burdens to users. It is capable of intercepting anylocation-based services and providing the privacy preser-vation for users in real time without any involvement ofa trusted third party or central server.

• In the experiments, we evaluated the MoveWithMe sys-tem against a variety of existing location-based servicessuch as Yelp and TripAdvisor in different brands of smart-phones. The experimental results demonstrate feasibility,effectiveness, and efficiency.

The rest of this paper is organized as follows. Section IIreviews related works. Section III presents the details of ourproposed MoveWithMe system. Section IV conducts privacyanalysis. Section V reports the experimental results. Section VIdiscusses the limitations of this system. Lastly, Section VIIconcludes the paper.

II. RELATED WORK

Various approaches have been proposed to preserve locationprivacy, which can be classified into four main categories:

A. Spatial-Temporal Cloaking Based Approaches

The key idea of spatial-temporal cloaking is to generate acloaking region that contains the user’s real location and K −1other users. In this way, the service provider would not beable to distinguish the K users in the same region and henceusers achieve K -anonymity. The idea was first introducedby Gruteser and Grunwald [8] and later has been extendedby many [9]–[14] with different ways of generating the


KANG et al.: MoveWithMe: LOCATION PRIVACY PRESERVATION FOR SMARTPHONE USERS 713

cloaking regions. Although this kind of approaches can hidethe user’s exact location, the coarse location information ofthe user such as the user’s moving trend is still not wellprotected. For example, even though the attackers cannot knowthe exact location of the user’s home, it is still possible forthem to know which city the user lives, and the approximatetrajectory of the user by connecting the cloaking regions.Lin et al. [15] propose a remedy solution that transformsall the real locations to a new domain, which fully preventsthe leak of the exact and continuous locations but can onlysupport limited types of queries such as queries on the friends’locations.

B. Differential Privacy Based Approaches

Another way to hide the user’s exact locations from theservice provider is to utilize the differential privacy theoryto add noises to the users’ real locations. Andres et al.apply Laplacian noise to location data in a discrete Carte-sian plane in [16]. In this model, users are able to adjustthe level of the desired privacy, which in turn increases ordecreases the amount of noise added to the location data.Chen et al. [17] propose to adjust noises based on unob-servability and a Kalman filter. Xiao et al. [18] propose toadjust the privacy protection levels based on users’ locationprofile and mobility history. Ngo and Kim [19] introducethe differential privacy geo-indistinguishability notion thathelp reduce the average size of cloaking regions. Similarly,Wang et al. [20] also use differential geo-obfuscation to hidethe user’s exact location. Although these differential basedapproaches can obfuscate the user’s locations, the noisesthat are added to the location data still need to be limitedto ensure the service quality. That means the adversarieswill still be able to know the city where the user lives,the approximate user trajectories, the time pattern of the user’sdaily routine, and hence be able to profile the user. Moreover,by observing non-sensitive contexts, the adversary may alsobe able to infer the user’s sensitive information as pointedout in [21].

C. Encryption Based Approaches

The encryption-based approaches aim to fully preserve thelocation privacy by encrypting the location data and conduct-ing queries directly on the encrypted data. One representativework is by Ghinita et al. [22] who propose a frameworkto support private nearest neighbor queries based on PrivateInformation Retrieval. Puttaswamy and Zhao [23] propose toencrypt location coordinates before sharing which ensuresthat only designated users can decrypt the location informa-tion. Huang et al. [24] use smartphones to perform securemulti-party computation over users’ location data. Wei et al.in [25] propose a system named MobiShare to support thelocation sharing among trusted friends and untrusted strangerswhile preserving user’s location privacy. Guha et al. [26]introduce a privacy-preserving framework which provides acloud-based matching service to return attributes and theirvalues in an encrypted fashion. In [27], Li and Jung devise aprivacy-preserving location query protocol which encrypts the

location data using Pallier encryption to ensure that adversariescannot intercept transmitted data. Later, Puttaswamy et al. [28]attempt to preserve location privacy in geo-social applications.To improve query efficiency, Paulet et al. [29] combine oblivi-ous transfer and private information retrieval techniques. Basedon the improved homomorphic encryption, Zhu et al. [30]present a query framework in which users can query LBSresults in a polygon range without leaking the informationof the query polygon. These encryption-based approachescan provide a strong privacy guarantee of user’s locationinformation. However, to support the encryption-based fea-tures, the current architecture of the LBS server and clienthave to be significantly changed, which may not be eas-ily deployed in the near future due to the capital costinvolved.

D. Dummy-Based Approaches

This category of work is most related to ours. Thedummy-based approaches generate dummies and send fakelocations along with the user’s real location to the serviceprovider so as to protect the user’s location privacy [31]. Forexample, Niu et al. [3], [32] propose dummy swapping anddummy selection strategies. Xue et al. [33] propose to placemultiple virtual probes to pinpoint user location from fakeGPS locations. Zhang et al. in [34] propose two dummy-POIselection algorithms so as to support the queries of top-kPOIs. Fei et al. in [35] propose to divide users into groups,select dummies based on groups, and then share the returnedresults from the service provider. However, these dummiesdo not have continuous movement patterns which can beeasily discovered by attackers who analyze dummies collectedat different time stamps. In order to better simulate thetrajectories of dummies, Lei et al. [4] propose two schemesto generate dummies that exhibit long-term movement patternsbased on human movement behavior. Wang et al. [6] propose afog structure to store partial information and generate dummytrajectories. Since they did not consider the geographicalconstraints, as a result, the generated dummy trajectories maybe off-road or at places that are not accessible by real humans.To solve this problem, Hara et al. [5] added the considerationof geographical constraints during the dummy generation.With the similar idea of generating fake dummies to hidethe user’s real location, Zhang et al. [36] proposed to releasesome fake contexts to the adversary so as to protect the user’ssensitive contexts such as location information. Based onexisting dummy generation schemes, Liu et al. [37] filter outthe dummies that can be identified by taking into account ofthe spatiotemporal correlation. Hayashida et al. [7] propose adummy generation method which can estimate user-movementbased on the visiting points inputted by the user. Insteadof generating dummy locations, Pingley et al. propose togenerate dummy queries with different service attributes toprevent the adversary from correlating a query with a specificuser. However, these approaches still lack the consideration ofdummies’ behavior rationale. Their generated dummies do nothave daily routines. Such random behavior of dummies can beeasily distinguished from real human trajectories by existingdata mining techniques.



Another related thread of work is on privacy recommenda-tion such as Li et al. [38] who propose to automatically learnuser’s privacy preferences.

Although there have been extensive studies on location pri-vacy theories, very few efforts have been devoted to developingreal mobile apps for users to actually control their locations.Existing applications are mostly preliminary. For example,in [39], Hornyack et al. develop a system which returns a fixedlocation and phone number at all times. While this can ensuregood privacy for the user, the user will never be able to enjoymost utilities of the location-based services. Shokri et al. [40]devise an interesting collaborative approach that allows peerusers to form MobiCrowd. When a user needs to contact alocation-based service, his/her request will not be directly sentto the server but be routed through the MobiCrowd. In thisway, the location-based service provider will not know whosent the query. However, such strategy falls short when thereare not enough users nearby. Achara et al. [41] developed amobile app which can analyze the privacy leakage in smart-phones. Most recently, Fawaz et al. [2] conducted a detailedrisk analysis of the use of mobile apps in terms of locationprivacy leak. They propose an app called LP-Doctor whichallows users to adjust the amount of location information tobe disclosed to various apps. However, the service providerswhich have been granted permission to access the locations canstill track the users. Compared to existing works on location-privacy-preserving mobile apps, our proposed MoveWithMeis unique in the following aspects:

• It is not constrained by the people density and can beused at any time and any place.

• It protects not only the user’s discrete locations but alsocontinuous trajectories.

• It generates decoy trajectories that follow the real-timeroad conditions such as traffic jams.

• It can prevent the adversaries from knowing which city,and even which country the user lives in by simulatingdifferent decoys in different cities and countries.

• It guarantees the user’s experience and service qualityin that the user is able to obtain the same query resultswithout performing extra steps.

• It introduces very little overhead as demonstrated by ourimplementations.

• It does not require any change on existing server andclient structure, and can be immediately adopted byusers.

It is worth noting that the initial idea of having a Move-WithMe system was first presented in our prior poster [42]which however has a very simple decoy generation algorithmand a simple app implementation that mainly relies on theAndroid platform’s location mocking. In this paper, we havemade the following significant improvement. We designeda much more sophisticated decoy generation algorithm.We developed a new app framework that is able to automati-cally capture and modify the data packets between users andservice providers in the back end so as to automate the locationmocking process which has to be done manually in our priorwork. Our app can now be deployed both on Android andIOS platforms. Moreover, we conducted a whole new set of

experiments including the evaluation of the use of advanceddata mining techniques as an attack to our proposed system.

III. MOVEWITHME – A LOCATION PRIVACY PRESERVING

SYSTEM FOR SMARTPHONE USERS

The goal of the MoveWithMe system is to prevent theservice provider from profiling a user who is using thelocation-based services. In what follows, we first present ourthreat model and then elaborate our proposed system.

A. Threat Model

In our work, there are two main parties: (i) Location-basedservice providers; (ii) Smartphone users who requestlocation-based services. We assume that the smartphone usersconnect to the Internet via certain VPN (Virtual PrivateNetwork) or anonymity network TOR (The Onion Router) sothat the location-based service providers cannot use the IPaddress attached to the service request to pinpoint a user’slocation. We consider two types of location-based serviceproviders:

• Precise location collectors: Some location-based servicescollect users’ precise location information such as theGPS coordinates or other forms of data which could beused to reveal the user’s exact locations (e.g. embeddedaccelerometer, gyroscope, etc. [43]). For example, navi-gation apps need the user’s exact locations to calculate thecorrect routes; the IoT (Internet-of-Things) device man-agement platforms may need to know the user’s preciselocations to trigger certain location-based functions.

• Coarse location collectors: Some location-based servicesonly need coarse location information such as the zipcode. For example, weather forecasting services just needto know which city a user is located.

We consider two kinds of adversaries: (i) location-basedservice providers who are interested in profiling the usersfor business profits; (ii) attackers who have compromised thelocation-based servers. These adversaries may attempt to seekusers’ private information in the following ways:

• The adversary profiles the users’ daily routines andpreferences by analyzing the users’ accurate locationsor coarse locations collected from the users’ ser-vice requests. Specifically, if the user accesses thelocation-based services intermittently, the adversary willobtain the user locations as disconnected spatial pointson the map. If the user uses the service continuously,the adversary will obtain the user’s trajectories or mov-ing trends. In either case, the adversary can learn thetime patterns of the users’ movement by analyzing thetimestamps associated with the location information.

• The adversary may try to link accounts of the same userin different location-based services, combine the collectedlocation information from different accounts, and obtaina more complete trajectory information of the user.

• The adversary may exploit many tools such as advanceddata mining tools and statistical tools to try to filter outthe fake locations/trajectories that the users intend to useto obfuscate their true locations.



Fig. 2. The Framework of the MoveWithMe System.

We assume that the adversaries can only passively receivelocation information provided by users. That means the adver-saries are not able to control the user’s mobile device ordirectly pull the user’s location information without users’permissions. Our proposed approach will be robust againstthese attacks.

B. System Overview

The MoveWithMe system consists of five main components:• Decoy Simulator: The decoy simulator component takes

movement patterns and social profiles as inputs to gen-erate real-time trajectories of the decoys. The decoys’trajectories also consider moving speed and possible staytime as well as GPS errors in order to mimic real humanbehavior as much as possible. In order to ensure theconsistency of the decoys’ movement and better protectuser’s location privacy, this component is constantly run-ning in the background even when the real user is notusing a location-based service or is not moving.

• Request Interceptor: When the user accesses alocation-based service, the request interceptor compo-nent will analyze the request based on the pre-definedintercepting rules. Specifically, this component will firstcheck if the request contains location information, andwhat type it is. Then, it will take the decoys’ locationsfrom the decoy simulator component, generate severalrequests for decoys, mix the simulated requests with theuser’s real request, and send them to the service provideraltogether. Upon receiving the response from the serviceprovider, this component will filter out the response tothe decoys’ requests and display only the response tothe user’s request. By intercepting the communicationbetween the user’s mobile phone and the service provider,this component is able to prevent the service providerfrom identifying the real user request.

• Service Monitor: When the user is accessing alocation-based service, the request interceptor componentwill hand over the request record to the service monitorcomponent. The service monitor component will record

each location request from the service provider and notifythe user about his/her location usage.

• Location Recorder: This component is in charge ofstoring both the real and fake location information in ahistorical trace database in order to ensure the consistencyduring the decoy generation and adjust the decoy profilegeneration parameters if needed. By analyzing the histor-ical trajectories and with the help of Google Places API,we can find out the user’s moving pattern, daily schedule,social behaviors, favorite places, etc., which are useful forgenerating new patterns and profiles for decoys to bettermeet the user’s needs.

• Trajectory Display: This function is for the user tovisualize his/her real trajectories and the decoys’ trajec-tories so that he/she may adjust the privacy settings ifneeded.

Figure 2 gives an overview of how the components inthe MoveWithMe system are cooperating with each otherand interacting with location-based services. In particular,to obtain the protection from MoveWithMe, the smartphoneuser just needs to open the MoveWithMe app before visitingany location-based service websites. If the service monitordetects that a location-based service requires the user’s phoneto upload the user’s location information, the MoveWithMeapp will automatically send a mixed group of the real userrequest and the fake requests based on the decoys’ locationsto confuse the service provider.

The MoveWithMe app needs two permissions from the user,which are the permission to access the Internet for accessingGoogle Directions and Places API, and the permission toaccess GPS location. Note that compared to many apps inthe Google Play Store and Apple App Store, the number ofpermissions requested by our app is relatively minimal.

C. Decoy Pattern and Profile

In the MoveWithMe system, we model the decoys’ socialand travel behavior patterns and personalized profiles asfollows:



Definition 1: A decoy’s social and travel behavior patternis in the form of 〈P I D,T ,M,P〉, which describes when andwhere a decoy may be and in what travel mode:

• PID is the unique ID of the pattern.• T contains the types of places a decoy may visit. It is

defined as a matrix [〈T ypei , Randi , Meani , Devi 〉]n,where T ype denotes the type of a place such as “home,”“friend’s home,” “university” and “restaurant,” Randindicates whether this is a fixed type (F) (e.g., home) ora randomly selected type (R) (e.g., restaurant), Mean andDev are the mean and deviation of the length of time thata decoy may stay at this type of place, and n (n > 0) isthe total number of place types that a decoy may visit.

• M depicts the travel modes that a decoy may take underdifferent situations. Specifically, M is a matrix in theform of: [〈Dis_mini , Dis_maxi , Pdi , Pti , Pbi , Pwi 〉]m,where Pd, Pt, Pb, and Pw are respectively the prob-abilities of four travel modes (driving, public transitsystem, bicycling, and walking) that a decoy may takewhen the estimated travel distance is in the range of[Dis_min, Dis_max), and m (m > 0) denotes the totalnumber of travel modes in this pattern.

• P defines the transition probabilities between differ-ent types of places in a week. For the wth dayin a week (let 1 to 7 denote Monday to Sundayrespectively), Pw is a set of probability matrices inthe form of [〈T ime_sti , T ime_edi , [PT ype j ,T ypek ]n×n〉]q ,where PT ype j ,T ypek indicates the probability that a decoymay transit to T ypek when it leaves a place of T ype j

during the time period [T ime_st, T ime_ed), n is thetotal number of place types, and q (q > 0) is the totalnumber of transition probability matrices.

Definition 2: A decoy’s personalized profile is in the form of〈F I D,SP ,MB,G〉, which is an instantiation of the decoy’ssocial and travel pattern.

• FID is the unique ID of the profile.• SP is a set of specific places a decoy may visit.SP is defined as a matrix [〈Namei , T ypei , Lati ,Lngi , [Wsw]7〉]s , where Name is the name of the place,T ype is the type of the place defined by the decoy’spattern, Lat and Lng are the latitude and longitude of theplace respectively, [Wsw]7 is the weekly schedule whereSP i .Wsw denotes the probability of the place i beingvisited by a decoy when it decides to visit SP i .T ype onthe wth day of the week, and s (s > 0) is the total numberof places that a decoy may visit.

• MB depicts the moving behaviors of a decoy. It is inthe form of [〈Modei , Speed_ fi , Speed_devi 〉]t , whereMode is the travel mode, Speed_ f is the speed fac-tor (Speed_ f > 1.0 means a decoy may move fasterthan others and vice versa), and Speed_dev depicts thevelocity stability of the decoy.

• G defines the GPS parameters of a decoy underdifferent travel modes. G is in the form of[〈Modei , Accuracyi, Accuracy_devi , U pdate_ti 〉]g,where Mode is the travel mode (besides the travel modesdefined above, we introduce a new mode non-moving

Fig. 3. An Example of a Social & Travel Behavior Pattern.

so as to simulate the GPS error when a decoy is notmoving), Accuracy, Accuracy_dev, and U pdate_tare respectively the positioning accuracy, the deviationof accuracy, and the update interval of the decoy’ssimulated locations.

The decoys’ patterns and profiles are used to depicthuman-like decoys with different behaviors. Here, the socialand travel behavior pattern refers to a high-level description ofdaily activities and travel patterns of a group of people, whilethe personalized profile refers to specific places and movingbehaviors of a decoy. In particular, a social and travel behaviorpattern describes possibly different behaviors of a kind ofpeople on different days of a week. For example, many peopleusually go to work during weekdays, but stay at home or go tothe supermarket/theater on weekends. With this type of socialpattern, at the same time of 14:00, a person’s location may beat a company on Monday while at a supermarket on Sunday.Another example of social behavior pattern for hospital staffmay be a little different, whereby their work schedule mayinclude night shifts and weekends. In addition, social andtravel patterns may also need to include other factors suchas the travel mode since some people may prefer bicyclingfor short distance while some may just drive all the time.By composing different patterns and profiles, we can generaldifferent kinds of decoys. Figure 3 shows an example of asocial pattern for a decoy, and Figure 4 shows an example ofa decoy’s profile.

The decoy’s patterns and profiles can be obtained via variousmeans, such as user input, common knowledge or results from



Fig. 4. An Example of a Decoy’s Profile.

mining real trajectory datasets. In this work, we assume thata set of patterns and profiles are already been generated, andleave the pattern and profile generation in the future work.

D. Decoy Simulator

The decoy simulator component takes a set of social andtravel behavior patterns and personalized profiles as the inputsand then simulates a set of corresponding decoys. For eachdecoy, there are several steps to simulate its movements:

1) Initialization: In our system, a decoy is describedby a pair of pattern and profile. For example, as shownin Figures 3 and 4, the combination of “Pattern_student_0001”and “Profile_Alice” depicts a student Alice who is studying atNew York University (NYU). The decoy simulator will loadthe pattern and profile during the initialization phase.

2) State Transition: We model the movements of a decoyas a set of state transitions. For example, if the decoy Aliceleft home, went to NYU in the morning, and went to theSubway after class at noon, the states and transitions will thenbe “home,” “home → NYU,” “NYU,” “NYU → Subway,”“Subway”. Formally, we employ the probabilistic automatonto model the decoy’s transitions among different places:

Definition 3: A probabilistic automaton [44] is a tuple〈S,�, s, F, M〉, which describes a machine that is in one ofthe finite states at any given time, and whose state changesaccording to the transition probabilities with respect to asequence of input symbols:

• S = {s1, . . . , sn} defines a finite set of states.• � denotes a finite set of input symbols.• s denotes an initial state.• F defines a set of designated final states.• M defines the transition probability function from S × �

to [0, 1]n.In our system, the set of status S equals to SP (a set of

specific places defined by the decoy’s personalized profile),

Fig. 5. An Example of the State Transition Diagram.

and the status si indicates that a decoy is staying at a place i .As for now, the set � equals to {≥}, where “≥” indicates thatthe stay time of a decoy at a status is larger or equal to theestimated stay time t . If a decoy stays at home at the beginningof a day, the initial state s will be home. Since we mainly usethe probabilistic automaton to simulate the transition amongdifferent specific places (status) under different conditions(input symbols), the final states F in our system is set to anempty set.

Since the probability matrices in the decoy’s pattern onlydepict the transit probabilities among different types of places,to implement the probabilistic automation, we also need tocalculate the transition probabilities among a set of specificplaces. Let M(i, b, j) denote the probability that a decoytransits from the place (state) i to the place j when theinput symbol is b. Equations 1 and 2 show how to calculateM(i, b, j).

M(i, b, j) = {f (i, j) b = “ ≥ ”

} (1 ≤ i, j ≤ s,

b ∈ {≥}) (1)

For any i and j (1 ≤ i, j ≤ s), we have:

f (i, j) = Pw(t).PT ypei ,T ype j × SP j .Wsw (2)

where T ypei and T ype j are the types of place i and j ,respectively.

Now we can use the probabilistic automaton to simulate thetransitions of places. For example, if we want to simulate thedecoy’s movement at 10am on Friday (w = 5), we first retrievethe transition probability matrix from its pattern in Figure 3,which is the following:

P5(8 : 00 − 11 : 30).P =⎡⎣

0.2 0.6 0.20.8 0.1 0.10.5 0.0 0.5

⎤⎦

Given the above probability matrix which only describesthe transition probability between the place types, we fur-ther calculate the transition probabilities between the fiveexact places (as shown in Figure 4) that the decoy mayvisit. The transition probabilities are represented as M≥ andFigure 5 illustrates the probabilistic automaton constructed



Fig. 6. Comparison of Real Trajectories and Fake Trajectories.

based on M≥.

M≥ =

⎡⎢⎢⎢⎢⎣

0.2 0.6 0.1 0.0 0.10.8 0.1 0.05 0.0 0.050.5 0.0 0.25 0.0 0.250.5 0.0 0.25 0.0 0.250.5 0.0 0.25 0.0 0.25

⎤⎥⎥⎥⎥⎦

Each time the decoy arrives at a place with T ypei , the sim-ulator will generate its stay time tstay following the Gaussiandistribution and the parameters in its pattern component T ,as shown in Equation 3.

tstay = Gaussian(TT ypei .mean,TT ypei .dev) (3)

When the decoy stays at the place equals to or longer thantstay, the simulator will take “≥” as the input symbol to theprobabilistic automaton and find out the next place that thedecoy may visit.

3) Movement Simulation: From the previous state transitionphase, we obtain the places that the decoy will visit. Themovement simulation will generate the detailed path betweenthese places. A straightforward approach is to calculate theroutes between these places (stay points) and then choosethe positions along the routes. However, such an approachwill result in constant moving speed and precise positions,which may be easily identified as fake trajectories by attackers.Figure 6 illustrates this problem. Figure 6 (a) is a real user’sdaily trajectory recorded obtained from a smartphone’s GPS.Figure 6 (b) is a fake trajectory passing by the same stay pointsand is obtained using the aforementioned naive approach, fromwhich we can see that this fake trajectory is very smooth.

In order to make the decoy’s trajectory look similar to areal human’s trajectory, the movement simulation takes thefollowing steps:

a) Step 1 (Determine travel mode): The simulator willfirst calculate the distance d between the origin placei andthe destination place j , and then find the distance range in thetravel mode matrix M (Figure 3) that satisfies Mk .dis_min ≤d < Mk .dis_max or closest to d when d does not fall in anyrange. Next, based on the probabilities of each travel modewithin this distance range, i.e. Mk .Pd , Mk .Pt , Mk .Pb,and Mk .Pw, the simulator generates a travel mode for thedecoy. For example, if the distance between the decoy’s currentlocation to the next place is 4 km, the 2nd row in M willbe selected since its distance range is between 0.5 km and5 km. The corresponding probabilities for driving, publictransit system, bicycling, and walking are 0.4, 0.3, 0.2 and

0.1, respectively, which means the decoy may be more likelyto drive than to walk.

b) Step 2 (Obtain route): Once the travel mode m isdetermined, the simulator will send out a request using GoogleDirections API to obtain the route from (SP i .Lat,SP i .Lng)to (SP j .Lat,SP j .Lng) at the travel mode m. The obtainedroute includes the estimated travel time and a series ofsegments and timestamps. If no result could be returned bythe Google Directions API, the simulator will try a differenttravel mode such as driving until getting a route.

c) Step 3 (Speed obfuscation): Given the length and thetravel time of the segments returned by the Google DirectionsAPI, we can further calculate the moving speeds of thedecoy at these segments. However, the speeds obtained inthis way (denoted as Speedsegi ) may contain too manyconstant speeds for a sequence of continuous road segments,e.g., “60 km/h,” “60 km/h,” . . ., “60 km/h”. This does notlook like real human whose traveling speeds are never soconstant. Also, constant speeds form unique patterns that canbe easily caught by data mining tools. To simulate the decoy’smoving speed in a better way, we multiply Gaussian noiseγi = Gaussian(MBm .speed_ f,MBm .speed_dev) to thedirectly computed segment speed.

Decoy_Speedsegi = Speedsegi × γi ; (4)

d) Step 4 (Geographic position obfuscation): Not onlywe cannot use the speeds directly calculated from the opti-mal travel route as discussed above, we should not use theexact optimal route for the decoy either. This is becausereal GPS positions are never 100% accurate and trajecto-ries formed by real GPS positions are not as smooth asthe optimal route. To mimic the real human’s trajectory,we currently simulate the GPS accuracy rate based on thedecoy’s travel mode m, which could be extended to amore complicated model that includes weather conditionsor other factors. For each position on the optimal travelroute (denoted as pos = 〈lati tude, longi tude〉), we firstgenerate a GPS accuracy rate α = Gaussian(0, Gaussian(Gm .accuracy,Gm.accuracy_dev)). Then, we randomly gen-erate an angle β and add it to the position pos:

Decoy.lati tudei = posi .lati tude + α · sin(β)

Decoy.longi tudei = posi .longi tude + α · cos(β) (5)

Finally, the decoy’s positions are published at an intervalGm .update_t to simulate the GPS module which has differentupdating rates under different circumstances.

Figure 6 (c) shows the decoy’s trajectory obtained by ourapproach, where we can see that it behaves more like a realhuman than the optimal route in Figure 6 (b).

E. Request Interceptor

The request interceptor component is in charge of analyzinguser’s requests, mixing the real locations and the decoys’locations when sending out the location-based service requeststo the service providers. There are four steps to realize therequest interception:



1) Detect the location information leakage: The inter-ceptor checks each of the user’s service request. Thisis achieved by intercepting the requesting URL. Specifi-cally, we first override the function “shouldOverrideUrl-Loading” of class “WebViewClient” in Android, andthe function “shouldStartLoadWith” of class “UIWe-bView” in iOS. We define a set of regex (RegularExpressions) rules to detect if a URL contains loca-tion information. For example, if the requesting URLis “https://abc.xyz/key=ab&lat=34.123&lng=-91.456,”our defined regex rule “lat=(.*?)&lng=(.*?)” will beable to extract the latitude and longitude in this URL.If it is confirmed that the requesting URL contains theuser’s location information, the interceptor will ask theservice monitor to keep a record of the location usageand invoke the following decoys’ request generation.

2) Generate decoys’ requests: The interceptor obtainsdecoys’ current locations from the decoy simulator,and then generates service requests for the decoysin the same form of the user’s real service request.For example, if the user is looking for nearbyItalian restaurants, and the requesting URL is“https://abc.xyz/food/italian/lat=34.123&lng=-91.456,”the requests from the decoys will also be looking forrestaurants near the decoys’ locations but the restaurants’types may be different such as Mexican restaurants.For example, the decoy’s requesting URL would be“https://abc.xyz/food/mexican/lat=40.12&lng=-80.34”.

3) Send out mixed requests: After generating thedecoys’ requests, the interceptor mixes them withthe real user’s request and send all the requestsout to the service provider by calling the function“decoyWebView_i.loadUrl(decoyUrl_i)” and “mainWe-bView.loadUrl(userUrl)”.

4) Filter returned responses: Upon receiving theresponses from the service provider, the query resultscorresponding to the user’s real request will be displayedin the main webview to the user. The responses that arerelated to the decoys’ requests will return to the decoys’webviews which will be invisible to the user unless theuser wants to monitor the decoys’ activities and clicksa switch button in our interface to switch to the decoys’query result page.

With the support of the decoy simulator component,the request interceptor can act as a middle ware betweenthe user and the service provider to protect user’s locationprivacy without reducing the quality of service. It is worthnoting that all the APIs, functions, and UI elements usedby this component are officially supported by both Androidand iOS platforms. Therefore, the user can install and useour MoveWithMe app just like other apps, without changing,re-compiling any existing framework or gaining any “root”access of the mobile devices.

F. Service Monitor

Upon receiving the detection results from the request inter-ceptor, the service monitor component will first inform the

Fig. 7. Service Monitor.

user when his/her location information is being requested bythe service provider. Meanwhile, it will keep the record ofthese accesses. Specifically, when the user taps the “ServiceMonitor” button on the phone screen, our app will display alist of the current services that require location information.For example, Figure 7 (a) shows the notification that thewebsite is uploading user’s precise geo-location information,and Figure 7 (b) shows the services a user has visited andthe corresponding types of location information that havebeen uploaded to the service providers. The purpose of thesetwo additional features aims to draw user’s attention to thelocation-based services that have collected their location infor-mation, and let the users be aware of potential privacy risksthat they may not notice before.

G. Location Recorder

The location recorder component is currently in charge ofstoring the user’s real trajectories and decoys’ fake trajectories.

A potential usage of these stored historical trajectories is toprovide flexible and adaptive privacy protection. Specifically,the system can present a report about the similarity betweenthe trajectories of a decoy (decoyi) and the user u to the user.Based on the user’s input, the decoys’ social and travel patternsand profiles may be changed to reach the desired similarity,i.e., adjust decoys’ profiles to make decoys perform more (orless) similar to the user. There are several ways to do thesimilarity calculation. For example, we can directly comparethe types of places visited by a decoy with that of the realuser; or we can consider also the stay time and transition timeduring the comparison. This feature is optional and can beturned off without affecting the other functions. In this paper,since we focus on the simulation of decoys and the requestintercepting, we leave the details of the similarity calculationand the adjustment of decoys’ profiles as the future work.

H. Trajectory Display

The trajectory display component aims to help users visual-ize their real trajectories as well as decoys’ trajectories. In thissense, the users may possibly feel more secure.



We utilize the Google Maps API to display trajectories.When viewing the trace, the users’ real location will beautomatically placed with a blue map-marker and lines, so thatusers can visualize the other reported locations comparedto their origins. Lines with different colors are connectinglocations based on the movement from one place to the next.An example of this trajectory display feature is presentedin Figure 9 in the experimental section.

IV. PRIVACY ANALYSIS

We now discuss the privacy protection achieved by ourproposed MoveWithMe system. Recall that in the threatmodel (Section III-A), we consider two types of user locationinformation: (i) precise location such as coordinates providedby GPS; (ii) coarse location such as postal code. Serviceproviders may utilize collected location information to learnthe user’s sensitive information. The more precise the locationis and the more frequent the user accesses the same service,the respective service provider would have more chances toinfer the user’s personal information such as hobbies, religions,health status, and political stance.

With the aid of our proposed MoveWithMe system, the userwill be able to prevent the service provider (or attackers whocompromise the server) from knowing his/her true profile. Thisis because the user’s service requests are now accompaniedby a group of decoys’ service requests. More importantly,these decoys have different patterns and profiles (e.g., dailyschedule, personal interests, living city) from the real user. Forexample, if the real user is a student, one decoy may behavelike a full-time worker in Las Angeles, another decoy maybe a part-time worker moving in Toronto, Canada. Moreover,our decoys behave like the real human so that even advanceddata mining tools cannot tell which trajectory belongs to adecoy (as shown in our experiments). As a result, the serviceprovider will receive seemly multiple users’ service requestsand hard to tell what are the real users’ true interests.

It is worth mentioning that for the users to gain such privacyprotection from the MoveWithMe system, they need to connectto the Internet via certain VPN or anonymity network TORso that the service provider cannot identify the users’ reallocations by analyzing the original IP address. Also, the usersshould not directly use the location-based services to consumethird-party services, such as reserving a restaurant throughthe TripAdvisor’s website, which would lead the users’ truelocations since decoys are not allowed to purchase anything.Users are suggested to only use the location-based services tobrowse the needed services, and then directly go to the websiteof the desired service for the purchasing operations.

V. EXPERIMENTAL STUDY

We have implemented the proposed MoveWithMe system asmobile apps both in Android 6.0 and iOS 11.3, and conducteda series of experiments to evaluate the effectiveness andefficiency of the system. In terms of effectiveness, we examinethree aspects: (i) we tested various location-based services tosee if the requests generated from decoys are also receivedand responded by the service providers; (ii) we check if the

TABLE I

LOCATION-BASED SERVICES TESTED

decoys’ trajectories are consistent with the designated socialpatterns as time evolves; (iii) we utilize data mining toolsto see if fake trajectories can be identified out of the realtrajectories. In terms of efficiency, we measure the responsetime taken for the user to receive the original location-basedservice with and without the MoveWithMe app. The devicesused for testing include a Samsung Galaxy S4, a SamsungGalaxy S6, a Google Nexus 5X, and an iPhone 7. Unlessnoted, the results are from Google Nexus 5X.

A. Effectiveness Testing

In the first round of experiments, we evaluate the effective-ness of the MoveWithMe app when the user is visiting thepopular location-based services as shown in Table I. Thesewebsites can be classified into three categories. The firstcategory of the websites needs the user’s precise geolocationinformation (latitude and longitude) to perform the services,such as Yelp, TripAdvisor, and Google Arts & Culture.The second category of the websites would submit the user’saddress information, such as Airbnb and Aol. Weather. Thethird category of websites such as KFC and Movietickets usethe postal code to locate the user.

In the experiments, we first use our MoveWithMe app totest whether or not the above websites receive the real user’slocation and the decoy’s locations. The real user’s location isin Rolla, MO. Figure 8 (b), (c), and (d) shows the query resultsfrom the Yelp when the user inquiries nearby restaurants.We can see that these query results are not restaurants near theuser’s real location (i.e., Rolla), but the results with respect tothe decoys’ locations at Chicago, Kansas, and Atlanta. Thatmeans MoveWithMe has successfully fed fake locations toYelp. Note that the requests of those decoys are performedin the background automatically. For the user, he/she willbrowse the Yelp website in the foreground as usual withoutany interruption. As presented in Figure 8 (a), the userwill obtain the restaurant information regarding his/her reallocation. Similarly, in Figure 8 (e), the user is searching fornearby things to do in Rolla using an iOS device. As presentedin Figure 8 (f), the first decoy in Chicago is querying things todo at the same time. We observe the similar performance ofMoveWithMe for other websites that provide location-basedservices. Due to the space constraints, we do not include thescreenshots here.



Fig. 8. Effectiveness Testing.

Next, we run the MoveWithMe system for a whole dayand compare the historical trajectories of the real user anddecoys. Figure 9 (a) and (b) show the results. We can see thatit is hard to tell which trajectory is fake since the decoy alsofollows the speed limit, the human’s schedule like lunch breakand going back home at night. In addition, we also observethat the decoy’s movement pattern is quite different from theuser, which means the MoveWithMe app can effectively helpprevent the service provider from profiling the user.

After that, we test if the fake trajectories generated by theMoveWithMe app can prevent the data mining tools’ detection

Fig. 9. Historical Traces of Decoys and the Real User.

Fig. 10. Trajectory Classification Precision.

more effectively than other randomly generated dummies.We select three commonly used data mining algorithms:DecisionTree, KNN, and GaussionProcesses. Each algorithmis trained by using 1000 real trajectories extracted from theGeoLife trajectory dataset [45]–[47] and 1000 fake trajectoriesfrom our MoveWithMe app. For each trajectory, n samplepoints are randomly selected to simulate the number of dailyvisit to the same service provider. The features used fortraining include various aspects of a trajectory, which arethe minimum segment length, the maximum segment length,the average segment length, the minimum speed, the maxspeed, the average speed, and the standard deviation of speed.For comparison, we also generate another set of fake trajec-tories that are formed by randomly selected locations aroundthe real locations in the GeoLife trajectories with less than1km distance deviation. During the testing, we mix 500 realGeoLife trajectories with 500 fake trajectories.

As shown in Figure 10, the detection rate of randomlygenerated dummy trajectories is also very high (around 95%).This is because the moving patterns of the random dummiesare much different from real humans. Compared to randomdummies, the decoys generated by our MoveWithMe systemare much harder to be correctly classified by the data miningalgorithm. The detection accuracy of our decoys is only around60% to 70%, slightly higher than a random guess (50%). Notethat this detection rate is achieved when we give the serviceprovider advantages by assuming that they have correctlylabeled 1000 of our decoy trajectories as fake trajectories



Fig. 11. Response Time.

during the training. When the service provider uses the randomdummies for training, their ability of detecting our decoysdrops to 45%.

More formally, let k be the number of decoys in theMoveWithMe app, and p be the accuracy of the real trajectoryclassification. We can calculate the possibility for the serviceprovider to precisely distinguish the real trajectory and ruleout the fake trajectories as P = pk+1. For example, even ifp equals to 70% while k equals to 10, the chance for theservice provider to precisely distinguish the real trajectoryis only 1.98%. This demonstrates that our MoveWithMecan effectively protect user’s location privacy even when theservice provider is trying to identify the real trajectories usingadvanced data mining tools. In addition, we also vary thenumber of daily visits to the same service provider from25 to 200 (denoted by the number under the algorithm namein the figure). When there are fewer daily visits (e.g., 25),the detection rate is lower. The reason is straightforward thatthe less frequent use of the same service, the less locationinformation the service provider will collect from the user.

B. Response Time Testing

The second round of experiments aims to evaluate theresponse time of the proposed MoveWithMe app. We vary thenumber of decoys (the value of k) from 0 to 5 (k = 0 meansaccessing location-based services without our MoveWithMeapp’s protection). In each instance of a run, we perform10 different queries and record the response time for eachquery. Then, we calculate the average response time of the10 queries.

Figure 11 reports the average response time with respectto each service and the aggregated average response time ofall the services (denoted as “AVE.”). From the figure, we canobserve that the response time of the services slightly increaseswith the increase in the number of decoys. This is becausethe requests sent by decoys in the background take a bit ofbandwidth. Since the decoys do not need to download theimages and videos when sending requests, the impact on theresponse time is still negligible. Overall, the wait time issimilar to the wait time for connecting a phone call, and hencewe expect it to be acceptable for users who care about theirlocation privacy. The minor fluctuation among the responsetime is mainly caused by the continuous generation of decoys’locations.

Fig. 12. Response Time on Different Smartphones.

We also compare the time performance of MoveWithMeapp running in four different brands of smartphones: SamsungGalaxy S4, Samsung Galaxy S6, Google Nexus 5X, andiPhone 7. Figure 12 shows the average response time for eachservice when there is 0 decoy (k = 0) and 5 decoys (k = 5),respectively. We can see that the MoveWithMe app incurs verylittle delay for all the services tested. Note that the differencein the response time among different services is mainly causedby the network condition and the service providers’ servers.

C. Network Data Usage Testing

The third round of experiments aims to evaluate networkdata usage. We tested two scenarios. In the first scenario,we simulate the user’s daily activities. For each round in thefirst scenario, we search nearby bars, banks and gas stationsin Yelp, restaurants and ’things to do’ in TripAdvisor, hotelsin Hotels.com, museums in Google Arts & Culture, stores inMcDonald’s, and then search movies and theaters in MovieT-ickets. In the second scenario, we refresh the lists of coffee andtea in Yelp, restaurants in TripAdvisor, stores in McDonald’s,and theaters in MovieTickets 10 times respectively, and recordthe data usage.

As presented in Figure 13, since the decoys need to forgemultiple requests related to their locations while the user isbrowsing the location-based service websites at the same time,it is not surprising to see that the data usage increases withthe increase of k (the number of decoys). However, the extranetwork data usage is very little, which is only 10% morein the first scenario and 18% more in the second scenariowhile k equals to 5. This is because the decoys do not need



Fig. 13. Network Data Usage.

Fig. 14. Battery Consumption (Running in the Background).

to download the images and other large files when sendingrequests. The service requests from decoys are mainly textcontents which do not consume much bandwidth.

D. Battery Consumption Testing

In the end, we study how the MoveWithMe app affects thebattery consumption of smartphones. We tested two differentscenarios. In the first scenario, we compare the total batteryconsumption with and without running our MoveWithMeapp for a duration of 60 minutes. Note that even runningin the background, our MoveWithMe app is still generatingseveral decoys’ locations continuously to prepare for the useat any time. As presented in Figure 14, our MoveWithMeapp consumes only 0.5% more battery at the end of the60 minutes of testing (k = 5). The experimental resultsindicate that MoveWithMe’s decoy simulation algorithm isvery efficient. Recall that the decoys’ profiles only need tobe generated once and then the follow-up generation of fakelocations is fast.

In the second scenario, we compare the battery consumptionwith (k>0) and without (k = 0) the MoveWithMe app’s pro-tection. Specifically, in a time period of 60 minutes, we sim-ulate 10 rounds of user access to each service, i.e., browsingall the nine service websites every 6 minutes. Figure 15reports the battery consumption results. As expected, with theMoveWithMe app running, the smartphone consumes energyslightly faster than just browsing location-based websites with-out MoveWithMe. However, the additional battery needed forthe MoveWithMe app (k = 5) is less than 4%, which is almostnegligible and hard to be noticed by the user. The same patternis demonstrated for other smartphones as shown in Figure 16.

VI. DISCUSSION

Although the analysis and experimental results demon-strate the practicability, effectiveness and efficiency of the

Fig. 15. Battery Consumption (Browsing Websites in the Foreground).

Fig. 16. Battery Consumption on Different Devices.

MoveWithMe system, there are still several limitations of theproposed system as discussed below.

One limitation of the MoveWithMe system is that it relies onthe VPN (or TOR) services to hide the user’s real IP addressesfrom the service providers and adversaries. If the user turnsoff the VPN service when using the location-based services,a short-term exposure may not cause privacy leakage becausethe adversary will not know if this exposed IP address is theuser’s real IP address or just another one provided by the VPN.If the disconnection to the VPN frequently occur at the sametime when the user accesses the location-based services, it islikely that the adversary will be able to distinguish the user’sreal IP address from previous received VPN’s addresses.

The current version of MoveWithMe system can onlyprotect user’s location privacy while he/she is accessinglocation-based service websites. Theoretically, the Move-WithMe can act as a middleware to provide location privacyprotection for mobile application as well. However, to interceptthe requests sent out by APPs, we have to gain the “root”access of the mobile devices, which is not an easy job fornormal users and may introduce additional security risks.

VII. CONCLUSION

In this paper, we present a novel location privacy-preservingmobile app–MoveWithMe–to help smartphone users protecttheir location privacy when they need to frequently exposetheir locations to location-based services. MoveWithMe canbe easily installed as other common apps without rootingthe device. The MoveWithMe system performs a sophisti-cated decoy simulation algorithm and automatically generatesdecoys at the runtime and sends service requests along withthe user’s real request to the service providers. Our proposedalgorithm ensures that these decoys act consistently like realhuman beings as time passes, making it very hard for theservice provider to identify the real user from the group ofdecoys and profile the real user even by using advanced data



mining technologies. By evaluating the prototypes of the pro-posed MoveWithMe system against a variety of location-basedservices on various smartphones, we found that the Move-WithMe system is very effective and introduces very littleoverhead on the response time, network data usage, and batteryconsumption. It is believed that by using our system, users willbe able to gain greater privacy when accessing location-basedservices while still enjoying their full utilities.

REFERENCES

[1] K. Fawaz and K. G. Shin, “Location privacy protection for smart-phone users,” in Proc. ACM SIGSAC Conf. Comput. Commun. Secur.,Nov. 2014, pp. 239–250.

[2] K. Fawaz, H. Feng, and K. G. Shin, “Anatomization and protection ofmobile Apps’ location privacy threats,” in Proc. Secur. Symp. USENIX,Feb. 2015, pp. 753–768.

[3] B. Niu, Q. Li, X. Zhu, G. Cao, and H. Li, “Achieving k-anonymityin privacy-aware location-based services,” in Proc. IEEE INFOCOM,May 2014, pp. 754–762.

[4] P.-R. Lei, W.-C. Peng, I.-J. Su, and C.-P. Chang, “Dummy-basedschemes for protecting movement trajectories,” J. Inf. Sci. Eng., vol. 28,no. 2, pp. 335–350, 2012.

[5] T. Hara, A. Suzuki, M. Iwata, Y. Arase, and X. Xie, “Dummy-baseduser location anonymization under real-world constraints,” IEEE Access,vol. 4, pp. 673–687, 2016.

[6] T. Wang et al., “Trajectory privacy preservation based on a fog structurefor cloud location services,” IEEE Access, vol. 5, pp. 7692–7701,2017.

[7] S. Hayashida, D. Amagata, T. Hara, and X. Xie, “Dummy generationbased on user-movement estimation for location privacy protection,”IEEE Access, vol. 6, pp. 22958–22969, 2018.

[8] M. Gruteser and D. Grunwald, “Anonymous usage of location-basedservices through spatial and temporal cloaking,” in Proc. 1st Int. Conf.Mobile Syst., Appl. Services, May 2003, pp. 31–42.

[9] R. Cheng, Y. Zhang, E. Bertino, and S. Prabhakar, “Preserving userlocation privacy in mobile data management infrastructures,” in Proc.Int. Workshop Privacy Enhancing Technol., Jun. 2006, pp. 393–412.

[10] M. F. Mokbel, C.-Y. Chow, and W. G. Aref, “The new Casper: Queryprocessing for location services without compromising privacy,” in Proc.32nd Int. Conf. Very Large, Sep. 2006, pp. 763–774.

[11] T. Xu and Y. Cai, “Feeling-based location privacy protection forlocation-based services,” in Proc. 16th ACM Conf. Comput. Commun.Secur., Nov. 2009, pp. 348–357.

[12] M. K. Domenic, Y. Wang, F. Zhang, I. Memon, and Y. H. Gustav,“Preserving users’ privacy for continuous query services in road net-works,” in Proc. 6th Int. Conf. Inf. Manage., Innov. Manage. Ind. Eng.,Nov. 2013, pp. 352–355.

[13] X. Ju and K. G. Shin, “Location privacy protection for smartphone usersusing quadtree entropy maps,” J. Inf. Privacy Secur., vol. 11, no. 2,pp. 62–79, 2015.

[14] F. Abbas and H. Oh, “A step towards user privacy while using location-based services,” JIPS, vol. 10, no. 4, pp. 618–627, 2014.

[15] D. Lin, E. Bertino, R. Cheng, and S. Prabhakar, “Location privacy inmoving-object environments,” Trans. Data Privacy, vol. 2, pp. 21–46,Apr. 2009.

[16] M. E. Andrés, N. E. Bordenabe, K. Chatzikokolakis, and C. Palamidessi,“Geo-indistinguishability: Differential privacy for location-based sys-tems,” Feb. 2012, arXiv:1212.1984. [Online]. Available: https://arxiv.org/abs/1212.1984

[17] Z. Chen, X. Hu, X. Ju, and K. G. Shin, “LISA: Location informationScrAmbler for privacy protection on smartphones,” in Proc. IEEE Conf.Commun. Netw. Secur. (CNS), Oct. 2013, pp. 296–304.

[18] Q. Xiao et al., “POSTER: LocMask: A location privacy protectionframework in Android system,” in Proc. ACM SIGSAC Conf. Comput.Commun. Secur., Nov. 2014, pp. 1526–1528.

[19] H. Ngo and J. Kim, “Location privacy via differential private perturba-tion of cloaking area,” in Proc. IEEE 28th Comput. Secur. Found. Symp.,Jul. 2015, pp. 63–74.

[20] L. Wang, D. Yang, X. Han, T. Wang, D. Zhang, and X. Ma, “Locationprivacy-preserving task allocation for mobile crowdsensing with dif-ferential Geo-obfuscation,” in Proc. 26th Int. Conf. World Wide Web,Apr. 2017, pp. 627–636.

[21] W. Wang and Q. Zhang, “A stochastic game for privacy preservingcontext sensing on mobile phone,” in Proc. IEEE INFOCOM, May 2014,pp. 2328–2336.

[22] G. Ghinita, P. Kalnis, A. Khoshgozaran, C. Shahabi, and K.-L. Tan,“Private queries in location based services: Anonymizers are not nec-essary,” in Proc. ACM SIGMOD Int. Conf. Manage. Data, Jun. 2008,pp. 121–132.

[23] K. P. N. Puttaswamy and B. Y. Zhao, “Preserving privacy in location-based mobile social applications,” in Proc. 11th Workshop MobileComput. Syst. Appl., Feb. 2010, pp. 1–6.

[24] Y. Huang, P. Chapman, and D. Evans, “Privacy-preserving applicationson smartphones,” in Proc. HotSec, Feb. 2011, p. 4.

[25] W. Wei, F. Xu, and Q. Li, “MobiShare: Flexible privacy-preservinglocation sharing in mobile online social networks,” in Proc. IEEEINFOCOM, Mar. 2012, pp. 2616–2620.

[26] S. Guha, M. Jain, and V. N. Padmanabhan, “Koi: A location-privacyplatform for smartphone apps,” in Proc. 9th USENIX Conf. NetworkedSyst. Design Implement., Apr. 2012, p. 14.

[27] X.-Y. Li and T. Jung, “Search me if you can: Privacy-preserving locationquery service,” in Proc. IEEE INFOCOM, Apr. 2013, pp. 2760–2768.

[28] K. P. N. Puttaswamy et al., “Preserving location privacy in geosocialapplications,” IEEE Trans. Mobile Comput., vol. 13, no. 1, pp. 159–173,Jan. 2014.

[29] R. Paulet, M. G. Kaosar, X. Yi, and E. Bertino, “Privacy-preserving andcontent-protecting location based queries,” IEEE Trans. Knowl. DataEng., vol. 26, no. 5, pp. 1200–1210, May 2014.

[30] H. Zhu, F. Liu, and H. Li, “Efficient and privacy-preserving polygonsspatial query framework for location-based services,” IEEE InternetThings J., vol. 4, no. 2, pp. 536–545, Apr. 2017.

[31] A. Patel and E. Palomar, “Privacy preservation in location-based mobileapplications: Research directions,” in Proc. 9th Int. Conf. Availability,Rel. Secur., Sep. 2014, pp. 227–233.

[32] B. Niu, X. Zhu, H. Chi, and H. Li, “3PLUS: Privacy-preserving pseudo-location updating system in location-based services,” in Proc. IEEEWireless Commun. Netw. Conf. (WCNC), Apr. 2013, pp. 4564–4569.

[33] M. Xue, Y. Liu, K. W. Ross, and H. Qian, “I know where youare: Thwarting privacy protection in location-based social discoveryservices,” in Proc. IEEE Conf. Comput. Commun. Workshops, May 2015,pp. 179–184.

[34] H. Zhang, Z. Xu, X. Yu, and X. Du, “LPPS: Location privacy protectionfor smartphones,” in Proc. IEEE Int. Conf. Commun. (ICC), May 2016,pp. 1–6.

[35] F. Fei, S. Li, H. Dai, C. Hu, W. Dou, and Q. Ni, “A K-anonymitybased schema for location privacy preservation,” IEEE Trans. Sustain.Comput., vol. 4, no. 2, pp. 156–167, Jun. 2017.

[36] L. Zhang, Z. Cai, and X. Wang, “FakeMask: A novel privacy preservingapproach for smartphones,” IEEE Trans. Netw. Service Manage., vol. 13,no. 2, pp. 335–348, Jun. 2016.

[37] H. Liu, X. Li, H. Li, J. Ma, and X. Ma, “Spatiotemporal correlation-aware dummy-based privacy protection scheme for location-based ser-vices,” in Proc. IEEE INFOCOM, May 2017, pp. 1–9.

[38] H. Li, H. Zhu, S. Du, X. Liang, and X. S. Shen, “Privacy leakageof location sharing in mobile social networks: Attacks and defense,”IEEE Trans. Dependable Secure Comput., vol. 15, no. 4, pp. 646–660,Aug. 2018.

[39] P. Hornyack, S. Han, J. Jung, S. Schechter, and D. Wetherall, “Thesearen’t the droids you’re looking for: Retrofitting Android to protectdata from imperious applications,” in Proc. 18th ACM Conf. Comput.Commun. Secur., Oct. 2011, pp. 639–652.

[40] R. Shokri, G. Theodorakopoulos, P. Papadimitratos, E. Kazemi, andJ. P. Hubaux, “Hiding in the mobile crowd: Locationprivacy throughcollaboration,” IEEE Trans. Dependable Secure Comput., vol. 11, no. 3,pp. 266–279, Jun. 2014.

[41] J. Achara, C. Castelluccia, J.-D. Lefruit, V. Roca, F. Baudot, andG. Delcroix, “Mobilitics: Analyzing privacy leaks in smartphones,”in Proc. ERCIM, Oct. 2013, pp. 1–60.

[42] D. Steiert, D. Lin, Q. Conduff, and W. Jiang, “Poster: A location-privacyapproach for continuous queries,” in Proc. 22nd ACM Symp. AccessControl Models Technol., Jun. 2017, pp. 115–117.

[43] Y. Liang, Z. Cai, Q. Han, and Y. Li, “Location privacyleakage through sensory data,” Secur. Commun. Netw.,vol. 2017, Mar. 2017, Art. no. 7576307. [Online]. Available:https://www.hindawi.com/journals/scn/2017/7576307/abs/

[44] M. O. Rabin, “Probabilistic automata,” Inf. Control, vol. 6, no. 3,pp. 230–245, Sep. 1963.

[45] Y. Zheng, L. Zhang, X. Xie, and W.-Y. Ma, “Mining interesting locationsand travel sequences from GPS trajectories,” in Proc. 18th Int. Conf.World Wide Web, Apr. 2009, pp. 791–800.

[46] Y. Zheng, Q. Li, Y. Chen, X. Xie, and W.-Y. Ma, “Understandingmobility based on GPS data,” in Proc. 10th Int. Conf. UbiquitousComput., Sep. 2008, pp. 312–321.

[47] Y. Zheng, X. Xie, and W.-Y. Ma, “GeoLife: A collaborative socialnetworking service among user, location and trajectory,” IEEE Data Eng.Bull., vol. 33, no. 2, pp. 32–39, Jun. 2010.


movewithme: location privacy preservation for smartphone...

Documents