An open source research tool and application that looks into the circumstances in which Android's permission model can be compromised to harm user privacy.

Note that we are not talking of exploits here, but normal usage of Android's APIs which can be manipulated in ways that can expose the phone user's privacy. For example. one issue is that apps can monitor the phone's screen state, which of course has legitimate uses. but can also be manipulated into:

"an app roughly figuring out from what time to what time you use your phone and for how many hours you are on the phone every day".

The privacy implication of this is that:

"this can be used to directly spy on a user and study his/her phone usage pattern".

The research also goes through the technical lowdown behind this issue:

Android sends a broadcast whenever the phone's screen turns on/off. So, if an app is running a service (whether it's foreground or a background service), it can continuously receive a broadcast when the screen becomes interactive/non-interactive (and then get the actual screen state using getState()).

It might legitimate, but it also doesn't require, the underlying app to ask for any permissions, which brings up the privacy implications. Hence the authors, after identifying the issue, make suggestions to the Android team in order to mitigate it. In the screen state case their suggestion was :

The screen state broadcasts need to be protected with permissions.

I think this makes one part of the equation. The other part would be for the Android team to incorporate those notices to educate the users on those issues and their implications. It's a scene all too familiar - when a user is about to install an app he gets bombarded with dialog boxes that ask of a variety of permissions.

If the user gets confronted with a message:

"Allow the application to monitor the screen state" 

that would create more questions than answers leading the user to become baffled.He would ponder:

"What does this mean? Should I allow it or not?"

So by also presenting him with the notice explaining the issue, a simplified version of the original leaving out the tech jargon, like:

Android sends a broadcast whenever the phone's screen turns on/off. So, an app can know when the screen becomes interactive/non-interactive.

In this way, the app can roughly figure out from what time to what time you use your phone and for how many hours you are on the phone everyday.This can be used to directly spy on a user and study his/her phone usage pattern.

would help him to make an educated choice about whether to give the app permission or not. So if the app at hand is a messaging app, then it has to monitor the screen state so that when the screen comes up again it would display the unread messages notifications. In that case, yes, allow it.

But if an app is, say, an image editor, why would it care about the screen changing state? It's a no-no here.But again the user should be thoroughly informed beforehand.

Used this way the project is more valuable than it initially seems. That is, in addition to bringing focus to the Android team, it also help users make informed decisions.

The project is also interesting from a developer's point of view because you discover use cases and several events fired by the Android OS which you can plug into. I got acquainted with the notion of Broadcasts and Services when doing the Android Developer Nanodegree, but I didn't know of several of the broadcasts outlined here, such as:

"app can monitor when you plug-in and remove your phone charger and headphones" 

which I found very interesting and would consider incorporating into future applications. I've learned how to do that by examining the accompanying source code of the project.

Of course the project examines those broadcasts from a privacy perspective;the developer outlook is considered a side effect or bonus that goes along with it.

The issues then are categorized by severity :

• 'Low severity' means that the issue has some negative impact on user's privacy, but it is OK as it has some legitimate use-case.
• 'Medium severity' means that the issue breaches user's privacy, but doesn't amount to spying and can merely be used for analytics by a company.
• 'High severity' means that the issue breaches user's privacy and can be used for spying (like monitoring your body movements and studying your behavior).

That's an indicator that sums up the apps' maliciousness. For instance, the screen state monitoring example is classified as 'high' because this can be used to directly spy on a user and study his/her phone usage pattern.

The issue with an app "that can monitor when you plug-in and remove your phone charger and headphones without any permissions" is marked as low "because, this has some legitimate use-cases like, if an app wants to run an important long running task, then it can do so when the phone is charging to make sure the battery is not drained".

The issue with an app that "can figure out at what time you switched on/off your phone without any permissions" is marked as low too since "this feature has some legitimate use cases like a service can properly do the cleanup task and shutdown smoothly when the device is shutting down. But, device uptime is a system information and providing it to all apps without any permissions can lead to some privacy concerns for the user."

Other issues explored are

• Apps installed on your phone can get to know at what angle you are holding your phone, in which direction your phone is facing and can determine if you are moving your phone or not, all without any permissions.
• An app can get a list of all the other apps installed on your phone without any permissions.
• An app can keep a track of your WiFi/Mobile data usage without any permissions.
• An app can get most of your device related information without any permissions.

The accompanying open source PrivacyBreacher app is available as an apk from its Github repo or from the Playstore. This means you can  test all these issues on your phone. - although the app supports only Android Pie (Android 9, API 28) or later versions, hence older phones won't be able to run it.

More Information

Android Privacy Issues research

PrivacyBreacher

PrivacyBreacher- APK on Github

PrivacyBreacher on Playstore

Related Articles

EU Bug Bounty - Software Security as a Civil Right

Insider's Guide to Udacity Android Developer Nanodegree - Full Stack Android

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info