On an iOS 8 device, I installed Google Hangouts and upon first launch, it pre-populated an account that was previously associated with a different, and long ago deleted, Google app.

Since I had just Reset Advertising Identifier, I assumed it must be the Vendor ID (there was another Google app installed on the device). So, I deleted both (all) Google apps on the device, which should reset the Vendor ID.

I then re-installed Google Hangouts and launched it. It STILL had the old account active. This is not only mysterious behavior, but is also a pretty serious security and privacy vulnerability. When an app is deleted, and especially when all apps from a vendor are deleted, there should be no active accounts or data left on the device.

Any ideas on how Google Hangouts knows about the old account?

3 Answers 3


Apple advises developers to store app login credentials in the encrypted iOS Keychain. When you delete an app from your phone it doesn't delete the related records from the Keychain.

Keychains are secure storage containers, which means that when the keychain is locked, no one can access its protected contents. In OS X, users can unlock a keychain—thus providing trusted applications access to the contents—by entering a single master password. In iOS, each application always has access to its own keychain items; the user is never asked to unlock the keychain. Whereas in OS X any application can access any keychain item provided the user gives permission, in iOS an application can access only its own keychain items.


  • This seems to be the most likely mechanism, but If this is indeed the mechanism Google is using (or any app for that matter), it seems insanely insecure and a severe privacy violation. I got access to another person's Google login simply by installing an app from Google when no other Google apps existed on the device. It looks like there is a way that newly installed apps should clean up: stackoverflow.com/questions/4747404/… but Hangouts didn't do this. There also does not seem to be a way for a user to delete non-Safari Keychain items.
    – pseudon
    Aug 9, 2015 at 5:01
  • It's a big Apple security/privacy problem that Keychain items are not cleared when an app is deleted (or, worst case when the last of a vendor's apps is deleted). It's also an Apple problem that there is no easy way for users to delete individual (non-Safari) Keychain items. And it's a Google security/privacy problem that they allow a login to persist across app deletion (including deleting all Google apps).
    – pseudon
    Aug 9, 2015 at 5:03
  • I don't agree that this is a big security/privacy problem. If someone gave you their device and was concerned about their data they should have wiped it first. I'd never give a device to someone with data still on it. There is no mechanism for an app to delete its keychain items, so you can't really fault Google here either. I would agree though that it would be good if Apple gave us a way for us to edit our keychain, similar to the way you can go into Safari settings on an iOS device and edit the saved credentials. Aug 9, 2015 at 13:12
  • Yes, if I was getting rid of a device, I'd wipe it, though I'm sure many people forget to or don't know how. But I do think this is very counterintuitive behavior. It's common to share an iPad among family and/or friends, but that shouldn't imply persistent active logins to deleted apps.
    – pseudon
    Aug 9, 2015 at 13:49
  • Another use case is deleting the app (or even all apps in the app group), but later wanting to re-install an app with with a new identity not linked to the old one. If the old data restores from backup, this becomes impossible.
    – pseudon
    Sep 15, 2016 at 17:33

It probably uses iCloud as a method, possibly the iCloud Key-Value Store.

As far as that storage goes…

The total space available in your app’s iCloud key-value storage is 1 MB per user. The maximum number of keys you can specify is 1024, and the size limit for each value associated with a key is 1 MB. For example, if you store a single large value of exactly 1 MB for a single key, that fully consumes your quota for a given user of your app. If you store 1 KB of data for each key, you can use 1000 key-value pairs. The maximum length for a key string is 64 bytes using UTF8 encoding. The data size of your cumulative key strings does not count against your 1 MB total quota for iCloud key-value storage; rather, your key strings (which at maximum consume 64 KB) count against a user’s total iCloud allotment.

(Source: Apple Developer Conceptual Reading for iCloud Key-Value Storage's Data Limits, see link above)

In short, developers can access data through iCloud's KV pairs through NSUbiquitousKeyValueStore, store objects storable in an NSDictionary (up to 64K per item, up to 1024 keys, and the total size must be less than 1 MB), and retrieve them later.

Edit: iCloud Key-Value storage isn't as secure as Keychains. Google might use Keychains, but they might also store encrypted data on the Key-Value store, considering iCloud has security issues. Maybe use the device's name as a way to de-encrypt?

  • The Google apps had no permissions for iCloud, so more likely to be Keychain.
    – pseudon
    Aug 9, 2015 at 4:59
  • @pseudon KVS doesn't need permission.
    Aug 9, 2015 at 5:22
  • Possible then. This would also be counterintuitive behavior to a user, who would never expect an app to be able to store an active login persistently in his iCloud, especially for a deleted app. Can an app use iCloud KV Store if iCloud isn't signed in or in use at all on the device?
    – pseudon
    Aug 9, 2015 at 13:53
  • @pseudon not that I know of.
    Aug 9, 2015 at 13:53

...in iOS an application can access only its own keychain items

Vendors can share data across their applications, using the Keychain as long as they are using a keychain group, defined in the entitlements in their app bundle; "it's own" means vendor, not application.

As others have pointed out, the keychain entries may not get cleaned up implicitly.

Since this widest scope of this type of 'tracking' is limited to a single vendor with apps installed, this significantly reduces the security risk surface area (compared to UUID or UIPasteboard sharing - both removed/closed).

It is important to note that Apple's products are currently designed for "single users"; Apple does not yet offer user partitioning (for example, any registered fingerprint unlocks the entire device, so if you have a friend/child with a registered fingerprint, they get exactly the same access as you).

Adding to the answers by DDPWNAGE and Alistair (since I don't have enough rep to comment) but specifying how all Google apps can access exactly one keychain entry.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .