1

Analysis of Location Data Leakage in the InternetTraffic of Android-based Mobile Devices

Nir Sivan, Ron Bitton, Asaf ShabtaiDepartment of Software and Information Systems Engineering

Ben-Gurion University of the NegevBeer-Sheva, 8410501, Israel

{sivanni,ronbit}@post.bgu.ac.il, shabtaia@bgu.ac.il

Abstract—In recent years we have witnessed a shift towardspersonalized, context-based applications and services for mobiledevice users. A key component of many of these services is theability to infer the current location and predict the future locationof users based on location sensors embedded in the devices.Such knowledge enables service providers to present relevant andtimely offers to their users and better manage traffic congestioncontrol, thus increasing customer satisfaction and engagement.However, such services suffer from location data leakage whichhas become one of today’s most concerning privacy issues forsmartphone users. In this paper we focus specifically on locationdata that is exposed by Android applications via Internet networktraffic in plaintext (i.e., without encryption) without the user’sawareness. We present an empirical evaluation, involving thenetwork traffic of real mobile device users, aimed at: (1) mea-suring the extent of location data leakage in the Internet trafficof Android-based smartphone devices; and (2) understanding thevalue of this data by inferring users’ points of interests (POIs).This was achieved by analyzing the Internet traffic recorded fromthe smartphones of a group of 71 participants for an averageperiod of 37 days. We also propose a procedure for miningand filtering location data from raw network traffic and utilizegeolocation clustering methods to infer users’ POIs. The keyfindings of this research center on the extent of this phenomenonin terms of both ubiquity and severity; we found that over 85%of devices of users are leaking location data, and the exposurerate of users’ POIs, derived from the relatively sparse leakageindicators, is around 61%.

I. INTRODUCTION

In recent years, there has been a trend towards the person-alization of services in many areas. This is particularly truefor services provided on mobile devices, where a plethora ofcontext-based applications (for example, Yelp, Uber, GoogleMaps, and Google Now) are used daily by millions of people.These devices possess a tremendous amount of private infor-mation, ranging from users’ personal and financial data to theirlocation data, making such devices the target of commercialentities and intelligence gathering. A key property of manyof these services is the ability to understand the users’ currentlocation, infer points of interest, and predict the future locationof users based on location sensors embedded in the devices.Such knowledge enables service providers to present relevantand timely services (such as navigation recommendations,weather forecasts, advertisements, social networks, etc.) totheir users, thus increasing customer satisfaction and engage-ment. Methods for deriving the location of a mobile devicecan be categorized into the following two approaches:

• Host-based: In this approach, an installed applicationcan infer the location of the device by probing built-insensors or evaluating data provided when a user checksin to a place on social media. Local sensors that canprovide location data include hotspot (Wi-Fi) informationsuch as the SSID and BSSID [1], connected cellular, aswell as GPS [2]. The location can also be inferred byusing various side-channel attacks such as power supplyvariance analysis [3].

• Network-based: In this approach, the location of themobile device can be derived by using cell tower tri-angulation [4] (i.e., using radio-location by analyzingsignals received by the cell towers the device is connectedto). This requires high privileged access to the data,which is usually available to service providers and lawenforcement agencies.

In order to utilize location traces as a meaningful informa-tion source, it is imperative to analyze the data and aggregateit to location clusters that are important to the user, such ashome, shopping, or work [2]. These locations are also knownas the users’ points of interest (POIs). The most commonapproach for inferring a user’s POIs from location traces is byclustering the location traces by distance and time thresholds;eventually, a cluster will be produced if the user has stayedin the same place for a sufficient amount of time. POIs areidentified by understanding which clusters are important tothe user and omitting less important data such as transit data[5][6].

Location data collected on the host (mobile device) maybe provided to third party services by applications or leakedby a malicious application [7]. Recent works have reported ahigh rate of personal data leakage by popular applications overinsecure communication channels without users’ awareness.These studies also showed that location data is one of the most”popular” leaked personally identifiable information (PII), as10% of the most popular applications leak location data inplain text [7]. In fact, according to Trend Micro, the locationpermission was identified as the most abused Android applica-tion permission.1 This privacy breach was also acknowledgedduring the 2018 DEFCON workshops, when applications of

1http://about-threats.trendmicro.com/us/library/image-gallery/12-most-abused-android-app-permissions

arX

iv:1

812.

0482

9v1

[cs

.CR

] 1

2 D

ec 2

018

2

both iOS and Android-based devices were detected sendingaccurate location data in unencrypted formats.2

In this research, we investigate the phenomenon of locationdata leakage in the Internet traffic of Android based smart-phones. The main goals of this research are as follows:

1) Understanding the amount and quality of location leak-age detected in plain text in the device’s network traffic.

2) Analyzing the location leaks in order to infer the user’sPOIs. This task is not trivial due to the fact that thevast majority of the previously proposed POI detectionmethods assume a consistent and high rate of locationsampling (e.g., GPS); therefore, they cannot be directlyapplied on noisy and sparse location data, such as thedata we focus on in this study (i.e., location data leakedover mobile device network traffic).

3) Understanding the privacy exposure level of users interms of the number of identified POIs, amount ofdata required for identifying the POIs, accuracy of thedetected POIs, and time spent in the POIs.

In order to achieve these goals, we collected and analyzedthe Internet traffic of 71 smartphone users for an average of 37days, while the devices were being used routinely. In addition,we collected the location of the mobile devices by using adedicated Android agent (application) that was installed on thedevices and sampled the location sensor. The data collected bythe agent was used as the ground truth for the actual locationof the mobile device.

In summary the contributions of this paper are as follows:1) we explore and discuss the scope, volume and quality

of location-based data leaked via insecure, unencryptednetwork traffic (i.e., as plaintext) of smart mobile de-vices.

2) we conduct an empirical evaluation based on real datafrom mobile devices.

3) the evaluation involves a unique dataset that wascollected simultaneously from the device itself andthe network traffic sent from the device; such adataset from real users’ devices is very difficult toobtain.3

4) we present a methodological process for collecting,processing, and filtering location-based data from mobiledevices in order to infer the users’ POIs.

5) to the best of our knowledge, we are the first to usePOI clustering on a sparse, inconsistent data stream bymodifying available clustering algorithms, and discussthe experiments results and the effectiveness of theapplied process.

The rest of this paper is organized as follows. In Section IIwe summarize previous related work in the domains of dataleakage in mobile devices and inferring points of interest fromlocation traces. In Section III we describe the assumed threatmodel, and in Section IV we present the data collection frame-work and the data collection process used in this research, as

2https://arstechnica.com/information-technology/2018/09/dozens-of-ios-apps-surreptitiously-share-user-location-data-with-tracking-firms/

3we currently in the process of getting the required permissions for makingthe anonymized dataset publicly available for research.

well as privacy and ethical considerations. Section V containsour analysis of the location traces extracted from the capturedraw network traffic and Section VI includes an analysis ofinferred points of interest from the leaked location traces. InSection VII we discuss the challenge of identifying the leakingapplication and possible mitigation strategies, and finally, inSection VIII we conclude with a discussion of the paper’scontributions and introduce possible directions for future work.

II. RELATED WORK

A. Data leakage in mobile devices

According to the GDPR definition [8], personal data orpersonally identifiable information (PII) is any data that canbe used to identify a person, including name, ID, social mediaidentity and location. PII leaks are a major privacy concern formobile devices users. Along with device and user identifiers,location leakage is among the private data most commonlyand extensively leaked from mobile devices [7]. Furthermore,location permission is a very popular permission requested bymost mobile apps (25% of apps use precise location, and aneven greater number of apps use coarse location) [9].

Without accurate knowledge about how each app uses andhandles its location permissions, access of apps to locationAPI pose a real threat to users’ privacy.

There are several ways to abuse network traffic access inorder to disclose users’ personal information. For example,one attack model is based on monitoring the network flowbehavior and uses machine learning methods to reveal useractions, an approach that is effective even if the traffic isencrypted [10]. Prior research has also shown that by sniffingthe network traffic of well-known and heavily downloadedapps, an attacker can obtain (leak) a broad spectrum ofpersonal and device identifying information without the user’sawareness [11]. The protocol used to transfer PIIs may bevulnerable to cyber attacks and thus can also be a privacybreach regardless of user awareness. As a case in point, Renet al. [12] presenedt a review on data leakage in mobile appsby an unsecured HTTP protocol which can be used to identifythe user.

B. Inferring meaningful locations

Inferring meaningful locations from aggregated locationtraces is a field of research that has rapidly evolved sincethe appearance of cheap mobile GPS devices for civilian use.These devices, as well as smartphones (in the proper navi-gation and sampling mode) which have become ubiquitous,have a high and constant sampling rate; the availability of aconstant data stream is a common assumption for most studiesin location analytics. Inferring meaningful locations reliesupon several major algorithm families: Ester et al. introducedDBSCAN [13], which is a density-based algorithm for spatialdata, which provides the ability to determine clusters withundefined shapes and is not bound to a specific number ofclusters, and does not use temporal data as a parameter. Birantet al. extended DBSCAN into ST-DBSCAN [14], which notonly uses the spatial data of the database points but also

3

uses its temporal data which is more suitable for spatio-temporal data sets. Another approach introduced by Kang etal. [5] clusters places based on time and distance thresholdsto determine stay points from transit to improve analysis oftrajectories; in the current research we refer to this methodas the ”incremental method.” Kang et al. [5] used predefinedconstraints in order to prevent incorrect clustering due tomissing information between traces. Montoliu et al. [15] alsodeal with inconsistency and missing data by adding maximumtime constraints between traces’ constraints. Alvares et al. [16]proposed the use of semantic data to better understand themeaning of the collected data, and their method can be usedto determine whether a place could be important to the user.

III. THREAT MODEL

Previous research has discussed personal information disclo-sure and personal information inference from network trafficleakage. However, those studies mainly dealt with inferringstatic information, such as demographic attributes or other PIIwhich can be observed when the user is connected to a singlemalicious hotspot. In our case, since we are analyzing locationdata over time in order to obtain contextual information,capturing network traffic from a single hotspot is insufficient.Thus, in this paper, it is assumed that a threat actor cancontinuously capture the network traffic of the user’s mobiledevice. This special capability is granted to the following mainthree threat actors:

1) Internet service providers and mobile network op-erators (MNOs) which are exposed to the vast amountof the users’ network traffic. The ISP threat model isstrong, however we believe that location data leakage isa significant problem by itself and therefore should beexplored. In addition, although ISP’s can derive locationinformation from the cell ID, it is very coarse location.On the other hand, the location that can be derived fromthe leaked data is much more accurate.

2) VPN and proxy servers, which relay mobile devicenetwork traffic to a third party server and can alsomisuse the unencrypted data sent in the network traffic.These solutions are increasingly being used by mobileusers for protecting their privacy or consume restrictedentertainment content [17].4 5

3) Tor-like solutions, which commonly used for protectingprivacy [18]. In this case the location leakage data canbe used by the exit node to expose the real user location(and maybe the user identity).

The main goal of this study is to estimate the potentialprivacy exposure of a user by the such entities if they chooseto misuse this data, or by an attacker.

IV. DATA COLLECTION

In the interest of exploring the extent of location dataleakage in the Internet traffic of Android-based smartphones,we developed a dedicated data collection framework. Using

4https://www.forbes.com/sites/forbestechcouncil/2018/07/10/the-future-of-the-vpn-market/

5https://blog.globalwebindex.com/chart-of-the-day/vpn-usage/

the framework, we collected data from 71 participants for anaverage period of 37 days.

A. Data collection framework

The framework consists of three main components: a VPNclient that collects all of the network traffic transmitted by thedevice to the Internet, a dedicated Android agent applicationthat obtains location readings from the device’s location API,and a light-weight server.

• VPN client. The high volume of Internet traffic onsmartphones makes it prohibitive to store this informationlocally on the device for a long period of time. Alterna-tively, caching the Internet traffic locally and transmittingit daily to a remote server causes overheads to the device’sbattery, CPU, and network. In addition, due to securityconcerns, such operations require super-user privileges,which necessitate rooting the user’s device. For thesereasons, we opted to use VPN tunneling to redirect thetraffic through a dedicated VPN server, where we couldrecord and store the traffic. It should be mentioned that aVPN is the only user space API provided by the Androidoperating system to intercept network traffic that does notrequire super-user or system privileges.

• Android agent (client) application. To understand thequality of location leakage detected in plaintext withinthe device’s network traffic and to estimate the privacyexposure level of users, we developed a dedicated An-droid application that obtains the actual location of users.The application uses the network location provider APIwhich assesses the location by utilizing three sources ofinformation: GPS, Wi-Fi, and Cell ID (obtained fromthe cellular network). The data collected by the agentapplication was used as the ground truth for the actuallocation of the users. Applying clustering algorithms onagent-based, accurate and consistent location samples wasshown to be accurate and effective for deriving users’POIs. Therefore, we opt to use this approach as ourbaseline and not to rely on the (subjective) collaborationof the participants in providing the actual/labeled POIs.

• Light weight server. This server has two primary objec-tives. First, it operates as an application server, whichcommunicates with the Android agent application andstores all location data in a database. Second, it acts as aVPN server which communicates with the VPN clients,records all of their network traffic, and redirects it tothe Internet. To provide VPN connectivity and record thetraffic, we created a dedicated LAN (local area network)on that server where every VPN client was assigned to adifferent IP address in the LAN. The Internet traffic wasrecorded using ”tshark,” - a network analyzer tool that iscapable of capturing packet data from real-time networktraffic.

B. Experiment

In order to achieve the research objectives, we conductedan experiment involving 71 participants. The participants werecurrent and former students at two universities located in

4

Fig. 1: The amount of time users participated in the experi-ment.

Fig. 2: The users’ actual (averaged) location sample rate ofthe agent installed on the users’ devices.

two different cities in Israel. Additional information on theparticipants:

• 60% are male and 40% female,• 44% are in the age of 18 to 24 and 56% in the age of 25

to 30,• 51% are undergraduate students and 49% graduate stu-

dent.The participants were required to install the two client appli-cations on their personal mobile device for an average periodof 37 days.

To ensure that the location sampling had minimal impacton the battery, throughout most of the experiment we set theAndroid client to sample the location provider for 60 secondsevery 20 minutes. In addition, the server was deployed on anAWS (Amazon Web Services) EC2 instance to ensure highavailability.

In Figure 1 we present the amount of time the usersparticipated in the experiment. In Figure 2 we present thedistribution of the actual location sample rate of the agentapplication, as observed in the experiment.

Note that the framework that we developed, and specificallythe VPN and monitoring agent applications that were installedon the participants smartphones, were used for data collection,research and validation only and are not assumed to be partof the threat model.

C. Privacy and ethical considerations

The experiment involved collecting sensitive informationfrom real subjects for a long period of time. To preserve thesubjects’ privacy, we took the following steps:

1) The subjects participated in the experiments at their ownwill and provided their formal consent to participate inthe research; in addition, they were fully aware of thetype of data that would be collected and were allowedto withdraw from the study at any time. It should benoted that the subjects received a one-time payment ascompensation for their participation.

2) Anonymization was applied to the data. At the beginningof the experiment, a random user ID was assigned toeach subject, and this user ID served as the identifierof the subject, rather than his or her actual identifyinginformation. The mapping between the experiment’suser ID and the identity of the subjects was stored ina hard copy document kept in a safe box; at the end ofthe experiment we destroyed this document.

3) During the experiment, the communication between theagents and servers was fully encrypted. In addition, thedata collected was stored in an encrypted database. Atthe end of the experiment the data was transferred toa local server (i.e., within the institutional network),which is not connected to the Internet. Only anonymizedinformation of the subjects was kept for further analysis.

Based on these steps, the research was approved by theinstitutional review board (IRB).

V. EXTRACTING LOCATION TRACES FROM RAWNETWORK TRAFFIC

Location data can be transmitted over network traffic inmany formats including: explicit geolocation coordinates,names of cities or points of interest, Wi-Fi networks (BSSID),and cellular network data (Cell ID). In this research we focuson explicit geolocation data that is transmitted in plaintext;such structured data can (potentially) provide more accuratelocation and is easier to extract and analyze, and thus intro-duces a greater risk to the user’s privacy if leaked.

A. Process description

In order to automatically detect location traces within thenetwork traffic of a mobile device, we capture the data atthe IP network layer. Geographic coordinates can be repre-sented in different formats [19]. We perform regex search ofthe standard Android API [20] representation of geographiccoordinates which is decimal degrees in the following format:XX.YYYYYYY. We specifically used this regular expressionfor two main reasons. First, this is the standard format of theAndroid location API. Second, our manual exploration of otherlocation data formats (e.g., names of cities, points of interest,and Wi-Fi networks) indicated that they can dramaticallyincrease the number of false positives (for example, city namessent by a weather forecast application do not indicate the truelocation of the user).

Each result is assigned a timestamp based on the packetcapture time. This regular expression may retrieve irrelevant

5

results of simple float numbers which have no geographicmeaning and can appear within the network traffic (e.g., thelocation of an object on the screen). Therefore, in the nextstep we apply the following heuristics in order to filter outirrelevant results:

• outgoing traffic filter. extracting geographic coordinatesfrom outgoing traffic (incoming traffic may contain ge-ographic data that is not relevant to the real location ofthe user such as recommendations of POIs and weatherforecasts);

• latitude/longitude pair filter. extracting only pairs ofvalid geographic coordinates (i.e., those that were notalready ruled out by the previous filters) that were as-signed with the same timestamp (they can appear indifferent IP packets due to fragmentation); this is becausea coordinate is represented by two values indicating thelatitude and longitude of the location.

• geo-fencing filter. filtering out geographic coordinate thatare outside a predefined geo-fence (e.g., the geographicalboundaries of a given country or city). In our case, allusers were located within the geographical boundariesof Israel during the data collection period, and thereforewe filtered out all geographic coordinates that are notwithin this area (as illustrated in Figure 3). Note thatin order to apply the geo-fencing filter in a generaland practical one can perform reverse geo-coding on theleaked location data and identify the geographical areasthat are most likely to be relevant to a user or a group ofusers. We demonstrat this approach in Figure 4, in whichwe performed reverse geo-coding on randomly selectedsamples from the leaked location data (1%). As can benoticed, most of the randomly selected sample are locatedwithin the boundaries of Israel.

B. Analysis and results

In order to evaluate the amount of location data leakage,we have to determine the accuracy and correctness of thegeographic coordinates detected within the network traffic.In our experiment we could compare the geographicalcoordinates detected within the network traffic with thelocation data that was sampled by the agent application(installed on the participants’ mobile phones). By analyzingthe data collected by the agent application, we observed thatthe location was sampled only 70% of the time (see Figure2 for the distribution of the location sampling rate). Possiblereasons for this are that the device was off, the agent wasshut down, or the location service was disabled.Following the above observation, we define the active timeof a given user as the number of hours at which the agentobserved at least one location sample. Using the locationsamples observed by the agent, we validated the geographiccoordinates that were detected within the network traffic.Specifically, a location that observed in network traffic wasclassified as ’true’ location only if (1) the timestamp of thedetected coordinate was close enough (within 10 minutes)to a location sampled by the agent application, and (2) themeasured distance between the two coordinates was below a

Fig. 3: The geo-fencing of identified coordinates. Coordinatesthat are outside of a predefined geographical area are removed.

Fig. 4: Worldwide distribution of randomly selected geo-locations found in the network traffic for all of the experimentparticipants.

predefined threshold of 250 meters. If just the timestamp ofthe detected coordinate was close enough (within 10 minutes)to a location sampled by the agent application, we labeledthe detected coordinate as ’false’; otherwise, it was labeledas ’unknown.’

Volume of leaked location data. A total of approximately474K geolocations (complying with the standard API locationregex) were identified within the network traffic of all ofthe monitored mobile devices. After applying the geo-fencingfilter, approximately 347K geolocations remained.

Figure 5 presents the classification of geo-locations de-tected within the network traffic after applying the lati-

6

Fig. 5: The classification of geolocations detected withinthe network traffic after applying the latitude/longitude pair(left column) and after applying both the latitude/longitudepair and the outgoing traffic filters (right column). Eachcolumn presents the distribution of labels (’true,’ ’false,’ and’unknown’) of the remaining geo-locations according to thelabeling process described above.

Group Leakage rate Number of devices PercentageHigh under 1hr 20 28%

Medium 1-6hrs 19 27%Low 6+ hrs 23 32%

No leakage ∞ 9 13%

TABLE I: The leakage rate of different mobile devices.

tude/longitude pair filter (left column) and after applyingboth the latitude/longitude pair filter and the outgoing trafficfilter (right column). Each column presents the distribution oflabels (’true,’ ’false,’ and ’unknown’) of the remaining geo-locations according to the labeling process described above.In total, after applying the latitude/longitude pair filter, 257Kgeolocations remained; 36% of them were labeled as ’true,’47% as ’false,’ and the rest could not be labeled. Afteralso applying the outgoing traffic filter, 100K geo-locationsremained; 58% of them were labeled as ’true,’ 11% as ’false,’and the rest could not be labeled.

These results support our hypothesis that incoming trafficis unlikely to contain relevant geolocations of the mobiledevice. We can also see that after applying all three filters,85% of the geolocations that could be labeled (either as’true’ or ’false’) indicated the true location of the mobiledevice. We can assume that the same rate also exists for thegeolocations that could not be labeled (i.e., ’unknown’).

Rate of data leakage. By analyzing the validated geo-locations (i.e., labeled as ’true’) of the 71 users, we could seethat the mobile devices of about 90% of them were leakinglocation traces. The rate of data leakage of a give user (device)is calculated by dividing the user’s active time by the numberof validated leaked locations. We partitioned the calculatedleakage rate into the following groups: ’high’, ’medium’, ’low’and ’no-leakage’ as presented in Table I.

As can be seen in Table I, 55% of the devices were leakinglocation data at a medium (once every one to six hours) andhigh (once every one hour) rate.

Fig. 6: The coverage rate measure is defined as the totalnumber of exposed hours of network traffic divided by thetotal number of hours of agent application data.

1) Leakage coverage.: We define an exposed hour as anhour within the collected data (network or agent) in which atleast two valid location leaks were detected.In order to analyze the coverage over time of relevant (val-idated) leaked location data, we define the coverage ratemeasure as the total number of exposed hours of networktraffic divided by the total number of hours of agent data (i.e.,excluding hours in which the agent was not active):

CoverageRate =#ofExposedTrafficHours

#ofAgentDataHours

We assume that a high coverage rate will result in a highexposure and discovery rates of users’ important places. Figure6 presents the distribution of the coverage rates of the mobiledevices in the collected dataset. As can be seen, for almost70% of the users the coverage rate is below 0.2.

2) Leakage inconsistency.: While Table I and Figure 6present the overall average leakage rate of location data, ourmanual exploration of the data showed that the leaked dataexhibits inconsistent, non-uniform, and bursty behavior. Asan example, Figure 7 depicts the number of location samplesper hour of a single user observed by the agent application(green line) and within the network traffic (red line). It canbe seen that while the agent’s sample rate is relatively stable(around 12 samples per hour) excluding minor changes (phoneshutdown or agent crash), the leaked location data within thenetwork traffic is unstable, ranging from only a few or no leaksto a high rate of leakage.

Thus, in order to analyze and understand the inconsistencyin the amount of leaked location data, we computed the relativestandard deviation measure for each mobile device by dividingthe standard deviation of ’leaks per hour’ by the averagenumber of ’leaks per hour.’

Figure 8 depicts the distribution of the values of the relativestandard deviation measure of the mobile devices; a value ofzero (0) indicates a constant leakage rate (i.e., zero variability).

VI. INFERRING POINTS OF INTEREST FROM LEAKEDLOCATION TRACES

We are also interested in understanding how we can infermeaningful insights from the geolocations (coordinates) that

7

Fig. 7: An example of a single user, comparing the locationleakage rate obtained by the agent installed on the devices andthe network traffic.

Fig. 8: The leakage rate variability as indicated by the leakrelative standard deviation measure.

were detected as leaks within the mobile devices’ networktraffic. Specifically, we are interested in identifying a user’spoints of interest (POIs) and differentiating them from transitor noise data [21].

As mentioned in the related work section, the most com-mon a approach for identifying stay points (or POIs) is byapplying clustering algorithms that are not usually boundto a predetermined number of clusters (e.g., k-means), andclustering stay points by spatial or spatio-temporal parameters.In this research we opted to use three different algorithms:incremental clustering [5], DBSCAN [6], and ST-DBSCAN[14]. These algorithms usually have some assumptions on thedata. Specifically, it assumed that the data is arriving at aconstant rate which was not true in our case. Therefore, wemade the following modifications to the algorithms. First, weincluded the notion of time by calculating the time betweensamples and defined a bound on that time interval. Second,since we processed long time frames of data, we added a phasewhich applies backtracking and use previously created clusters(i.e., repeating POIs) in order to increase the confidence in theidentified POI.

Another approach uses semantic data to determine when auser is at an important place; for example, a location traceat a famous landmark will identify it as an important place

Incremental-traffic

DBSCAN-traffic

STDBSCAN-traffic

Total 282 470 339True positive 205 213 148Precision 0.73 0.45 0.43Recall 0.20 0.20 0.14

TABLE II: Recall and precision measures of the threemethods (Incremental-traffic, DBSCAN-traffic, STDBSCAN-traffic), when considering the Incremental-agent as the groundtruth of the users’ POIs.

for that user [16]. This approach is not relevant in our case,because the points of interest are not known in advance;however, we use semantic data from reverse geocoding toeliminate transit geolocations (e.g., highways). One of themain challenges when applying clustering algorithms in fullyunsupervised data is determining the parameters that will yieldthe best results. This is even more challenging when thedataset is not consistent over time and for all users, as shownin Section V. Based on a manual analysis of the clusteringalgorithm results, in our evaluation we set the thresholdsfor the incremental clustering algorithms at 500 meters and30 minutes, and the value of the minPts parameter for theDBSCAN and STDBSCAN clustering to be at five pts.

Note that we did not have any information about theusers’ real (confirmed) POIs in order to understand thenature and validity of the POIs identified in the networktraffic leaked locations. Therefore, as a benchmark (andground truth) we used the POIs identified by applyingthe incremental clustering algorithm on the Android agentlocation data (denoted as Incremental-agent). Because thelocation traces collect by the mobile agent applicationindicate the true location of the user with high accuracy, andsince POIs clustering methods have been proven in previouswork, we found this benchmark sufficient for our purposes.The POIs identified by applying the different clusteringalgorithms on the network traffic’s leaked locations (denotedas Incremental-traffic, DBSCAN-traffic, and STDBSCAN-traffic) were compared with the agent-based POIs, namelythe Incremental-agent. We calculated the total amount of timespent at each user POI and weighed the POI significanceby its part from the user total amount of time spent in all POIs.

POI detection rate. A total of 1,053 POIs (over all users)were identified by the Incremental-agent method. For eachtraffic-based method we calculated: (1) the total number ofPOIs identified; (2) the true positive measure (number of POIsthat were also detected by the Incremental-agent method);(3) the precision (the true positive value divided by thetotal number of POIs identified); and (4) the recall (the truepositive value divided by the number of POIs identified bythe benchmark method, i.e., Incremental-agent). The resultsare presented in Table II. As can be seen, the recall, whichrepresents the POI discovery rate, is approximately 20% for allmethods; the Incremental-traffic method yields the best results,compared to the other methods, with slightly lower recall butmuch higher precision.

In a real-life scenario, the adversary will not be able to label

8

Incremental- traffic(all)

Incremental-traffic(’true’ only)

Precision 0.73 0.94Recall 0.20 0.20

TABLE III: The recall and precision of the Incremental-trafficmethod when applied on all identified geolocations and whenapplied only on the confirmed (’true’) geolocations.

Incremental-traffic

DBSCAN-traffic

STDBSCAN-traffic

Total 263 374 264True positive 193 201 141Precision 0.73 0.54 0.53Recall 0.20 0.20 0.14

TABLE IV: The recall and precision measures of the threemethods (Incremental-traffic, DBSCAN-traffic, STDBSCAN-traffic), when considering the Incremental-agent as the groundtruth of the users’ POIs and when using semantic information.

the extracted geolocations as ’true,’ ’false,’ or ’unknown’ (asdescribed in Section V). Therefore, in Table II we applied theclustering algorithm on all the geolocations.In Table III we present the optimal results that the adversarycan achieve when the POI identification process is only appliedon the users’ ’true’ geolocations. In this case, it can beseen that the Incremental-traffic clustering method achieveda similar recall of 20%, however the precision improveddramatically to 95%.

Previous work on location data analysis showed thatprior semantic information (e.g., landmarks, shopping centers,roads, etc.) can be used in order to determine if a locationtrace is a user’s POI or transit location [22]. Thus, in orderto further improve the POI inference process, we used priorsemantic information in order better determine the real POIs.Specifically, we used Google’s reverse geo-coding API inorder to remove geo-location clusters (i.e., POIs) that arelocated on highways.

Table IV presents the results of detected POIs (true positive,precision, and recall) when using this semantic information.As can be seen, using semantic information to eliminateirrelevant location clusters can improve the precision with noeffect on the recall. This can be explained by the fact thatdue to the lower and inconsistent location leakage within thenetwork traffic, the irrelevant location clusters (i.e., highways)are poorly reflected within the network traffic but bettercaptured by the agent.

The importance of the 25% identified POIs. The numberof identified POIs alone does not necessarily provide a goodestimation for the exposure rate of users’ whereabouts. Forexample, let’s assume a user with ten different significantlocations (POIs). If a user spends 50% of his/her time at homeand is at work 35% of the time, by determining the user’shome and work locations, we are able to identify the locationsat which the user spends 85% of his/her time (although weidentified only 20% of the user’s POIs).

Thus, in order to estimate the significance of the identifiedlocations (POIs), we computed a weighted measure for the POI

Leakage rate POI discovery ra-tio

Weighted POIdiscovery ratio

High rate (under 1hr) 48% 81%Medium rate (1-6hr) 26% 67%Low rate (6+hr) 8% 37%No leakage 0 0Total 27% 61%

TABLE V: The POI and weighted POI discovery ratios ofthe Incremental-traffic method. The POI discovery rate isthe number of places found in the network data dividedby the number of places found by the benchmark method(Incremental-agent). The weighted POI discovery rate is theamount of time spent at the identified POIs out of the totaluser time.

Dependent variable:Weighted POI’s exposure rate

Coverage 0.559∗∗∗(0.172)

Leak rate −0.0000013∗∗(0.00000)

Relative standard deviation −0.048(0.078)

Constant 0.597∗∗∗(0.106)

R2 0.315Adjusted R2 0.283Residual Std. Error 0.331 (df = 65)F Statistic 9.955∗∗∗ (df = 3; 65)

Note: ∗p<0.1; ∗∗p<0.05; ∗∗∗p<0.01

TABLE VI: The linear regression model for estimating POIs’exposure rate from network traffic measures.

detection rate as follows. For each POI detected we computedthe relative time spent by the user at that location (i.e., thetotal time that the user was at the POI divided by the totaltime the user spent at all POIs). The weighted measure ofthe POIs was computed from the baseline Incremental-agentmethod. Then, the POI discovery rate measure was computedby using the weights computed for each identified POI.The results presented in Table V show a high weighted POIdiscovery ratio for the medium and high leakage rates, andtotal of 61% weighted POI’s exposure rate.

Inferring the potential exposure rate of POIs fromnetwork traffic leakage measures. In a real-life scenario anattacker would not have a benchmark to relate to and inferringa user’s POI exposure rate would be based on captured dataalone. By deriving a regression model (Table VI) we cansee that the user weighted POI exposure ratio parameterhas a high correlation with the leakage rate and coveragerate measures and no significant correlation with the relativestandard deviation.

VII. DISCUSSION

In this section we discuss two interesting questions that arisefrom our research: (1) how to identify which are the leaking

9

apps, and, (2) how can users reduce the location leakageprivacy risk.

A. Identifying leaking applications and servicesThe goal of our analysis in this section is to determine which

applications are responsible for leaking the location data andwhether the leakage occurs as a result of intentional misuseor a benign application sending location data in plaintext.One approach for obtaining such information is real-timeon device monitoring of the installed applications’ outgoingtraffic. However, as mentioned in Section IV-A, due to securityconcerns such operations require super-user privileges whichnecessitate rooting the user’s device, and therefore, such anapproach was not an option in our experiment.

Deriving the information about the leaking applicationsfrom the network traffic captured is also challenging for threemain reasons: (1) the network traffic captured does not providean explicit indication of the sending application/service, (2) be-cause of the growing use of cloud services and content deliverynetworks (CDNs), many destination IPs are hosted by servicessuch as AWS, Akamai or Google, and (3) location data canbe sent to advertisement and intelligence service domains bycomponents embedded in multiple Android applications.

Given this, we opted to analyze the destination host namesobserved within the HTTP traffic. We focused specificallyon outgoing traffic containing location leaks. By extractingthe host names from the HTTP requests that contained theleaked location data we identified 112 different services. Then,we analyzed the host names using public security services(VirusTotal), search engines (Google and Whois) and securityreports. Based on the analysis results, we were able to classifyeach host name by its reported usage (e.g., weather fore-cast, navigation, location analytics, advertisement service) andwhether it appears to be a legitimate or unwanted/suspiciousservice. Services with clear/reasonable location usage and noreported security issues were classified as ’benign’; the rest ofthe services were classified as ’suspicious’.

Figure 9 presents the top 12 host names classified by theircategory (color) and level of suspiciousness (size of circle).Each host name is placed on the graph according to the averagenumber of detected leakage events (x-axis) and the number ofusers involved in the experiments sending location data to thathost name (y-axis).

Some of the suspicious domain names include sam-sungbuiasr.vlingo.com which was previously published as aSamsung pre-installed speech recognition application namedVlingo. This application was found to be leaking sensi-tive information. Another example includes the domains,n129.epom.com and mediation.adnxs.com, which are reportedto provide personalized advertisements. An additional sig-nificant suspicious domain is app.woorlds.com, which wasreported to be a location analytics service. Interestingly, ouranalysis concludes that the Google Maps JavaScript API(maps.googleapis.com), which lets Android application devel-opers customize maps with user locations, is also responsiblefor sending location data in plaintext. This is particularlynoteworthy since Google recommends that application devel-opers use the secured Maps JavaScript API (which operates

0 500 1000 1500 2000 2500 3000Avarage Leakage Volume (packets)

5

10

15

20

25

30

35

Leak

age

Vol

ume

(use

rs)

mediation.adnxs.com

n129.epom.com

app.woorlds.com

samsungbuiasr.vlingo.com

upload.wikimedia.org

location.gtforge.com

maps.googleapis.com

venues.waze.co.illgemobilewidget.accu-weather.com

easy.co.il

htc2.accu-weather.comapi.openweathermap.org

CategoryAdvertisementAnalyticsSpeech RecognitionOtherLocation ServiceWeatherLabelSuspiciousBenign

Fig. 9: Presenting the top 12 host names classified by theircategory (color) and benign/suspicious (size of circle) The x-axis represents the average number of detected leakage events,and the y-axis represents the number of users involved in theexperiments sending location data to that host name.

over HTTPS) whenever possible.6 Nonetheless, our analysisshows that in practice, developers also use the unsecured MapJavaScript API (which operates over HTTP). Overall, based onthe analyzed data, we found that the set of unwanted servicesis responsible for more than 60% of location leakage events.

Another interesting observation from our analysis is thatalthough the number of location data leakage events (x-axisin Figure 9) for each individual host name is not high, basedon the analysis in Section VI we were still able identify theusers’ significant POIs from the data. We attribute that findingto the fact that there are multiple applications installed on eachindividual smartphone, which together leak a sufficient amountof information that can be analyzed in order to infer the POIs.

Although the identity of the leaking application is not ex-plicitly indicated in the network traffic, we performed furtheranalysis in an attempt to link the identified host names withthe applications installed on the users’ mobile devices. Inorder to do so, we first extracted (using our Android agent)the set of all applications that are installed on the mobiledevices of the users which require both location and networkpermissions. Next, we computed a modified tf-idf measurefor each pair consisting of an application and host name. tf-idfis a well-known measure in the field of text categorization,which is often used as a weighting factor in informationretrieval and text mining [23]. The acronym tf-idf is short forterm frequency-inverse document frequency. It is a numericalstatistic intended to reflect how important a term (i.e., word)is to a document in a collection or corpus. The tf-idf valueincreases proportionally to the number of times a term appearsin the document, but it is offset by the frequency of the term inthe corpus, which helps to adjust for the fact that some termsappear more frequently in general. In our case, a document isa host name, and a term is an application. The term frequency

6https://developers.google.com/maps/documentation/javascript/tutorial

10

(denoted by TF ) of an application (denoted by a) with respectto a given host name (denoted by h) is calculated as follows:

TFh(a) =|Ua

h ||Uh|

where Uh represents the set of users for which we identify alocation leakage (from their devices to h), and Ua

h representsthe subset of users from Uh in which application a wasinstalled on the devices.

The inverse document frequency (denoted by IDF ) of anapplication is calculated as follows:

IDF (a) = −log10(|Ua||U |

)where Ua represents the set of users for which application awas installed on the devices; and U represents the set of allusers.

Given the above, the tf-idf of an application with respect toa given host name is calculated as follows:

TFIDFh(a) = TFh(a) ∗max(1, IDF (a)

)The reason for limiting the inverse document frequency (IDF )value to one is to prevent rare applications from achievinga very high tf-idf score and consequently be mistakenlylinked with the host name. In addition, we applied min-maxnormalization to the tf-idf scores of applications in order tokeep them within the range of zero and one. A high TF valuefor an application a with respect to a host h indicates that awas frequently observed in devices that transmit location datain plaintext to h. On the other hand, a high IDF value for aindicates that a was not frequently observed on the devices ingeneral. Thus, a high tf-idf score for application a with respectto host h may indicate that a is related to the location leakageto h.

The results of this analysis are presented in Figure10, where the tf-idf values are shown for each hostname (x-axis) and application (y-axis). Based on these re-sults we can classify the applications into two categories.The first category includes applications that send the lo-cation data to their own hosting service. In this cate-gory we can find multiple HTC, LG, and Samsung pre-installed applications found to be related to their own host-ing services (htc2.accu-weather.com, lgemobilewidget.accu-weather.com, and samsungbuiasr.vlingo.com), as well as theGetTaxi (com.gettaxi.android) and Easy (easy.co.il.easy3) ap-plications which were found to be related to their hostingservices (location.gtforge.com and easy.co.il respectively).The second category includes applications that send (usuallyvia integrated ”software plug-ins”) location data to third partyservices such as advertisement APIs (n129.epom.com) oranalytical services (app.woorlds). In this category we identifieda popular student application named com.mobixon.istudent.We also identified applications that send location data toGoogle Maps services (for presenting objects on maps), someof which potentially use the Google Maps JavaScript API in anunsecured manner (the HTTP protocol instead of the HTTPSprotocol).

map

s.go

ogle

apis

.com

med

iatio

n.ad

nxs.

com

n129

.epo

m.c

om

app.

woo

rlds.

com

venu

es.w

aze.

co.il

lgem

obile

wid

get.a

ccu-

wea

ther

.com

sam

sung

buia

sr.v

lingo

.com

uplo

ad.w

ikim

edia

.org

loca

tion.

gtfo

rge.

com

easy

.co.

il

htc2

.acc

u-w

eath

er.c

om

api.o

penw

eath

erm

ap.o

rg

com_goldtouch_ynet

com_gettaxi_android

com_mobixon_istudent

com_ebay_mobile

com_android_gallery3d

com_lge_email

com_lge_systemservice

com_lge_settings_easy

com_lge_sizechangable_weather

com_android_email

com_fmm_dm

com_sec_android_app_camera

com_sec_android_app_clockpackage

com_sec_android_app_videoplayer

com_sec_android_daemonapp_ap_accuweather

com_sec_android_widgetapp_dualclockanalog

com_sec_chaton

com_vlingo_midas

com_yohana_ea_ziggi

com_melodis_midomiMusicIdentifier_freemium

com_wolfram_android_alpha

com_htc_AutoMotive_Traffic

com_nero_android_htc_sync

com_htc_android_locationpicker

com_htc_task

com_sgiggle_production

com_sec_android_widgetapp_diotek_smemo

com_sec_android_widgetapp_dualclockdigital4x2

com_macropinch_swan

com_sec_android_app_mt

com_ideomobile_hapoalim

com_sec_pcw

com_amudanan_amudanan

easy_co_il_easy3

0.28 0.64 0.6 0.51 0.71 0.26 0.082 0.48 0.064 0.24 0.38 0.11

0.68 0.62 0.45 0.65 0.17 0.54 0 0.44 1 0.16 0 0.15

0.31 0.49 1 1 0 0.62 0 0.24 0 0.18 0 0.18

0.3 0.82 0.48 0.72 0.46 0.49 0 0.26 0 0 0 0

0.16 0.091 0.35 0.45 0 1 0 1 0.14 0.25 0 0.23

0.15 0.11 0.35 0.45 0 1 0 1 0.14 0.25 0 0.23

0.15 0.11 0.35 0.45 0 1 0 1 0.14 0.25 0 0.23

0.15 0.11 0.35 0.45 0 1 0 1 0.14 0.25 0 0.23

0.15 0.11 0.35 0.45 0 1 0 1 0.14 0.25 0 0.23

0.8 0.96 0.12 0.15 0.83 0 0.37 0.31 0.064 0.12 0 0.11

0.8 0.96 0.12 0.15 0.83 0 0.37 0.31 0.064 0.12 0 0.11

0.8 0.96 0.12 0.15 0.83 0 0.37 0.31 0.064 0.12 0 0.11

0.8 0.96 0.12 0.15 0.83 0 0.37 0.31 0.064 0.12 0 0.11

1 0.8 0.042 0.083 1 0 0.44 0.37 0.076 0.14 0 0.13

0.75 0.77 0.17 0.11 0.92 0 0.54 0.46 0.094 0 0 0.16

0.75 0.77 0.17 0.11 0.92 0 0.54 0.46 0.094 0 0 0.16

0.87 0.92 0.11 0.13 0.86 0 0.44 0.37 0.076 0.14 0 0.13

0.91 1 0.16 0.17 0.69 0 1 0.35 0.073 0.13 0 0.13

0.24 0.51 0.44 0.24 0.96 0.17 0.16 0.98 0.27 0.75 0.48 0

0.099 0.33 0 0.27 0.28 0 0.17 0.33 0 0.25 1 0

0.051 0 0 0.18 0.14 0 0 0.33 0 0.75 0.25 0

0 0.11 0 0.091 0.14 0 0 0.33 0 0.25 1 0

0 0.11 0 0.091 0.14 0 0 0.33 0 0.25 1 0

0 0.11 0 0.091 0.14 0 0 0.33 0 0.25 1 0

0 0.11 0 0.091 0.14 0 0 0.33 0 0.25 1 0

0.15 0.22 0.12 0.27 0.14 0.2 0 0.33 0.28 0 0 0

0.87 0.87 0.11 0.12 0.85 0 0.59 0.24 0.1 0.18 0 0

0.61 0.66 0.2 0.16 0.69 0 0.7 0.31 0.13 0 0 0

0.15 0.11 0 0.091 0 0 0.17 0 0.28 0 0 0

0.61 0.87 0.054 0.14 0.64 0 0.67 0.27 0 0.21 0 0

0.1 0.33 0.23 0.27 0.41 0 0 0.67 0 0.75 0.25 1

0.41 0.66 0 0 0.41 0 0.7 0.33 0 0 0 0

0.1 0.22 0.12 0.18 0.14 0 0 0 0 0.75 0.25 0

0.1 0.11 0 0.091 0.28 0 0 0.33 0 1 0.25 00.0

0.2

0.4

0.6

0.8

1.0

Fig. 10: Presenting the tf-idf values are presented for each hostname (x-axis) and application (y-axis).

B. Mitigation strategies: reducing the privacy risk

In order to reduce the privacy risk of location leakage andPOI inference presented in our paper, the following counter-measures are suggested and could be further investigated anddeveloped in future work.

• Awareness. The most basic approach is increasing theawareness of mobile device users to such risks and pro-viding them with the tools and means to reduce the risk[24]. For example, reducing the risk can be achieved byinstalling only trusted applications (from trusted sources),monitoring and limiting sensitive permissions such as lo-cation and Internet access, and disabling location serviceon the device while not in use and turning it on only ondemand.

• OS policy and tools. The Android OS provides built-instandard security solutions features such as isolation, en-cryption, memory management, and user-granted permis-sions for phone resources and sensors. Once permissionhas been granted by the user, PII handling is done solelyby best practice recommendation [25]. This may includeenforcing encryption on applications that send sensitiveinformation such as location over the Internet or applyinga tool such as PrivacyGuard [26]. In addition, futureversions of the Android OS could consider improvingprivacy by enabling user decisions regarding background

11

operation involving sensitive data.• Monitoring. Monitoring network traffic by third party

security providers in order to detect PII leaks was pro-posed by [7] and is a useful approach for identifyingapplications that misuse users’ private information.

• PII obfuscation. An application installed on the mobiledevice that monitors the location sampling or locationleakage over the network traffic can intelligently injectspoofed locations that can make it difficult for a threatactor to infer the true POIs of the user.

Since the experimental setup of this research was complexand resource and time consuming, we opted leave the design,development and evaluation of the defense approaches, es-pecially applying PII obfuscation as an adversarial learningapproach on the clustering algorithms [27], to future research.

VIII. CONCLUSIONS AND FUTURE WORK

In this paper, we showed the extent of location leakage frommobile devices and presented a systematic process of extract-ing location traces from raw network traffic. We analyzed theresults of three different geo-clustering methods applied overthe inconsistent network traffic data and showed that existingalgorithms yield good results, even with inconsistent locationdata; this makes any user location privacy vulnerable evenwith a low rate of location leakage. Our work enables locationexposure assessment by monitoring network traffic and revealsthat even relatively low location leakage rates (e.g., six hours)and coverage of only 20% can expose more than 70% of theweighted POIs. In future work we plan to further automatethe POI identification process by automatically setting up theclustering algorithm parameters; evaluate the extent to whichthe leaked data can be used for predicting the users futurelocation; and develop a mitigation approach based on adver-sarial learning techniques, which will be based on injecting aminimal number of false locations in clear text to the networktraffic, in order to deceive the clustering algorithms (i.e., PIIobfuscation).

REFERENCES

[1] L. T. Nguyen, Y. Tian, S. Cho, W. Kwak, S. Parab, Y. S. Kim, P. Tague,and J. Zhang, “Unlocin: Unauthorized location inference on smartphoneswithout being caught,” 06 2013.

[2] I. Hazan and A. Shabtai, “Dynamic radius and confidence predictionin grid-based location prediction algorithms,” Pervasive and MobileComputing, vol. 42, pp. 265–284, 2017.

[3] Y. Michalevsky, A. Schulman, G. A. Veerapandian, D. Boneh, andG. Nakibly, “PowerSpy: Location Tracking Using Mobile Device PowerAnalysis.” in USENIX Security Symposium, 2015, pp. 785–800.

[4] L. Arigela, P. Veerendra, S. Anvesh, and K. Satya, “Mobile PhoneTracking & Positioning Techniques,” International Journal of InnovativeResearch in Science, Engineering and Technology, vol. 2, no. 4, 2013.

[5] J. H. Kang, W. Welbourne, B. Stewart, and G. Borriello, “Extractingplaces from traces of locations,” ACM SIGMOBILE Mobile Computingand Communications Review, vol. 9, no. 3, pp. 58–68, 2005.

[6] M. Umair, W. S. Kim, B. C. Choi, and S. Y. Jung, “Discovering personalplaces from location traces,” in Advanced Communication Technology(ICACT), 2014 16th International Conference on. IEEE, 2014, pp.709–713.

[7] J. Ren, A. Rao, M. Lindorfer, A. Legout, and D. Choffnes,“ReCon: Revealing and Controlling PII Leaks in Mobile NetworkTraffic.” ACM Press, 2016, pp. 361–374. [Online]. Available:http://dl.acm.org/citation.cfm?doid=2906388.2906392

[8] P. Regulation, “General data protection regulation,” Official Journal ofthe European Union, vol. 59, pp. 1–88, 2016.

[9] V. F. Taylor and I. Martinovic, “A longitudinal study of app permissionusage across the google play store,” CoRR, abs/1606.01708, 2016.

[10] E. Grolman, A. Finkelstein, R. Puzis, A. Shabtai, G. Celniker, Z. Katzir,and L. Rosenfeld, “Transfer Learning for User Action Identication inMobile Apps via Encrypted Trafc Analysis,” IEEE Intelligent Systems,vol. PP, no. 99, pp. 1–1, 2018.

[11] D. Hodges, “Android apps and privacy risks : what attackers can learnby sniffing mobile device traffic,” 2014. [Online]. Available: https://ora.ox.ac.uk/objects/uuid:17c44695-402c-4275-8dab-468966d8fe0b

[12] J. Ren, M. Lindorfer, D. J. Dubois, A. Rao, D. Choffnes,and N. Vallina-Rodriguez, “Bug Fixes, Improvements, ... andPrivacy Leaks - A Longitudinal Study of PII Leaks AcrossAndroid App Versions.” Internet Society, 2018. [Online].Available: https://www.ndss-symposium.org/wp-content/uploads/sites/25/2018/02/ndss2018 05B-2 Ren paper.pdf

[13] M. Ester, H.-P. Kriegel, J. Sander, and X. Xu, “A density-based algorithmfor discovering clusters a density-based algorithm for discoveringclusters in large spatial databases with noise,” in Proceedings of theSecond International Conference on Knowledge Discovery and DataMining, ser. KDD’96. AAAI Press, 1996, pp. 226–231. [Online].Available: http://dl.acm.org/citation.cfm?id=3001460.3001507

[14] D. Birant and A. Kut, “ST-DBSCAN: An algorithm for clusteringspatialtemporal data,” Data & Knowledge Engineering, vol. 60, no. 1,pp. 208–221, Jan. 2007. [Online]. Available: http://linkinghub.elsevier.com/retrieve/pii/S0169023X06000218

[15] R. Montoliu and D. Gatica-Perez, “Discovering human places of interestfrom multimodal mobile phone data,” in Proceedings of the 9th Interna-tional Conference on Mobile and Ubiquitous Multimedia. ACM, 2010,p. 12.

[16] L. O. Alvares, V. Bogorny, B. Kuijpers, J. A. F. de Macedo, B. Moelans,and A. Vaisman, “A model for enriching trajectories with semanticgeographical information,” in Proceedings of the 15th annual ACM in-ternational symposium on Advances in geographic information systems.ACM, 2007, p. 22.

[17] M. T. Khan, J. DeBlasio, G. M. Voelker, A. C. Snoeren, C. Kanich,and N. Vallina-Rodriguez, “An empirical analysis of the commercialvpn ecosystem,” in Proceedings of the Internet Measurement Conference2018. ACM, 2018, pp. 443–456.

[18] A. Mani, T. Wilson-Brown, R. Jansen, A. Johnson, and M. Sherr,“Understanding tor usage with privacy-preserving measurement,” inProceedings of the Internet Measurement Conference 2018. ACM,2018, pp. 175–187.

[19] “Standard representation of geographic point location by coordinates,volume = 2008, address = Geneva, CH, institution = InternationalOrganization for Standardization,” Standard, Jul. 2008.

[20] “Location-Android developer documentation,” https://developer.android.com/reference/android/location/Location.html/, 2018, [Online; accessed12-April-2018].

[21] D. Ashbrook and T. Starner, “Using GPS to learn significant locationsand predict movement across multiple users,” Personal and Ubiquitouscomputing, vol. 7, no. 5, pp. 275–286, 2003.

[22] L. O. Alvares, V. Bogorny, B. Kuijpers, B. Moelans, J. A. Fern, E. D.Macedo, and A. T. Palma, “Towards semantic trajectory knowledgediscovery,” Data Mining and Knowledge Discovery, vol. 12, 2007.

[23] F. Sebastiani, “Machine learning in automated text categorization,” ACMcomputing surveys (CSUR), vol. 34, no. 1, pp. 1–47, 2002.

[24] L. Kraus, T. Fiebig, V. Miruchna, S. Moller, and A. Shabtai, “Analyzingend-users knowledge and feelings surrounding smartphone security andprivacy,” S&P. IEEE, 2015.

[25] “Security Tips-Android developer documentation,” https://developer.android.com/training/articles/security-tips.html/, 2018, [Online; ac-cessed 01-April-2018].

[26] Y. Song and U. Hengartner, “Privacyguard: A vpn-based platform todetect information leakage on android devices,” in Proceedings of the 5thAnnual ACM CCS Workshop on Security and Privacy in Smartphonesand Mobile Devices. ACM, 2015, pp. 15–26.

[27] B. Biggio, K. Rieck, D. Ariu, C. Wressnegger, I. Corona, G. Giacinto,and F. Roli, “Poisoning behavioral malware clustering,” in Proceedingsof the 2014 workshop on artificial intelligent and security workshop.ACM, 2014, pp. 27–36.