Mastodon IzzyOnDroid


Say thanks!
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Buy at Amazon for EUR 16,99
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Buy at Amazon for EUR 7,00
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Buy at Amazon for EUR 5,00
 
dehelp

Android Identifiers: How Android devices and their users are identified

Dog Tags
Dog Tags, © Postdlf (CC BY-SA)
Source: Wikipedia

App reviews and security reports mention them regularly: identifiers which apps like to access. Identitifying information picked from the device and „getting transfered to somewhere“. In this context, terms like „Google Adverising ID“ or „Android ID“ are referenced.

What do they mean? And what other „identifiers“ are there? Which purposes are they supposed to serve initially – and what for are they used (or abused) in „real life“?

Background

Apps, but also many websites and other online services try to identify (and recognize) their users/visitors for different purposes like:

The argument goes, by installing an app the user has agreed to its permissions (as to the use of cookies etc. when visiting a website) – and thus (implicitly) also to the data collection. It´s doubtful we can speak of an „educated decision“ here: exceedingly few users are aware of the scale this collection goes into, or where they might end up.

There are several properties by which a user can be uniquely identified (lets call them „identifiers“ here). Some of them are rather unproblematic – others allow to draw far-reaching conclusions about a person. Some of them can be accessed by any app or website, others are somehow „protected“ by the Android permission system. To list up and explain all of them would mean a pretty long article, so lets stick to some essentials here.

Which identifiers exist, and what´s their respective purpose?

READ_PHONE_STATE
What an app can see without any permission required

By which permission can I tell that an app has access to a given identifier?

Though this was already mentioned in above list, here´s a short sum-up:

Possible protective measures

How can we protect identifiers against abusive access?

Without root

… possibilities are, as usual, quite limited. The most obvious step is to check the permissions of an app – best before installing it. Google Play Store (and especially the corresponding app) make that a hard job: both are very much hiding details on this. Easier (and more complete) this can be achieved by e.g. visiting the app´s page at AppBrain – or, if included, check the app lists on this site and click the app´s name. Do those raise an eyebrow, better keep your fingers off that app. Or at least consult the comments and your favorite forum before installing if you´re unsure whether those permissions are legit.

What – too late? You´ve already installed it? Well, those you can check on-device, e.g. using one of the available Permission Checkers. They might even tell you about „suspicious/dangerous combinations“. After the check, you might be tempted to de-install the one or the other app, and replace it by a more decent alternative (again, the app lists here might help you finding such). When in doubt, there´re again the comments, and the forums to ask.

As a minor prevention, you can also head to your device´s „developer settings“ and change the hostname to something more generic (e.g. localhost). Within limits, you can retract permissions from apps: on Android 4.3 to 5.x using an AppOps FrontEnd, and on Android 6+ using the on-board permission front-end. But that´s rather cosmetical, as security expert Mike Kuketz concludes:4 it´s much too coarse-grained, and some essential permissions are not even listed.

Sometimes it can help to contact the corresponding developer – who often isn´t even aware how intrusive an included advertisement or analytics module is.5 So getting to know, he might be willing to replace it by something „lighter“ and more privacy-friendly.

With root

Xprivacy
Xprivacy: Random values

… much more is possible:

Further readings

appsprivacy


  1. For details on ADB, see the article ADB for end-users here at IzzyOnDroid ↩︎

  2. According to ArsTechnica, access for „normal apps“ is possible via ACCESS_FINE_LOCATION resp. ACCESS_COARSE_LOCATION↩︎

  3. Statistics on how many apps request a given permission are based on the 13k+ Apps listed at IzzyOnDroid, as of 8/2016 ↩︎

  4. Mike´s Blog is focused on security topics. In his article Das Android Berechtigungsmodell: Ein perfides Konstrukt sheds a lot of light on the Android permission system and its shortcomings. An absolute must-read! If you can´t read it in German, try Google´s translation ↩︎

  5. For example, Flurry Analytics is quite intrusive, see App Analytics Raises Privacy Concerns ↩︎

  6. On Xprivacy and the XPosed Framework, also see the article Xposed: The mighty Android toolbox here at IzzyOnDroid ↩︎

2016-08-22 (2017-09-12)