Posted on

Advertising identifiers as links between mobile app activities

Two unrelated apps do not need to share a login to recognize the same advertising identifier.

That is the point of the mobile advertising ID.

On Android, Google describes the advertising ID as a unique, user-resettable and user-deletable identifier supplied for advertising. Apps and advertising SDKs can retrieve a consistent value associated with the device user and use it for advertising functions such as personalization and measurement. See Google Play’s Advertising ID documentation and Android’s Advertising ID developer guide.

That consistency is useful to advertisers.

It is also what makes the identifier capable of linking activity across apps.

One value can join separate event streams

Imagine a weather app reports:

ad_id = ABC123

Later, a game reports:

ad_id = ABC123

A third app reports the same value.

If the same advertising system receives those events, it does not need the three app developers to exchange customer accounts directly.

The common identifier gives the system a join key.

Activity that looked separate at the app level can become one advertising profile at the network level.

The identifier itself does not contain a person’s name, search history, or purchases.

It becomes meaningful because databases attach events and attributes to it.

Resetting or deleting changes the link

Google’s current Android guidance lets users reset or delete the advertising ID through system settings. On supported Google Play services, deleting it causes attempts to retrieve the ID to receive a zeroed value instead. Google also warns developers not to cache the value because a user may reset it. See Google Play’s Advertising ID guidance.

That gives the user a real control.

A reset can break the straightforward continuity between the old identifier and the new one.

It does not guarantee that every company forgets everything it previously knew.

Historical records may remain subject to retention rules and policies, and other signals can create new connections.

The advertising ID is only one bridge

Apps can also recognize logged-in accounts, email addresses, phone numbers, app-specific identifiers, purchase records, IP-derived information, or other device and network signals.

Android itself distinguishes the advertising ID from other identifiers and provides newer privacy controls around advertising systems. See Android’s ad privacy settings.

So disabling one advertising identifier should not be described as a universal invisibility switch.

It removes or weakens one standardized connection.

That distinction matters throughout the Surveillance Economy.

The dangerous part of a dataset is often not any individual row.

It is the column that lets somebody join one table to another.

On mobile devices, the advertising ID was designed to be exactly that kind of column.

Posted on

Mobile apps that cannot be reinstalled after delisting

Flappy Bird left the App Store and Google Play in February 2014, pulled by the developer who designed it and then watched it climb to the top of both download charts. It had been downloaded more than 50 million times. New players could no longer get it, and as the LA Times reported, phones with the game preinstalled were briefly listed on eBay, one reaching a bid of nearly $100,000 before the auction was pulled. The game was not destroyed. The stores just stopped handing it out, which for most people was the same thing.

Why a working copy stops being enough

A delisted app lives on a device, but it reaches new devices through a store, and the store is the first point of failure. For years, a previously purchased iOS app stayed downloadable from the Purchased tab even after it vanished from search. That was policy, though, not physics, and policies get revised.

They were revised on a large scale with iOS 11. Apple’s 64-bit transition notice was precise: support for 32-bit apps was gone, and 32-bit apps already installed on an upgraded device would not launch. That is a compatibility failure rather than a simple delisting failure, but for preservation the result is similar: keeping the binary is not enough if the current operating system refuses to execute it. A working old app may require a compatible old device and operating system.

Android reaches a similar place by different routes. Android 14 blocks ordinary installation of apps targeting below API 23, and Android 15 raises that floor to API 24; Google’s Android 15 behavior documentation records the change and notes that already-installed older apps remain after an upgrade. Google Play has a separate distribution policy: as of August 31, 2026, stale apps that do not meet the current target-API requirement become unavailable to new users on newer Android versions. The store and the operating system therefore impose two different kinds of aging.

And none of that touches the backend. A delisted app that needs a login, a feed, or a marketplace is a corpse in a chair even when it installs cleanly. Plenty of apps survived delisting only to die when a company shut down its servers or let its certificates expire.

What preservation actually keeps

The two platforms recover differently. Android packages can often be preserved and installed on compatible systems outside Google Play, although newer Android versions increasingly block very old targets by default. On iOS, Apple still provides a purchase-history redownload path, but redownload does not solve incompatibility and it depends on Apple continuing to serve a compatible copy. A preserved binary, a compatible operating system, and any required backend all matter separately.

A preserved copy is therefore evidence more than it is a working program. Archives hold the binary, the screenshots, the documentation, and the review threads — a fair record of what the app was and who used it. Getting it running again requires a compatible-enough operating system, an acceptable signature, and sometimes a live server that no longer exists.

A previous download was never an archive. Delisting removes the reinstall, update, and trust channels along with the store page, so the software does not die so much as become unreachable — and unreachable is how most software now goes extinct. If you have an app you care about, keep the file, keep the version that matches your device, and assume the store will not be holding it for you.