What Your App Signature Doesn't Tell You

Earlier today I wrote about finding malicious JavaScript injected through PCGamer's ad network. The script came from a domain that was already on blocklists, but it was still being served through a legitimate site's ad pipeline because nobody in that chain was verifying that what got delivered matched what was intended.

Today, Google announced something that addresses the same problem at a much larger scale. They are expanding Binary Transparency across the entire Android ecosystem, and it is worth understanding why it matters.

The problem with signatures

When your phone installs an app, it checks the digital signature. If the signature matches, the app is considered authentic. This has been the model for decades: if the signature verifies, the software is legitimate.

But a signature only tells you who signed something. It does not tell you that this particular binary was the one the developer intended to release. A stolen signing key, an insider attack, or a simple build mistake could produce a binary that passes signature verification but was never supposed to reach users.

Google puts it cleanly: "Digital signatures are a certificate of origin, but binary transparency is a certificate of intent."

What Binary Transparency actually does

Google is publishing every production Google app for Android (released after May 1, 2026) in a public, append-only ledger. This is the same technology behind certificate transparency, which made the HTTPS ecosystem auditable.

The rule is simple: if a Google-signed app is not on this ledger, Google did not intend to release it. Full stop.

This means:

• No silent replacements. If someone swaps a binary on a server, even with a valid Google signature, it will not appear on the ledger. Anyone can check.
• No insider attacks. An employee with access to signing keys cannot push a one-off build without creating a public record.
• No "test build in production." Development builds that accidentally get signed and shipped would be immediately detectable because they would not be on the ledger.

This covers Google Play Services, standalone Google apps, and Mainline modules (the parts of Android that update independently of full OS updates). Combined with the existing Pixel System Image Transparency from 2023, Pixel users can now verify that both their system image and all Google apps are production software.

Why this matters beyond Android

The ad network malware I found today is a perfect case study in what happens without transparency. PCGamer's ad pipeline has over 50 third-party domains involved. At no point in that chain is anyone verifying that the JavaScript being served is what the original advertiser intended. A malicious script slipped through because the only "verification" was that it came from a domain in the ad network.

Google's approach is different. Instead of trusting the pipeline, they make the output verifiable. Anyone, anywhere, can check whether the binary on their device matches what is in the public ledger. You do not have to trust Google. You can verify.

This is the model the entire software industry should be moving toward. Not just for apps, but for firmware, for ad network scripts, for any code that runs on your device. Every binary should have a corresponding entry in a public, append-only ledger that proves it was intended for release.

What you can do right now

If you are on Android, Google has published verification tools in their Android Binary Transparency repository. You can check whether the Google apps on your device match the production ledger entries.[1]

If you are building software, consider how your users would detect a build that you never intended to ship. If the answer is "they cannot," you have a transparency gap.

And if you are reading this on a website with 50 third-party script domains, maybe install an ad blocker. The transparency revolution has not reached the ad networks yet.