https://orcid.org/0000-0002-7289-4264
ABSTRACT
Location-based services can provide many benefits to their users but sharing one’s location with third parties also incurs privacy risks. As one way to mitigate this, the two major mobile operating systems provide an approximate location feature, which enables users to only share their approximate location instead of their precise location. In order to assess the usefulness of this feature in practice, we analysed 36 iOS and 36 Android apps regarding the impact of using approximate location had on the functionality and usability in practical use. To achieve this, we used each app following a structured methodology with both precise and approximate location and recorded differences in app behaviour. Our results show that using approximate location caused many of the apps’ functionalities to stop working, although some functionalities were more affected than others. We also observed differences regarding which functionalities were most affected and which operating system the app was running on. Our results shed light on the practical use of approximate location in common apps and can benefit researchers interested in location privacy and app use.
1. Introduction
Location-based services (LBS) are computer applications (especially mobile applications), which deliver information tailored to the user’s location (Huang et al. Citation2018) and have become ubiquitous over the past decade. Location information and the user’s current location play a key role in providing a broad range of tailored LBS. This includes navigation systems, which help users to orient themselves in unfamiliar environments and provide directions to their destination. Fitness trackers record the route a user took during a run to calculate useful information. Food delivery apps suggest nearby restaurants or provide an estimated delivery time. Further common use cases include mobile guides, social networks, gaming, healthcare, transport, assistive technology, disaster and emergency, citizen participation, education, entertainment, insurance, billing and production processes in factories (Huang et al. Citation2018).
However, while LBS provide many different useful services, they also incur privacy and security risks. In a typical LBS, users send a query containing their location information to a server or the service provider, which then sends a response back (e.g. a list of nearby restaurants) (Jiang et al. Citation2021). Several privacy concerns are associated with this approach. The LBS provider may use the location data for purposes other than delivering the requested service (e.g. user profiling) or sell it to third parties such as advertisers and private investigators (Jiang et al. Citation2021). The LBS server may also be compromised in a malicious attack (Jiang et al. Citation2021). Even anonymising location data does not guarantee privacy as there are multiple deanonymisation attacks, e.g. using publicly accessible background information (Jiang et al. Citation2021). If an adversary has access to a user’s location data they can identify the user’s key locations (i.e. workplace and home address) and infer other sensitive information from it, such as political orientation, religious affiliation, health status, sexual orientation, economic condition and social relationships (Jiang et al. Citation2021).
Many users are aware of at least some of these privacy concerns (Barkhuus and Dey Citation2003). Previous studies have shown that concerns regarding app access to personal location information can result in various user behaviours. This can include deciding not to instal an app at all due to the ”exact location” requirement, uninstalling apps after learning they were accessing personal location information or disabling location services altogether (Fawaz, Feng, and Shin Citation2015; Fu and Lindqvist Citation2014). Against this backdrop, both Apple and Google have incrementally introduced more location privacy features in their mobile operating systems. In particular, app-specific settings that enable users to choose between sharing their exact or approximate location were introduced in 2020 to iOS (Apple Citation2021) and in 2021 to Android (Google Citation2023a). Prior versions of Android also differentiated between precise and approximate location, but only as a system-wide setting.
Providing such a feature at the OS level is only one-half of the story, though. The other half is how this is feature is implemented in various LBS. In theory, many LBS could function well using only approximate location. Weather apps (Shejwalkar et al. Citation2019) or local recommender apps, for example, could provide the same service quality as with precise information. For other LBS, service quality might be reduced when using approximate location. For example, navigation apps may no longer be able to provide turn-by-turn instructions but could instead provide orientation information (Schwering et al. Citation2017). For some apps, however, switching to approximate information would render them unable to provide their service. This applies, for example, to location-based games using augmented reality, as having just access to approximate location would prevent them from properly overlaying content in augmented reality.
In practice, however, app behaviour depends on how developers implemented it, e.g. whether the app adapts to receiving just approximate location information or not. If an app refuses to function at all when not allowed to access precise location information – regardless of whether it actually needs precise location to provide its services -, then users are in the same position they were in before the introduction of the approximate location feature. If an app accepts working with only the approximate user location, it remains to be seen how useful it still is and what service quality it can still provide. We expect some apps to stop working at all, either for technical (e.g. lack of implementation) or conceptual (e.g. precise location for navigation instructions) reasons. Other apps might adapt to approximate location or simply treat the approximate location as precise location.
The goal of the work presented here is thus to assess how popular location-based apps respond to having to work with approximate location instead of precise location. For this purpose, we analysed 72 popular and publicly available LBS in total to identify differences in terms of their user interface (UI) and user experience (UX) when using approximate location instead of precise location. Our main contributions consist of (1) a methodology to systematically analyse differences in app use when using approximate location; (2) a list of differences observed in publicly available apps that result from using approximate location; and (3) a report on the status quo of how popular location-based services behave when using approximate location. While the latter two contributions provide only a snapshot in time, they still highlight how apps behave in practice with approximate location turned on. By applying our method in the future, other researchers can systematically document changes in app behaviour over time and extend the analysis to other apps as well.
In the following, we first provide a short overview over related research and fundamental concepts related to approximate location in LBS. After describing and motivating the methodology we used, we present the results we obtained. The paper concludes by first discussing the results and then summarising our main findings.
2. Related work
In this section, we first review related academic sources that cover approximate location and LBS. We then briefly describe how approximate location is implemented in practice.
2.1. Approximate location in research
Approximate location is often discussed in the context of location data privacy and obfuscation mechanisms for privacy protection. Providing coarse or approximate location information is a frequently mentioned obfuscation mechanism, which is also implemented by both major mobile operating systems (OS).
In terms of actual use of the approximate location in practice, Fu and Lindqvist (Citation2014) carried out an online survey with 106 participants on how Android users understand the meaning and accuracy of approximate and precise location. Most users thought that precise location corresponds to their actual location while approximate location to the general area and assumed that the area covered by approximate location would have been much larger. Hence, the number of people who thought that approximate location would not protect their privacy properly doubled. One limiting factor here is that the study was carried out in 2014, years before approximate location controls became available in mobile OS.
In 2015, Fawaz, Feng, and Shin (Citation2015) analysed the effectiveness of OS controls in mitigating privacy threats and discovered for over a thousand apps which location granularity was required to achieve the apps’ (full) functionality. They developed a tool, which helps users to better use OS-based location-access controls, and evaluated its impact on the quality of service on the apps Yelp and Facebook in a user study with 242 participants. In the study, the tool added noise to the location accessed by Yelp and Facebook. Yelp users had to report their satisfaction with the list of restaurants returned by the app, while Facebook users had to provide feedback on whether the list of places to check-in was relevant to them. At the time of the study, authors conclude that the privacy controls offered by mobile operating systems are insufficient (because they only leave a binary choice between full or no privacy) and demonstrate that more fine-grained user control is indeed possible.
Micinski, Phelps, and Foster (Citation2013) studied how location truncation, which maps the user’s current location to a specified grid cell quite similar to what iOS does nowadays (Apple Citation2022), affects app utility. They recorded the output of six Android apps, which produce lists of nearby objects, in regions of different population densities. For each location, the truncation grid spacing was varied from 0.1 km to 50 km. Three metrics were developed to measure the impact of location truncation on the output lists of the apps: the edit distance is the number of edits (insertions, deletions, swaps) needed to change the list created under the effect of truncation to the reference list; the additional distance computes how much farther a user who always picks the first item in a list would need to travel; and the set intersection size counts how many objects are in both lists created under the effect of truncation to the reference list. Most of the tested apps were still able to provide a sufficient service at a truncation level from 5 to 20 km.
Fan and Gote (Citation2021) evaluated a number of computational location privacy methods regarding utility and privacy using two real-world trajectory datasets. To evaluate utility they introduced two classes of utility metrics: distortion metrics and mobility metrics. The distortion metrics class included the Hamming distance (which measures whether the obfuscated location differs from the input location) and the Haversine distance (which measures how far the obfuscated location is from the input location). The mobility metrics included the total distance covered, maximum distance, standard deviation of the displacements, maximum distance from home, radius of gyration, number of different places and number of different significant places. The authors conclude that it is indeed possible to balance service utility and users’ location privacy.
Huguenin et al. (Citation2018) studied the Foursquare users’ motivation for their location check-ins and proposed a predictive model to quantify the effect of geographic and semantic obfuscation on the utility of check-ins. They ran a personalised online survey providing participants with four alternatives to the precise location normally used by Foursquare and asked them to what extent the purpose behind their check-in would still be met by those alternatives. The alternatives were combinations of low or high semantic and geographical obfuscations. The semantic obfuscation was obtained by choosing an ancestor in Foursquare’s semantic hierarchy (for example, ”restaurant” instead of ”burger joint”), the geographical obfuscation was obtained by revealing only some of the geographic information (for example only the city instead of the street name and number). Based on their work, the authors claim that more than 60% of user check-ins still serve their purpose while an obfuscation method is applied.
Oya, Troncoso, and Pérez-González (Citation2017) evaluated the utility loss caused by geo-indistinguishability mechanisms, an approach based on differential privacy, through two metrics: the average Euclidian distance between the user’s actual and obfuscated location and the radius of the circular region centred around the user’s actual location where the obfuscated location is with probability 0.95. In their research, the authors highlight that some desired levels of location privacy protection cannot be achieved without a significant decrease of service utility.
Shejwalkar et al. (Citation2019) argued that using a generic distance-only-based metric to evaluate the quality loss caused by obfuscation mechanisms is misleading and metrics tailored to the LBS should be used instead. They designed a privacy-preserving ride-hailing service and demonstrated the differences between a generic and a tailored metric for this service. As generic quality loss metrics they used the average Euclidian and average squared Euclidian distance. As a tailored metric, they used the difference in time to complete a ride when hailing location is real versus obfuscated. Their findings thus also highlight the need to assess the impact of location quality on an app-by-app basis.
Many studies presenting obfuscation mechanisms tend to focus on the utility loss associated with their use (Fan and Gote Citation2021; Huguenin et al. Citation2018; Micinski, Phelps, and Foster Citation2013; Oya, Troncoso, and Pérez-González Citation2017; Shejwalkar et al. Citation2019). When these studies investigated publicly available apps, only a small number of similar apps was considered, for example, two (Fawaz, Feng, and Shin Citation2015) or six (Micinski, Phelps, and Foster Citation2013). In contrast, the work reported in this paper analyses a substantial number of different apps on both Android and iOS to study the effect approximate location has on them. We can also observe that many previous research efforts relied mainly on using distance-based utility metrics, an approach that Shejwalkar et al. (Citation2019) have criticised for neglecting user- and domain-specific effects. More specific utility loss metrics included the difference in time to complete a ride when hailing location is real versus obfuscated (Shejwalkar et al. Citation2019), metrics for lists of nearby objects (Micinski, Phelps, and Foster Citation2013) and the users’ satisfaction with a list of restaurants or locations to check-in (Fawaz, Feng, and Shin Citation2015). Our research complements previous research by deriving common functionalities across a diverse set of apps, which can be used to characterise the differences apps display when being provided with approximate location compared to precise location. Findings regarding the usability of services while using location privacy protection mechanisms indicate that sufficient service quality may be maintained (Fan and Gote Citation2021; Huguenin et al. Citation2018; Micinski, Phelps, and Foster Citation2013). Others argue that it is quite often not possible to protect the users’ location privacy without significantly decreasing service quality (Oya, Troncoso, and Pérez-González Citation2017). The work we present here adds a new perspective to this discussion by looking at apps and location privacy protection mechanisms in practice: apps and features that are actually available to users on mobile operating systems (see next section).
2.2. Approximate location in practice
When computing location estimates, modern mobile operating systems consider multiple data sources: the modem, which connects to the cellular network, and a number of sensors, such as GNSS receivers, Wi-Fi and Bluetooth receivers, barometers as well as gyroscopes and inertial measurement units (IMUs) (García, Maier, and Phillips Citation2020). The two most widely used OS provide users with similar controls over how the applications can access this location information. In line with suggestions by (Fawaz, Feng, and Shin Citation2015), today’s mobile operating systems now offer more fine-grained control over location data. Both allow users to decide for each app individually whether that app can access location information once, while in use, all the time or never. In addition, the user can now also choose whether an app receives precise or approximate location information. This approximate location feature is realised differently in Android and iOS.
Since Android 12, users can decide for each app individually to only receive approximate location data, while in older versions this change was system-wide and would affect all apps (Google Citation2023a). Approximate location is provided with an accuracy of about 3 sqkm (Google Citation2023b). Android uses three providers to identify the user’s location. The GPS provider uses both GPS and assisted GPS (GPS data collected by cellular towers) and provides the most accurate location. The Network provider uses a combination of Wi-Fi and Cellular data as well as assisted GPS and provides a location of varying accuracy. The Passive Provider uses providers requested by other applications (Microsoft Citation2022).
Since iOS 14, it is possible to share only an approximate location with individual apps (Apple Citation2021). For this feature, Apple divided the planet into fixed regions. The user’s location is quantised into these regions and the amount of quantisation varies according to the region’s population density. In dense urban areas the amount of quantisation can be a few kilometres but in rural areas in can be 10 km or more (Apple Citation2022). The quantisation radius will typically be about 5 km (Apple Citation2022). The feature tries to place the approximate location somewhere where the user expects to be; for example, if the user is near a country’s border, their approximate location is on the correct side of the border (Apple Citation2022). With approximate location there are about four location updates in an hour (Apple Citation2022). iOS uses GPS, Bluetooth and crowd-sourced WLAN-hotspot and cell tower locations to obtain a user’s approximate location (Apple Citation2023).
Consequently, even though both OS provide very similar controls to their users, what actually happens behind the scenes when approximate location is enabled, might differ in terms of how those estimates are computed and which location is returned when the feature is enabled. While Apple provides some information on how approximate location is realised (Apple Citation2022), Google stays quite vague in their available materials (Google Citation2023b). Neither method is described in sufficient detail to be fully replicable.
3. Methodology
In order to select a meaningful collection of location-based services and to systematically analyse the impact of using approximate location information, we followed the methodology outline in the following subsections.
3.1. App selection
In order to cover a broad range of widely used apps that use location information, we focused on obtaining popular apps from different categories in a systematic way. We created fresh accounts on both operating systems to avoid usage histories or personalisations affecting the lists presented by the app stores.
We used only information from the App Store and Play Store in Germany to select the LBS for our study. We mainly relied on the free-of-charge rankings as well as the ‘Must-Have’ and ‘Popular Apps’ lists. More specifically, we used the individual category charts to ensure that also apps from less common categories were included in the analysis. These apps might include less common use cases while being ranked highly within their category but not high enough on the overall charts to be selected.
We scanned the top 20 entries in each category on the App Store and Play Store for apps that were available on both platforms and used location services. We excluded categories without a ranking as the lack of a ranking was an indication for domains that were not so popular. In order to identify which apps used location, we used the location service information in the data privacy information of the stores.
Since the App Store and Play Store do not use the same categories, we re-categorised the apps for consistency. Some categories provided by the stores were also very broad, which resulted in many very similar apps being at the top of the rankings. In those cases, we further subdivided such categories into subcategories, and for each subcategory, we included the top app in the selection process. Categories and subcategories can be found in .
Table 1. Points awarded for different chart positions during app selection process.
Table 2. Apps included in our analysis with category and subcategory.
Finally, the candidate apps, which resulted from the filtering process outlined above, were ranked according to their popularity. We designed a simple point-based system, which awarded each app with points according to its position within the category and overall charts and whether it appeared on the ‘Must-Have’ and ‘Popular Apps’ lists. shows the point distribution for the charts. For example, if an app was in the top five of the category charts it received four points. If an app was listed in multiple categories, the category where it had the highest chart position was considered. For the overall charts (comprising apps of all categories), we applied the same principle. For example, if an app was within the top 100 to 150 it scored two points. This was done twice, once for the app’s position in the Play Store charts and once for the App Store charts. Additionally, if an app was listed in the App Store’s ‘Must-Have’ and ‘Popular Apps’ lists or the Play Store’s ‘Popular Apps’ list, the app received an extra point for each list they were included in.
As both the position within the category charts and the overall popularity of the app (as indicated by the overall charts and the ‘Must-Have’ and ‘Popular Apps’ lists) were considered, the calculated ranking should be a good indicator as to which out of a number of similar apps is the most popular. One disadvantage of this method is that the charts are constantly changing and as such, while the top apps on the day of collecting the ranking information (10 May 2022) might have been the most popular ones at that time, just a day later other apps could have taken those top spots. It might have been more accurate to take the top apps from a period of time, say a week or a month.
3.2. Exclusion criteria
In order to ensure all the selected apps were indeed location-based services that were readily available to any user, we excluded any app that did not meet all of the criteria listed below:
At least one function of the app depends on location information. This function must be easily found during normal handling of the app. In the settings, the app must ask for location permission and allow to use both precise and approximate location. The app must require location permission on both platforms (iOS and Android).
The app is free-of-charge and does not require a paid subscription to work properly.
The app does not require an additional device (i.e. fitness tracker, dash cam) to work properly.
The app is available in either English or German (since those were the languages the authors were fluent in).
The app does not require information that is too personal in nature (i.e. bank account information). If the function of the app that used location information was usable before it became necessary to input personal information (like in most shopping apps), we still considered the app to fulfill this criterion.
The app is usable at one of the analysis locations (the city of Münster, the city of Essen and the Haard forest, which are all located in Germany).
The app is suitable and available for minors.
The selection process yielded 36 apps that met all the criteria listed above, were available on both operating systems and received the highest scores according to our ranking scheme. shows the resulting list with all the apps we included in our analysis. An extended table () including provider and version numbers for each app can be found in the Appendix.
3.3. Analysis
The apps were analysed by one researcher on two test devices: an iPhone SE (second generation) with iOS 15.4 and a Google Pixel 6 with Android 12. Each app was used in one of three locations in Germany: the city of Münster (mostly at the university library ULB), the city of Essen (mostly at the central library) and the Haard forest (near Marl Sinsen). All test sites were located in Germany. The first two represent urban areas whereas the third location was a natural one. The latter was chosen for apps that involved activities like hiking or walking, which are frequently performed in natural environments. During the analysis only the automatic location provided by the location service of the respective OS was used. The user’s current location was never manually entered, e.g. by clicking on a map or entering an address.
Previous work on analysing the usability of location-based services and mobile apps has employed various methods. Recent work in the field of location privacy research looked at how informed consent was used regarding location sharing and found that many apps employ dark patterns to nudge their users to enable location sharing (Dreyer et al. Citation2022), where the authors applied a manual procedure. For our analysis, we were interested in the impact of approximate location on the usability of LBS. Frequently, standardised questionnaires and models such as SUS (Brooke Citation2013), NASA TLX (Hart Citation2006) or key-stroke level models (Holleis et al. Citation2007) are used to assess the usability of a service. One of these models is the PACMAD usability model (Harrison, Flood, and Duce Citation2013) that considers seven attributes to evaluate the usability of an application: effectiveness (whether users can complete specific tasks), efficiency (users can quickly and accurately complete their task), satisfaction (users’ level of comfort during use of the application), learnability (users’ ease at gaining proficiency with an application), memorability (users’ ability to retain how to use an application effectively), errors (how well users can complete their task without errors) and cognitive load (amount of cognitive processing required by the user). Furthermore, the PACMAD model identifies three factors which can affect the usability of a mobile app: the end user (e.g. possible physical limitations, level of experience), the user’s goal (e.g. its complexity, ease to accomplish it) and the user’s environment (e.g. their physical location, interaction with people and objects, other tasks users are trying to accomplish) (Harrison, Flood, and Duce Citation2013). Inspired by the PACMAD method, we focus on the effectiveness of LBS when using approximate user location. We derive app-specific user goals for analysis and use the apps in the appropriate real environment.
The analysis for each app took place in two phases. The goal of phase one was to familiarise ourselves with the app by using it with precise location. Location-based functionality and location visualisations were documented. A list of the discovered location-based functionalities can be found in the results section. Then, one to three app-specific use cases to reach certain goals were created, executed and documented.
We derived the use cases from typical goals that a user might want to achieve with an app and that required the user’s location to complete. shows some examples for how these were specified for three different apps. We then recorded the steps needed to achieve this goal with precise location. Where use cases involved creating user accounts or payments, we selected a different use case that still relied on the user’s location for completion. An extended table () including all use cases for every app we tested can be found in the Appendix.
Table 3. Examples of app-specific user goals and corresponding use cases we executed during our analysis.
Phase two had the aim to investigate app behaviour while using approximate location. Before first starting an Android app, the permissions for this app were set to use approximate location and ”only while in use”. Since this was not possible for iOS, we set permissions after starting the app. After switching from precise location to approximate location the apps tended to remember the last used precise location. In order to ensure the app only relied on the approximate location during our analysis, we either reinstalled the app or the app’s storage was cleared (Android). We then investigated whether the location-based functionalities were affected by using approximate location. We realised this by using the apps as intended or apparent from their user interfaces while going through the use cases. A functionality was classified as being unavailable when the app was not able to provide it. In such cases, the reason for its unavailability (or how the app responded differently to how it would when using precise location) was noted. The analysis of the use cases focused on the differences in terms of the steps that users had to take in order to reach the goal of a use case while using approximate location compared to precise location. We analysed whether the apps needed more or fewer steps or whether the steps were in a different order. It was also noted whether the use case could be completed successfully when using approximate location. Furthermore, the analysis focused on discovering how the apps requested permission to use precise location and on additional differences at the user interface level and in user experience between the two settings, such as how the user’s location was represented in maps and text.
4. Results
In the following, we report the results of our analysis, focusing first on how using approximate location affects various common LBS functionalities. We then detail how the app-specific use cases were affected as well as how the user’s current location is visualised or communicated by an app. Finally, we report on observations regarding apps requesting to use precise location when configured to use approximate location.
4.1. Impact on LBS functionality
We used each app with precise location to identify the location-based functionalities they provided. These functionalities were then grouped into nine categories:
4.1.1. Finding nearby points of interest (POI)
A common function of the analysed apps was finding nearby POI. These included businesses like restaurants and transportation hubs like bus stations. Means of transportation such as e-scooters were also included as well as other traffic-related facilities such as parking spots. Further examples included apartments for rent, houses to buy, bike/hiking tours and geo-tagged digital items.
4.1.2. Sharing location
Some apps allow users to share their location with others. This was predominantly offered in the context of a chat or an image. Users can decide to share their location once or to share their ”live” location for a set amount of time. Additionally, users can add a location sticker to images.
4.1.3. Auto-filling location information
Many apps provided text fields, in which the user could type the address of their current location. To save time and effort, many apps also provided a function to automatically fill the user’s current location into those text fields. This function could be triggered immediately upon opening a page, or it could be activated by clicking on a button or an option in a drop-down-menu.
4.1.4. Routing
Functionalities which allowed the user to get a route from or to their current location are included in this category. The other end point of the route could be any point of interest or any set of coordinates, often chosen by clicking on a spot on a map. The route could simply be a line on a map or it could consist of a set of instructions. Functionalities included routes for different modes of transportation, e.g. walking, biking, driving, using public transportation. Advanced functionalities in this category were updating the route as the user moved along it and showing the user’s progress.
4.1.5. Distance/Time calculation
Many apps used the user’s location to calculate the distance between the user and a POI, or to give an estimated travel time based on that distance. Examples for functionalities in this category include showing the user’s distance to a POI, showing the time it would take the user to walk to a POI, or giving an estimated delivery time for a food order.
4.1.6. Sorting/Filtering
This category consists of functionalities that enable the user to filter or sort a list of results according to their current location. This includes filtering results within a certain radius of the user location or sorting them according to their distance. Filtering/sorting could either be triggered manually or results could be pre-sorted/pre-filtered automatically.
4.1.7. Information about the user’s location
Functionalities in this category first collect the user’s location, and then gather and present information about that location. Examples include the current weather or weather forecast, information about native birds and plants, information about the local mobile network, information about whether the user is in the delivery area of an app, or information about local electricity/broadband providers and their rates.
4.1.8. Recording/Tracking
The primary purpose of all functionalities grouped in this category is to record the user’s location or trajectory. For example, they record it as a delivery address, as a home or work address, or as the place of an observation (e.g. of a bird/plant, of a hazard on the street). By recording the user location continuously, an app can capture the route a user took. For this route statistics can be calculated for, e.g. distance, time, elevation, speed, calories burned.
4.1.9. Mapping the user’s location
Functionalities in this group include showing the user’s location on a map and zooming in on the user’s location.
These categories are not exclusive. Most of the analysed apps provided functionalities from multiple categories. shows the percentage of the location-based functionalities across the tested apps. Of the 72 apps, 86.1% mapped the user’s location, 63.9% aimed at finding nearby POI, 55.6% automatically filled in the user’s location, and 47.2% showed the distance or time between the user and a POI. Approximately 36.1% of the surveyed LBS sorted or filtered the results according to distance, 30.6% relayed information about the user’s location, 27.8% recorded or tracked the user’s location, 16.7% calculated a route from or to the user’s location, and 13.9% allowed the user to share their location.
Figure 1. Percentage of functionalities using location information in the surveyed apps.
When an app uses precise location, it can provide all its functionalities. With approximate location, this is not always the case: For example, when a user wants to share their approximate location, upon clicking on the button, instead of sharing the location, a pop-up or system dialogue appears, asking the user to activate precise location. This dialogue appears every time the user clicks on the button, making it impossible to share their approximate location. Consequently, the functionality of sharing location effectively has completely stopped working for this app when users only want to use approximate location.
Furthermore, there is a difference between apps providing location-based functionalities and these functionalities being useful to the user when using approximate location. It is possible that due to the nature of approximate location, the user might feel that the functionality does not actually work or is (severely) limited. For example, if an app maps the user’s location as a point when using approximate location, the marked position on the map will not correspond to the user’s real location but to the obfuscated location determined by the approximate location feature. Technically, the app did the same thing when using approximate location as it does when using precise location. It was provided with a location and mapped it as a point, and the user also went through the same steps as they took when precise location was activated. The execution of the function also was not stopped by the appearance of a system dialogue requesting permission to use precise location. However, from a user perspective, the experience is quite different: with precise location, the dot on the map corresponds to their actual location and helps them to orient. With approximate location, the dot might be somewhere else and might actually confuse them about where they are.
The next part of the analysis only focused on whether the app provides a functionality at all when using approximate location, not whether the outcome of the service was of use to the user. We wanted to ascertain how many functionalities were ”blocked”, how common it was that apps prevent the user from accessing a functionality when approximate location was activated, and how the functionality was blocked. shows the percentage of all functionalities, which do not work or work in a limited way when using approximate location (split by operating system). Overall, 44.9% of functionalities did not work with approximate location. This number is made up of 10.7% iOS apps and 34.2% Android apps. The functionality that most frequently was blocked was sharing location, which we observed in 70% of the apps providing this functionality. For the other functionalities, we observed the following outcomes in descending order of frequency: routing (66.7%), recording/tracking (55%), distance/time (50%), autofilling location (47.5%), sorting/filtering (46.2%), finding nearby POI (45.7%), mapping user’s location (44.9%) and information about user’s location (30.7%).
Figure 2. Percentage of cases where specific categories were inaccessible when using approximate location for iOS and Android apps.
For each category, functionalities of Android apps are more frequently unavailable or are working in a limited way when using approximate location. The smallest difference between both platforms was observed in the functionality sharing location while the largest difference occurred with the functionality of mapping the user’s location. The main reason these functionalities did not work was the different behaviour of the apps when using approximate location. For example, instead of a button performing its usual functionality it causes a system dialogue to appear and the user is essentially blocked from accessing that functionality unless they give the app permission to use precise location. Below, we list the different behaviours the apps exhibited that prevented the user from accessing location-based functionalities:
4.1.10. Menu or menu items missing
For example, in the Android app Lieferando.de, the entire bottom navigation bar was missing, the map and filtering/sorting options disappearing with it. In the Android app Ebay Kleinanzeigen, the option to sort by distance was missing from the drop-down-menu. In the Android app Snapchat, the location stickers option disappeared.
4.1.11. List of results missing
This happened, for example, to the functionality finding nearby POIs. Instead of a list of nearby POIs, an empty page or a page with a text message, saying no results could be found or the app needs location information, would be shown.
4.1.12. System dialogues or pop-up windows appear
Upon clicking on a button, a dialogue would appear instead of the normal functionality. These dialogues most frequently requested permission to use precise location. When denied, the button would often either cause the dialogue to reappear or become inactive. These dialogues or pop-ups did not always inhibit the apps’ functionalities. Sometimes the user can deny permission to use precise location and still advance further to access the functionalities. In some cases the pop-ups held a non-specific error message which did not explain that the cause was most likely the use of approximate location instead of precise location.
4.1.13. Interface elements disabled from the get-go without a dialogue appearing first
In the Android app EVENTIM DE, for example, the user can usually check a box to filter the results according to distance, but with approximate location activated that box is visible but disabled.
4.1.14. Maps do not load, are shown at an inconvenient scale or show the wrong location
The Android app what3words, for example, was zoomed in on Bristol instead of Essen when using approximate location and being actually located in Essen. Many of the surveyed apps’ showed a map of Germany or a map of Earth instead of a local map.
4.1.15. Information is not provided
For example, when given the precise location the Android app Ebay Kleinanzeigen showed the distance from the user’s location to where items were offered. However, when using approximate location that distance was missing while everything else looked the same.
4.1.16. Indefinite waiting
In some cases, apps would actually wait for an indefinite amount of time when approximate location was used. The Android app wetter.com, for example, would be able to add the user’s current location to the list of saved locations in a few seconds when using precise location, but with approximate location the loading circle kept on spinning even after the minute mark.
4.1.17. Functionalities not available
The app behaves exactly as it would when using precise location, but the functionality is not offered to the user at all. For example, the user sets filtering options, but gets results from all over Germany, or the user clicks on share location in a chat, but then the location is not sent and it always says to retry.
Often one functionality also depended on another. For example, when no list of results was provided, the distance to a POI could not be shown either. Overall, 47 apps (65.28%) we analysed had functionalities that were limited or unavailable when only approximate location was used. System dialogues or pop-ups were by far the most common behaviour we observed (27 apps, 37.50%), which is in line with previous findings regarding apps trying to nudge users to enable (precise) location sharing (Dreyer et al. Citation2022). Disabled interface elements and map errors (13 apps each, 18.06%) were the second most frequent behaviours. The other behaviours only occurred rarely (single-digit percentages). Indefinite waiting, for example, was observed in three apps (4.17%).
4.2. Impact on typical use cases
When people use an app, they typically do not test each functionality individually. Rather, they use the app in order to achieve a specific goal. Therefore, the apps were also analysed with respect to whether they could fulfill the typical use cases a user might have. In contrast to the analysis of the apps’ functionalities, here the effect of approximate location on the successful completion of the use cases was considered. Even if all the functionalities involved in a use case worked with approximate location, we considered it as not successfully completed if the result did not fulfill the user’s goal. To determine which use cases were not completed successfully, we first followed a fairly strict approach. If a use case’s goal was made up of multiple functionalities and one of those functionalities was not provided, then the use case was considered as not successfully completed. For example, one use case of the iOS app Lieferando.de had the goal to find the nearest Italian-style pizza restaurant for pick-up, go to check-out and get a route to it. This goal necessitates the app to provide multiple functionalities, some of which it did. For example, it was able to provide a list of nearby restaurants and sort it by distance. However, the nearest restaurant on that list, while being the closest to the user’s obfuscated location, was not the closest to the user’s real location. And the route to the restaurant also used the obfuscated location as a start point and as such was wrong. Due to the strict requirements this caused the use case to be categorised as not completed successfully.
During the analysis it became apparent that some use cases’ goals might have been too difficult. The user’s goal was often fairly specific and used several location-based functionalities while having access to partial functionalities could still provide utility to the user. For example, if users are not looking for the nearest restaurant but just a list of nearby restaurants, from which they then choose which one they prefer, then it does not matter to the user that the nearest restaurant is actually only the second closest restaurant to their actual location.
To give a more nuanced picture, an additional ‘soft’ goal was defined to the original ‘hard’ goal. To assess soft goals, we used the data from the hard goal analysis. For several use cases the soft and hard goal were identical. Only use cases which used multiple location-based functionalities had a different soft goal defined. This soft goal was based on the assumption that the user was mainly interested in one functionality while the other (minor) functionalities the app provided were a bonus they were willing to relinquish for the protection of their privacy. Additionally, for the soft goal the user was willing to put up with a reduced service. If the hard goal asked for the nearest POI, then the soft goal asked for a nearby POI.
The main differences between soft and hard goals is that soft goals did not require the functionalities of auto-filling addresses, getting a route to a POI, or getting the nearest POI to the actual user location. In , the percentage of successfully completed use cases can be seen for both the soft and hard goals (split by operating system). When considering the soft goals, we were able to classify only a few more use cases as successfully completed. Overall, 38.1% of use cases with a soft goal identified as successful opposed to the 29.7% when looking at a hard goal. The increase was not evenly distributed across both platforms: twice as many iOS use cases than Android use cases were re-categorised as successfully completed with the soft goal.
Figure 3. Percentage of successfully completed use cases for the hard and soft goals.
We also analysed each use case regarding whether the user needed fewer or more steps when using approximate location or whether the steps were in a different order. We found that the steps were always in the same order. It was never the case that a use case required fewer steps when using approximate location. However, there were instances where additional steps were needed compared to using precise location. Most frequently, this involved closing pop-ups and system dialogues requesting the change to precise location. Eleven percent of use cases required extra steps that were not pop-ups or system dialogues. Using the app Bolt, for example, involved identifying the nearest e-scooter to the user’s location. The app’s map is zoomed in on the obfuscated location, but the user can then navigate to their real location (if known) within the map and find the nearest scooter to them that way. The Android app ImmoScout24 at first glance does not allow auto-filling the location in the search bar. There is, however, a workaround to get similar functionality that involves extra steps: users can first click on ‘draw search area on map’ and then ‘radius search’, which results in the app automatically setting the location. In other cases, the extra steps were basic operations such as having to click one more button.
4.3. Impact on communicating users’ location
The way in which apps communicated the users’ current location – both visually on a map and textually – differed substantially when approximate location was activated.
In terms of depicting the users’ current location on a map, we observed five distinct approaches. Locations were visualised as
a point or a different symbol (e.g. marker, pin),
a point inside of a small circle (the circle had a radius of 5 to 40 m),
a point inside of a big circle (the circle had a radius of 2 to 7 km),
a big circle (the circle had a radius of 2 to 7 km), or
not portrayed at all.
The circles usually correspond to an estimation of the location data’s accuracy. If the user’s location was portrayed as a point inside of a circle, but that circle obviously did not show the accuracy (because the radius was adjustable or the circle was too big), we counted this as a point visualisation. If an application had used multiple methods of portraying the user’s location, only the most accurate method was recorded.
As shown in , when given the precise location most apps portrayed the user’s location as a point (49%). Thirty-three percent showed a point inside of a small circle. Eighteen percent of apps did not portray the user’s location on a map at all. This includes apps which did not use maps as well as apps, which zoomed in on the user’s location but did not mark it in any way. When receiving the approximate location, however, most apps did not portray the user’s location at all (47%). Frequently with apps in this category, we observed that maps were inaccessible, would not load, or were zoomed out to the country-level. Half as many apps (22%) portrayed the user’s location as a point when they received the approximate location compared to the precise location case. With approximate location enabled, apps portrayed the user’s location also as a big circle (22%) or a point in a big circle (8%). These visualisations were never used when the apps received the precise location, while point in small circle was only used when precise location was enabled. breaks down how apps on different platforms visualised user locations. Again, app behaviour was markedly different depending on which platform the app ran on.
Figure 4. Visualisation of the user’s location when precise or approximate location was activated.
Figure 5. Visualisation of the user’s location when precise or approximate location was activated, separated by platform.
Overall, we can thus observe that many apps tend to portray the user’s location in a way which also provides information about the location data’s accuracy, choosing to use a precise way of portrayal (e.g. a point or point in a small circle) when receiving precise location and a more coarse way of portrayal (e.g. a point in a big circle or a big circle) when receiving approximate location. Some apps, however, continued to portray the user’s location in a precise way when receiving approximate location. In those cases, the point on the map did not correspond to the user’s real location but rather to the obfuscated location.
The same is true for the category ‘Point in big circle’. The point in the middle of the circle marks the obfuscated location, while the user’s real location is somewhere in the circle. If users are aware of where they are, this visualisation does not pose much of a problem. However, if the user is in an unfamiliar environment and uses the app with the purpose of identifying their location, this could potentially cause problems as users might mistake the obfuscated location for their real location. Of course, this also depends on whether the user is aware which location granularity they have set for the app and what that location granularity means.
Rather than using a map to convey the user’s location, some apps presented it in text form. For example, the user’s location would be given as a full address, a street name, a city district, a postal code, a city or as coordinates. As with the map visualisations, we only recorded the most precise way an app portrayed the user’s location in text.
shows the differences in this portrayal when the apps were given the precise or approximate location. Compared to the portrayal of the user’s location on a map, there are less differences when the user’s location is given in text form. The percentage of apps giving a city or a street name for the user’s location remains very similar regardless of whether the apps receive approximate or precise location. For the categories ‘City District’ and ‘Coordinates’ the number of apps is too low to draw conclusions. The number of apps portraying the user’s location as a full address fell by about two-thirds (from 22% to 7%) when switching to using the approximate location. Eleven percent of apps gave a postal code for the user’s location when using precise location, but only 1% when using approximate location. Conversely, slightly more apps (from 14% to 17%) portrayed the user’s location as a city when using approximate location. Substantially more apps stopped conveying the user’s location in text form altogether (from 43% to 68%).
Figure 6. Textual communication of the user’s location when precise or approximate location was activated.
All apps which portrayed the user’s location as a full address, street name or coordinates showed an incorrect location when only given approximate location. The categories ‘Postal Code’ and ‘City District’ fall somewhere in between a fine and coarse granularity. Whether they show incorrect information depends on whether the obfuscated location is far enough away from the real location that it falls into a different district or postal code region. That leaves ‘City’ as the only coarse way the user’s location was portrayed. When compared to the options ‘Big Circle’ and ‘Point in big circle’ that we observed for map-based visualisations, ‘City’ is a much less frequently used.
depicts app behaviour on the two platforms. While more iOS apps gave the city name for the user’s location when using approximate location (28%) compared to precise location (14%), the opposite was true for Android apps. Six percent of Android apps gave a city name when using approximate location and 14% with precise location. When switching to approximate location, the Android apps we analysed did not switch to a coarser location portrayal (i.e. city instead of full address), but rather either continued on with the same way of portraying the user’s location or stopped giving any location information in text form. The percentage of Android apps not portraying the user’s location nearly doubled from 44% when accessing precise location to 83% when accessing approximate location. For iOS apps, the numbers of apps providing a city name for the user’s location doubled when switching from precise to approximate location (from 14% to 28%). The percentage of iOS apps that did not portray the user’s location at all when using approximate location increased from 42% to 53%.
Figure 7. Textual communication of the user’s location when precise or approximate location was activated, separated by platform.
4.4. Requesting permission to use precise location
Depending on which permissions have been set for an app, when that app requests further permissions, the system dialogue appears differently. For our analysis, permissions were set to ‘only when in use’ (if the app explicitly asked for ‘always’, we used that option instead) and ‘approximate location’. We then used the apps and we recorded whether and how they requested permission to use precise location.
We found that no additional request was made for 75% of iOS apps but only for 8.3% of Android apps (see ). To request precise location, 44.4% of Android apps showed a system dialogue, while only 19.4% of iOS apps did (with additional 5.6% of custom dialogues followed by system dialogues on both platforms). Approximately 41.7% of Android apps showed the generic dialogue to prompt the user to activate location services, while no iOS apps did. Using a dialogue to ask users to activate location services is a questionable practice when the user already has location services and the approximate location enabled. This could lead the user to the false conclusion that location services are deactivated for this app. If the user now wants to activate location services the dialogue offers no information on whether they will activate precise or approximate location for this app. During the analysis, giving permission through this system dialogue always activated precise location. So, when the app requests permission to access location services and the user accepts, thinking they are activating approximate location, they are actually activating precise location. This is not communicated to the user when making the decision and is only visible when they go to settings of the app.
Figure 8. How apps requested permission to use precise location, categorised by OS.
Some apps reconfigured their user interface in response to using approximate location, e.g. by changing the functionality of certain elements. For example, in one app, the location button was overlaid with a question mark. Upon clicking this button, the map would not centre on the user’s current location but a system dialogue appears and the user can activate precise location. Other apps instead provided an additional button, for example, a button labelled ‘Precise Location: Off’. When clicking on this button a system dialogue appears and the user was asked to switch on precise location. If the user does indeed switch, however, this button disappears providing no quick way to re-active approximate location. A third example for reconfigured UIs was adding a button as a short-cut to the settings with a text label next to asking the user to activate location services in order to find nearby facilities. Again, when precise location was activated, these apps did not do provide a similar shortcut to switch to approximate location.
5. Discussion
Overall, we found many differences when approximate location was activated compared to precise location. These differences varied in terms of type and severity from the users’ perspective, including functionalities being completely unavailable, not providing the service the user wants, the user’s location being presented as a circle instead of a point, and trying to nudge the user to provide access to precision location. Apps provided fewer functionalities when using approximate location and reduced numbers of successful use cases show that the approximate location feature had an impact on the apps’ usability. The analysis found that the degree of impact was also related to which functionalities a LBS provided. For example, apps that allow the users to share their location were the most likely to not provide this service at all with approximate location. Related research in the field indicates that larger numbers of location-based services are still usable with mechanisms for location privacy preservation (Fan and Gote Citation2021; Huguenin et al. Citation2018; Micinski, Phelps, and Foster Citation2013) while others highlight a significant service quality decrease (Oya, Troncoso, and Pérez-González Citation2017). Our results draw a similar picture. Nevertheless, this observation might not be so surprising: Especially if one considers apps that depend on precise location information (e.g. navigation systems), a degraded service quality or complete failure to deliver a core functionality with approximate location is to be expected.
Considering the PACMAD method mentioned in Section 2, the effectiveness attribute is also the one most related research focused on. The analysis we reported on here was performed at a more general level that facilitates comparing apps across different categories rather than carrying out fine-grained measurements that would have required multiple extensive uses of each app and also might be specific to a category (see limitations below). We also uncovered numerous different app behaviours and UI re-configurations, which the apps showed with approximate location and which have not been mentioned in previous research. These also impact usability beyond the attribute effectiveness, e.g. by requiring users to take additional steps. In 58% of apps, the user had to deal with dialogues requesting access to precise location and in 11% of apps, they had to take other additional steps. Issues such as missing menus, missing results, error messages, inactive buttons and endless waiting might confuse the user and slow the execution of their task. Here, one issue is especially critical: When an app treats approximate location information as precise location information, e.g. simply displays the user’s location on a map as if it was precise location information, users might get confused. Another factor, that hinders usability, is obtrusive requests for precise location permission that block the user interface, something that can be considered as a dark pattern (Dreyer et al. Citation2022). This leads to a number of implications for app users and developers: First, developers should explicitly consider the use of approximate location for their location-based services and not simply treat it as precise location. Approximate location should not be treated as second class location but the new norm to protect the users’ location privacy. This also entails not forcing the users to grant access to their precise location. On the other hand, users should also make use of the approximate location feature. If they do so, they might need to keep in mind that they have only shared their approximate location with an app and the LBS might thus not work as expected. From our perspective, this will most likely be a long-running process: Developers need to adapt their apps to cater for approximate location while still delivering a service while users must get used to sharing their approximate locations (see section on future work below).
5.1. Limitations
The presented work is subject to several limitations. It is important to highlight that our findings are based on a relatively high-level analysis. To get a more complete picture of how approximate location affects LBS usability, larger studies with diverse users are needed. As highlighted in Section 3, we only looked at a small subset of the PACMAD model. In a much larger future study, we could incorporate the whole model. A further potential limitation of our study relates to how the approximate location feature is actually implemented and how that affects apps. Different implementations and inner workings of both Android and iOS might have influenced our study. Furthermore, the app assessment was carried out by a single researcher rather than a group of raters. The researcher has also defined the use cases and made the app selection. Regarding the app selection, working with app stores might make reproducing the analysis hard: Depending on what app stores know or assume about a user, the presented apps might differ from user to user. Those factors might have led to more subjective results. In addition to expanding the number of apps beyond the ones we analysed in our study, carrying out a field study with actual non-expert users trying to achieve specific goals while using approximate location, would yield deeper insights into practical and individual implications. In a first step, the participants could actively contribute to the app selection and use case definition, before carrying out and reporting on the use cases in a second step. An additional limitation of our work is the fast-paced evolution of our technological environment. The analysis was carried out in 2022. As mobile platforms develop rapidly, a repeated analysis might lead to a vastly different result in the future.
5.2. Future work
Apart from the points we have named to overcome the aforementioned limitations, future work on the topic of location privacy and approximate locations with respect to LBS could benefit from different study designs. Instead of using mobile apps only for a short time, it would be very insightful to run a logging or diary study with participants exclusively using approximate location for an extended period while going about their regular day-to-day lives. This way, we could gather deeper insights. In addition, it would be very interesting to further investigate how LBS can effectively cope with only having approximate location available. This could include designing and evaluating different ways to visualise approximate location (along the lines of Ranasinghe, Krukar, and Kray Citation2018) or developing and testing different strategies to provide a service, for example, switching from turn-by-turn directions to orientation information (Schwering et al. Citation2017).
6. Conclusion
In this paper, we reported on a systematic study investigating the impact of using approximate location instead of precise location in popular, publicly available location-based apps. We selected 36 apps for each of the two big mobile operating systems from different categories (for a total of 72 apps) and analysed them with respect to their usability. We identified a set of core functionalities shared by many apps and found that a significant share of the functionalities offered by the reviewed LBS were not available when using approximate location. Some functionalities such as location sharing were more affected than others. The reasons for why these functionalities became unavailable also varied, from menu items disappearing to persistent request to share precise location information and indefinite loading.
While we looked at functionalities individually, we also analysed the LBS in the context of common use cases. Here we also found that many use cases could not be completed successfully when approximate location was activated. In some use cases, it was possible to access the location-based functionality but due to the coarse granularity of the user’s approximate location that functionality was not helpful in achieving the users’ goal. Overall, only a third of the use cases could be completed successfully with the approximate location feature, and 11% of use cases featured extra steps the user needed to take compared to when they shared their precise location.
We also investigated the way in which the LBS communicate the current location to users. We found that only in a minority of cases, the apps adapted their visualisations or textual description to reflect that an approximate location was communicated. In addition, some apps requested access to the precise user location when prompted to show where the user was located. In some cases, this was done in an intransparent and confusing way that could trick users into disclosing their precise location.
Finally, we noted differences with respect how the reviewed LBS reacted to approximate location information depending which operating system they ran on.
Our findings shed light on how using approximate location affects LBS and paves the way for further interesting research in this area (as outlined in Section 5). Summarising, we can thus conclude that – while the approximate location functionality might in principle have the potential to provide a compromise between privacy and usability – further work is needed to develop user interfaces, visualisations and strategies to provide high-quality LBS with only approximate location information.
Disclosure statement
No potential conflict of interest was reported by the author(s).
Data availability statement
The data that support the findings of this study are openly available in OSF at https://doi.org/10.17605/OSF.IO/JNY29.
Additional information
Funding
References
- Apple. 2020. “What’s New in Location.” Accessed September 25, 2023. https://developer.apple.com/videos/play/wwdc2020/10660/.
- Apple. 2021. “About iOS 14 updates.” Accessed September 25, 2023. https://support.apple.com/en-us/HT211808.
- Apple. (2023). “Location Services & Privacy.” Accessed September 25, 2023. https://www.apple.com/legal/privacy/data/en/location-services/.
- Barkhuus, L., and A. K. Dey. 2003. “Location-Based Services for Mobile Telephony: a Study of Users’ Privacy Concerns.” In Human-Computer Interaction INTERACT ‘03: IFIP TC13 International Conference on Human-Computer Interaction, edited by M. Rauterberg, M. Menozzi and J. Wesson. Amsterdam, Netherlands: IOS Press.
- Brooke, J. 2013. “Sus: a retrospective.” Journal of Usability Studies 8 (2): 29–40.
- Dreyer, J., S. Heitmann, F. Erdmann, G. Bauer, and C. Kray. 2022. “‘Informed’ Consent in Popular Location Based Services and Digital Sovereignty.” Journal of Location Based Services 16 (4): 312–342. https://doi.org/10.1080/17489725.2021.2017495.
- Fan, L. and I. Gote. 2021. “A Closer Look: Evaluating Location Privacy Empirically.” In SIGSPATIAL ’21: Proceedings of the 29th International Conference on Advances in Geographic Information Systems, 488–499. New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/3474717.3484219.
- Fawaz, K., H. Feng, and K. G. Shin. 2015. “Anatomization and Protection of Mobile Apps’ Location Privacy Threats.” In 24th USENIX Security Symposium (USENIX Security 15), Berkeley, CA, USA: USENIX Association. 753–768, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fawaz.
- Fu, H. and J. Lindqvist. 2014. “General Area or Approximate Location? How People Understand Location Permissions.” In WPES '14: Proceedings of the 13th Workshop on Privacy in the Electronic Society, 117–120. New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/2665943.2665957.
- García, A., S. Maier, and A. Phillips. 2020. Location-Based Services in Cellular Networks: From GSM to 5G NR, 73–74. Norwood, USA: Artech House.
- Google. 2023a. “Android 12 and Android 12 release notes.” Accessed September 25, 2023. https://source.android.com/setup/start/android-12-release?hl=en.
- Google. 2023b. “Request Location Permission.” Accessed September 25, 2023. https://developer.android.com/training/location/permissions#approximate-request.
- Harrison, R., D. Flood, and D. Duce. 2013. “Usability of Mobile Applications: Literature Review and Rationale for a New Usability Model.” Journal of Interaction Science 1 (1): 1–16. https://doi.org/10.1186/2194-0827-1-1.
- Hart, S. G. 2006. “NASA-Task Load Index (NASA-TLX); 20 Years Later.” Proceedings of the Human Factors and Ergonomics Society Annual Meeting 50(9): 904–908. https://doi.org/10.1177/154193120605000909.
- Holleis, P., F. Otto, H. Hussmann, and A. Schmidt. 2007. “Keystroke-Level Model for Advanced Mobile Phone Interaction.“ In CHI ‘07: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 1505–1514. New York, NY, USA: Association for Computing Machinery.
- Huang, H., G. Gartner, J. M. Krisp, M. Raubal, and N. V. de Weghe. 2018. “Location Based Services: Ongoing Evolution and Research Agenda.” Journal of Location Based Services 12 (2): 63–93. https://doi.org/10.1080/17489725.2018.1508763.
- Huguenin, K., I. Bilogrevic, J. S. Machado, S. Mihaila, R. Shokri, I. Dacosta, and J. P. Hubaux. 2018. “A Predictive Model for User Motivation and Utility Implications of Privacy-Protection Mechanisms in Location Check-Ins.” IEEE Transactions on Mobile Computing 17 (4): 760–774. https://doi.org/10.1109/TMC.2017.2741958.
- Jiang, H., J. Li, P. Zhao, F. Zeng, Z. Xiao, and A. Iyengar. 2021. “Location Privacy-Preserving Mechanisms in Location-Based Services: A Comprehensive Survey.” ACM Computing Surveys 54 (1): 4. https://doi.org/10.1145/3423165.
- Micinski, K. K., P. Phelps, and J. S. Foster. 2013. “An Empirical Study of Location Truncation on Android.” In MoST 2013: Mobile Security Technologies Workshop. https://www.cs.tufts.edu/jfoster/papers/most13.pdf.
- Microsoft. 2022. Location Services on Android. Accessed September 25, 2023. https://docs.microsoft.com/en-us/xamarin/android/platform/maps-and-location/location.
- Oya, S., C. Troncoso, and F. Pérez-González. 2017. “Is Geo-Indistinguishability What You are Looking For?.” In WPES ’17: Proceedings of the 2017 on Workshop on Privacy in the Electronic Society, 137–140. New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/3139550.3139555.
- Ranasinghe, C., J. Krukar, and C. Kray. 2018. “Visualizing location uncertainty on mobile devices: cross-cultural differences in perceptions and preferences.“ Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies 2 (1): 30. https://doi.org/10.1145/3191762.
- Schwering, A., J. Krukar, R. Li, V. J. Anacta, and S. Fuest. 2017. “Wayfinding Through Orientation.” Spatial Cognition & Computation 17 (4): 273–303. https://doi.org/10.1080/13875868.2017.1322597.
- Shejwalkar, V., A. Houmansadr, H. Pishro-Nik, and D. Goeckel. 2019. “Revisiting Utility Metrics for Location Privacy-Preserving” Mechanisms. In ACSAC ’19: Proceedings of the 35th Annual Computer Security Applications Conference, 313–327. New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/3359789.3359829.
Appendix
Table A1. Apps included in our analysis with version numbers, category and subcategory.
Table A2. All app-specific user goals and corresponding use cases we executed during our analysis.