32

Some android apps are can remember whether they were installed on the same device earlier. Suppose you uninstalled an app a year ago. After one year if you install that same app again, that app will be able to recognize that it was installed before on the same phone.

This technique is used by online applications to permanently ban users from ever creating a new account again if they have been banned from using the service once. When such users create a new account by reinstalling the application later, these apps are able to detect their "first time presence" and send this information to servers so that user can be banned again.

How they do it even after clearing their data and uninstalling them completely? It means they keep some file somewhere in the phone, which is not deleted after uninstall. How do I disable this detection?

  • Why do you want to delete this information? Do app creators have rights? I don't expect this to be a popular comment, but consider whether you have taken the time and trouble to create an app. – S. Mitchell Sep 25 '16 at 17:21
  • 6
    @S.Mitchell Today Some app developers and big advertising companies try to access unnecessary details from innocent users. Not only they want MAC Address but they also want to know your wifi SSID.Google gave them a good lesson by implementing which permissions you don't want to give them in android 6. But the advertisers are not stopping here, they always find a way to get around. I want to ensure this privacy system. – defalt Sep 25 '16 at 17:35
  • 1
    @S.Mitchell Hello Mitchell. You might be judging me wrong because of my question. No I'm not banned from any social or online services and neither from stack exchange if you doubt that. But for me knowing is learning. I'm not doing any practical work with the answers I've been received here. But definitely they help one to know how things work. One can't create anti-hacking security if one doesn't know how to hack. The same analogy is here. If I can't learn how apps work there is no point I'll be able to make one. – defalt Sep 26 '16 at 2:24
  • 7
    @S.Mitchell: Do app creators have rights? Actually, on my phone, they don't. I might let them run their code and store their data on my phone, but they don't have a right to and I reserve the right to revoke both privileges at my discretion. – dotancohen Sep 26 '16 at 8:43
  • 2
    @S.Mitchell i would encourage answers to all questions regardless of why you think they exist. good thing you don't run this site! – ell Sep 26 '16 at 15:38
32

There are multiple ways to identify a unique device or its user:

  1. Keep a file in some (non-default) directory: You already said this; apps can often write to the internal storage of a device. This method is easy, works offline and is not the easiest to spot (place the file in some system-like directory and nobody will bother deleting it).
  2. Keep track of a devices unique ANDROID_ID (unique per fresh installation): this method is simple but requires internet access, at least on the first use. It's not very intrusive and does not persist in case of a factory reset. It's also unique per user. See this information.
  3. IMEI: Very intrusive, unchangeable but requires a SIM-capable device. The IMEI is unique for each device, cannot be changed and doesn't follow the user, meaning that if you sell your device, the new owner will be greeted with a screen telling him that the app was already on the phone.
  4. Follow a user's Google account: This is pretty much the same as the ANDROID_ID approach but requires explicit permission (Android 6.0+) from the user to access. Apps that take advantage of the Google account ecosystem (e.g. highscores and achievements in games) can thus follow a specific user and gain more information than just whether the app has been installed or not.

2, 3 and 4 require a network connection and a server on the side of the developer.

  • I can manage 2,3&4th part using Xprivacy. I'll spoof each of them. But the first one, that is not easy to spot. Is there anyway I can detect this vulnerability? – defalt Sep 25 '16 at 16:56
  • 3
    It's not a vulnerability, just an abused feature. Much like applications keeping files in the registry. There is not much you can do apart from going through all the directories on your phone's internal storage and looking for suspicious files. – GiantTree Sep 25 '16 at 17:02
  • 1
    Good luck finding/making this app. The system can't crash because of some missing file on the internal storage. Generally, apps tend to use the same frameworks that use the same files but, as you already pointed out, those files are impossible to find (not always, but most of the time). Files that contain things like "id", "user" or similar often contain such an ID and those ID's are usually used for advertising. – GiantTree Sep 25 '16 at 17:29
  • 2
    @S.Mitchell No I'm never been banned from any online services, web applications and online gaming. But I believe that knowing about how system works behind its interface is the right step to move forward in android development. – defalt Sep 26 '16 at 2:31
  • 8
    @user334283 "never know what file name you are searching". This is false. Android, being a linux OS, has the strace utility that can be used to keep track of all system calls. So you have to start your app using strace and check all system calls related to files on the device and you will spot all the files read/checked for existance by the app. Sure: probably quite hard to do on the smartphone but definitely possible. – Bakuriu Sep 26 '16 at 8:21
2

It is not connected to storage, but to the cloud. That is how it remembers even though you deleted your data. In order to switch this off, go to your device's settings app, tap accounts google under personal (tap account you want if you have multiple accounts), then switch off the apps you don't want to auto-sync.

  • Auto-sync is not the root problem. Third-party party servers make sure that their app is capable of collecting your MAC Address, IMEI, Device ID, Advertising ID and store this to servers for detecting the device again in future. Spoofing these details will keep your privacy but if an app is writing "registry entries" like in windows problem will be undetectable. – defalt Sep 25 '16 at 17:01
2

GiantTree's answer covers it best, but there is another point to think about. It would clearly be a "dark pattern" but this identification could also be done through fingerprinting certain user data - this can be viewed as a variant on his first point ("keep a file") but it would be harder to detect and less convenient to avoid.

How resilient this is would depend on the data chosen. The most obvious method would be looking at contact details and using some form of fingerprint of this; an alternative might be use of photo timestamps and other metadata. Clearly these change over time so whatever method was used would need to still give a close answer after modification (so it differs from a traditional hash function). Also there is no guarantee that a user doesn't simply wipe the tracked data, but in many cases people will prefer not to do this.

You may wish to look at browser fingerprinting to get a sense of how this works, even though it is going to be somewhat different because phone hardware is typically more uniform than PC hardware. That said, the addition of certain phone details may help narrow the fingerprint down a bit.

Where this approach breaks down in particular is if a user switches phones and takes their details with them to a new phone - in this case (unless phone details are going into the fingerprint) the new phone might be detected as already having had an installation, as the question asked. However it seems quite likely that in a scenario where an app is trying to ban a user, this might actually be a desired outcome (rather than banning the specific phone itself)

Please note: In no way am I saying this is correct or "good" as a way to operate if you're writing apps, but it seems reasonable to discuss it as it is only through discussion that people will figure out whether they're concerned enough to do something about it and what that might be.

1

There is a SharedPreferences class - https://developer.android.com/reference/android/content/SharedPreferences.html - that some apps use to store preference data. This data is not deleted when the app is uninstalled. If the app is later reinstalled, any previously saved SharedPreferences keys are still available to it.

  • 6
    SharedPreferences are actually deleted when the app is uninstalled. There are ways for developers to set up backups, but by default they are removed upon uninstall. (Source: As a developer, I uninstall my apps to clear the preferences. Also see: stackoverflow.com/a/9815641/1438733) – Eric Sep 26 '16 at 0:22
1

There's another possibility - use of persistent cookies with a very large "time to expire". i guess that's how multiple apps from same developer used to share credentials traditionally, when stored credentials via the accounts feature was not so open/known to the public.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.