Anyone who uses a mobile app knows how convenient the features that use location data can be, from getting turn-by-turn directions and finding nearby restaurants to fitness-tracking and weather integration. But these rich mobile “experiences” – as app developers call them – can be a double-edged sword. All too often, mobile apps have bugs that leak location data and can cause concerns around privacy or even physical safety — so a best practice is to limit when those apps collect that information.
However, in Android, users have only been given two choices: To have apps track their location all the time, or to turn off location-tracking completely.
Google’s Android division is taking a step to address this. Android developers will soon be able to give users a choice of three options for when to provide location to an app. Those choices are all the time or never. Now they have a third choice – while the app is in use.
“Previously, a user had a single control to allow or deny an app access to device location, which covered location usage by the app both while it was in use and while it wasn’t,” said Jen Chai, product manager at Android, in a posting last week. “Starting in Android Q, users have a new option to give an app access to location only when the app is being used; in other words, when the app is in the foreground.”
So, a Yelp-like app can be allowed to use the user’s location only when they open it to search for a restaurant nearby; but an app that automatically tracks the mileage someone drives for tax purposes can be given the greenlight for background data collection. Users will see their new options in the same permissions dialog that is already presented when an app requests access to location.
The change brings Android in line with the options available with Apple iOS apps.
Developers writing for Android Q will need to actively add the new permission information if their apps have a feature requiring “all the time” permission; in Android 9 or lower, the ACCESS_BACKGROUND_LOCATION permission will be automatically added by the system.
Chai offered developers advice for best practices around privacy, too: “Consider asking for the location permission from users in context, when the user is turning on or interacting with a feature that requires it, such as when they are searching for something nearby.”
In addition, she echoed a tenet put forth by the E.U.’s General Protection Data Regulation (GDPR): “Only ask for the level of access required for that feature. In other words, don’t ask for ‘all the time’ permission if the feature only requires ‘while in use’ permission.”
Ironically, last summer, an Associated Press report claimed that the Google services prevalent on both Android and iOS phones – including Google Maps – store location data via the Location History feature, even when device users opted out. Google denied the issue, noting that there was actually a way to opt out – and that in turn led to a lawsuit and a discussion about the value of clarity when it comes to providing user controls, and the ethics of embedding “dark patterns,” or exploitative design choices, into mobile interfaces.
“It’s disingenuous and misleading to have a toggle switch that does not completely work,” said Jesse Victors, software security consultant at Synopsys, in an email to Threatpost at the time. “When Google builds a control into Android and then does not honor it, there is a strong potential for abuse.”
The stakes are high: Mobile apps can collect location information in the background even when an app isn’t being used—which can be problematic if that data falls into the wrong hands. In addition to opening the door to unethical targeted advertising practices, it would also allow an adversary to track someone’s movements and gain a clear picture of their routines and daily habits. This could be exploited in a number of different ways, including using the information to mount more convincing phishing and social-engineering attack, assisting in reconnaissance for burglary or even child endangerment.
Click to Enlarge – Source: Pradeo
And indeed, location data is the fifth-most exfiltrated in cyberattacks on mobile devices, according to Pradeo’s mobile security report from February.
Further, vulnerabilities that allow easier access to location information are not uncommon.
For instance, in January the European Commission issued a recall for a popular smartwatch for children, citing “serious” privacy issues that could allow a bad actor to track or communicate with kids remotely.
And in November, a flaw in the Android mobile operating system was discovered that could allow an attacker with physical proximity to a WiFi router to track the location of users within the router’s range.
The issue (CVE-2018-9581) allowed information leakage stemming from inter-process communication. While applications on Android are usually segregated by the OS from each other and from the OS itself, there are still mechanisms for sharing information between them when needed. One of those mechanisms is the use of what Android calls “intents.”
An application or the OS itself can send an “intent” message out, which is broadcast system-wide and can be listened to by other applications. Without proper access restrictions and permissions put in place around these intents, it’s possible for malicious applications to intercept information that they shouldn’t have access to.
Don’t miss our free live Threatpost webinar, “Exploring the Top 15 Most Common Vulnerabilities with HackerOne and GitHub,” on Wed., Mar 20, at 2:00 p.m. ET.
Vulnerability experts Michiel Prins, co-founder of webinar sponsor HackerOne, and Greg Ose, GitHub’s application security engineering manager, will join Threatpost editor Tom Spring to discuss what vulnerability types are most common in today’s software, and what kind of impact they would have on organizations if exploited.
