The two-second ad auction
you never see.

What happens when you open the app.

A mobile "ad auction" is exactly what it sounds like. Every blank ad slot in a free app is sold in real time to the buyer willing to pay the most. The auction finishes in a few hundred milliseconds. To bid intelligently, each ad company wants signals about the device and the user, and the app sends those signals along with the request, where every bidder sees them whether they win or lose. AppLovin runs one of the largest such auction networks on mobile, under the brand name MAX.

Concretely: you open a free game. Before the first frame draws, the phone sends a tiny encrypted request to a server called ms4.applovin.com. That request asks AppLovin to run the auction for the slot on your screen. AppLovin doesn't run it alone. The documented behavior is that AppLovin passes parts of the request along to roughly seventeen other ad companies, each of which gets a chance to bid. Whoever bids the most wins the right to show you one banner, one interstitial, or one rewarded video. A few hundred milliseconds later, an ad appears.

Partner list per Buchodi's analysis. The hand-off from AppLovin to each partner happens inside AppLovin's servers, so we can confirm the shape of the auction message from our measurements but we don't independently confirm which app's data reaches which partner.

The auction message is encrypted, so in principle nobody outside AppLovin and its partner graph can read what each app actually shipped about the device or the user. That's the part that just changed.

What the researcher figured out.

In May 2026, a security researcher writing under the name Buchodi published an analysis showing that AppLovin's encryption keys are derived inside the SDK from a string the app itself ships in plaintext: a value called the "SDK key" that sits in Info.plist on iOS and AndroidManifest.xml on Android. Anyone who downloads the app can read those bundles, rebuild the keys, and decrypt the request bodies. Inside, the researcher found device identifiers, app metadata, consent signals, the SDK version, the user's locale and timezone, and other device-fingerprinting fields.

The most quietly important finding in Buchodi's write-up is what happens when a user opts out of App Tracking Transparency (ATT) on iOS. Apple's opt-out zeros out the advertising identifier and the per-vendor identifier (Apple's idfv) inside the auction body. Those are exactly the two fields Apple designed the prompt around. Every other signal in the body is still populated and still sent: the device model and OS build, the app build, the language and region, screen dimensions, network type, the consent strings, the SDK configuration. Enough to fingerprint a device across apps even without the IDFA, and enough to ship to each of the seventeen demand-partner companies in the fan-out.

We're not republishing the research. The reverse-engineering belongs to Buchodi and it's on their blog. We wanted to know something different: how many real, shipping mobile apps emit this kind of message?

What an auction message looks like.

Every request shares the same shape. Three short metadata fields, followed by an encrypted body, all colon-separated:

We can see that shape. We don't decrypt the contents on our test devices yet. That requires the app's SDK key, which we did not use in this measurement just yet. Our claim is thus: if a mobile app emits a request that matches this structure, that's a strong signal it's using the version of the AppLovin protocol the researcher just unwrapped.

Buchodi did decrypt it, and reported what's inside. The fields below come from their write-up, not from our measurements. The point of listing them is to show that the decrypted body is not abstract: it's a specific, surprisingly long fingerprint that goes out on every auction.

Two things to notice about this list. First, even after Apple's tracking prompt zeroes the idfa and the api_did, every other field still goes out, and the combination is more than enough to fingerprint a device across apps. Second, the bt_ms_2 field, which records the device's boot time in milliseconds, survives a reinstall, an app uninstall, and an Apple-ID switch. It only resets when the user reboots their phone.

What the data adds up to.

None of those fields looks dangerous on its own. Phone model is one of a small set of values. iOS patch version is one of a few dozen. Screen dimensions, one of a few dozen. But combine model, OS, screen, timezone, locale, carrier, the installed-keyboard list, and bt_ms_2 (the boot time in milliseconds), and the result collapses to a single device, every time. That's device fingerprinting. It does not need the idfa to work.

Once a fingerprint can recognize the same device across two apps, the rest of the ad-tech stack follows. Buchodi documented the protocol; what an ad network can build from the decrypted output is industry-standard practice. A short list of what becomes possible:

• Cross-app identity stitching. The same fingerprint appearing in two different apps identifies the same device, even when both apps had ATT denied.
• Lookalike audience expansion. Advertisers feed fingerprints of known converters into a model and target devices that look similar across the network's inventory.
• Behavioral correlation. The timestamps and contexts of auction requests across apps reconstruct a coarse app-usage diary for the device.
• Re-identification. Fingerprint plus IP, carrier, locale, and timezone can be joined to other datasets (hashed emails from another partner, for instance) to bridge to a real-world identity.

How we counted.

NowSecure runs a continuous testing platform that pulls Android and iOS apps from the stores and exercises them, employing both static checks and dynamic analysis on real devices. For this post we asked one question of our May 2026 snapshot: how many apps sent at least one network request whose URL pattern matches the auction message above?

This is a structural test, not a decryption and enables us to match the wire shape (version, forty-character ID, fifty-four-character SDK suffix) without reading any bodies.

The narrow rung, 2,732 apps with captured matching requests, is the load-bearing number. Treat the wider rungs as context, not headline material.

How widely those apps reach real phones.

2,732 is a count of apps, not users. The right next question is: how many phones do these apps actually live on? We can't see that directly, but the Play Store publishes minimum-install ranges for every Android app, and the App Store publishes user rating counts for iOS. Those are different yardsticks, so we report them separately.

On iOS, where the Store doesn't publish a download count, we use the number of user ratings as a rough proxy for active reach. It's a different signal: apps with more users tend to get more ratings, but the relationship isn't linear, so don't compare it directly with Android downloads.

Five honest ways to talk about reach.

We publish the headline next to four independent reach numbers. A skeptical reader who throws out any one of them can still verify the others.

It isn't just casino games.

Most of these 2,732 apps are games. That's where mobile ad mediation has historically lived. But not all of them. The list also includes apps in personalization, books and reference, music players, communication tools, dating, health, and photography. Those are the privacy-relevant cases: places where a reader probably doesn't expect a sealed ad-auction request to be flying off the device.

On iOS the picture is similar. Most apps are games, but the list also includes books, utilities, photo and video, social, health, and lifestyle. An iOS app can carry more than one App Store sub-genre, so these bars overlap.

When "Ask App Not to Track" doesn't stop the request.

On every iPhone, iOS shows a prompt called App Tracking Transparency (ATT) before an app is allowed to use the device's advertising identifier to track you across other apps. You've seen it. The app asks, and you tap "Ask App Not to Track" or "Allow". Most people read that prompt as a yes-or-no for whether the app gets to send tracking signals at all.

Buchodi's research is more specific. When a user opts out of ATT, the auction request still goes out. The fields that get blanked are the two identifiers Apple's own framework controls: the cross-app advertising identifier (the idfa) and the per-vendor identifier (the idfv). Every other field in the body keeps its real value. Device model, OS build, app build, language and region, screen dimensions, network type, consent strings, the SDK configuration. Those are the ingredients of a device fingerprint, and they continue flowing to each of the seventeen partner companies in the fan-out.

Until Buchodi published the cipher break, that nuance was invisible to anyone outside the SDK vendor. Now any researcher with the SDK key and a captured request can read it. The iOS share of the apps we counted (1,631 apps) is exactly the population this applies to.

So what does this mean?

Two narrow conclusions, and one broader one.

The broader conclusion matters more. The publishers emitting this traffic did not design the protocol. They embedded a popular mediation SDK and trusted the vendor's privacy and security boundary. Accountability belongs upstream, with the SDK vendor and the ad-mediation graph it feeds, not with the publishers who shipped on its terms.

For Apple, the uncomfortable question is narrower than does ATT work? ATT itself still zeroes the identifiers it controls. The issue is what surrounds them: a rich device-fingerprinting payload that stays populated in the auction request, regardless of the user's tracking choice. Once the cipher is understood, that payload becomes externally auditable.

For Google, the question is scale and SDK governance. The Android side of the confirmed group includes 1,101 apps and a Play Store minimum-install floor of roughly 12.9 billion downloads. If a bundled ad SDK can ship client-side secrets and privacy-relevant auction telemetry at that scale, Play policy, Data Safety labels, the Advertising ID opt-out, and the Privacy Sandbox transition all have to account for what third-party mediation code actually sends.

Notes on the count.

For readers who want to push on the numbers. Most of this is the kind of thing security teams ask before they trust a chart.