Almost every app you run updates itself automatically. That update arrives signed, and your device checks the signature before installing. Signature verification answers one question well: did this build come from the key I expect? It says nothing about a second, harder question: is this the same build everyone else received, or was a different one crafted just for me?
The targeted-update problem
A signing key is a point of leverage. A vendor can be compromised, subpoenaed, coerced, or simply have an insider. Any of those can produce a validly signed build that carries a backdoor. Because it is signed with the real key, every device accepts it. If that malicious build is delivered to one journalist, one dissident, one company, and never to anyone else, ordinary signature checks will never notice. The victim's app sees a correct signature and installs. The attack is invisible precisely because it is narrow.
This is the same reasoning that produced Certificate Transparency for the web. A trusted authority holding a private key is a single point that can be turned against a specific target. The defense is not to make the key harder to misuse, but to make any misuse publicly visible after the fact.
The append-only log, borrowed from CT
Binary transparency reuses the data structure that makes CT work: a Merkle tree maintained as an append-only log. Each new entry, here the cryptographic hash of a released build, becomes a leaf. The tree produces two kinds of compact proofs that a client can verify without downloading the whole log:
- An inclusion proof shows that a specific build hash is present in the log, using a short path of hashes up to a signed root.
- A consistency proof shows that a newer version of the log still contains everything the older version did, so the operator cannot quietly rewrite or delete past entries.
Together these give a public, tamper-evident record. If the log ever forks, presenting one history to one observer and a different history to another, independent monitors comparing signed roots will catch the split. The same monitor-and-gossip idea underpins key transparency for messaging identity keys.
What binary transparency adds on top
The mechanism is CT's; the policy is what makes it useful for software. A binary transparency system typically does three things:
- Log every release. The vendor publishes the hash of each build to the append-only log before or as it ships.
- Make clients check. An updater refuses to install a build unless it can obtain an inclusion proof that the build's hash is in the public log. A backdoored build made for one target would have to be logged publicly to install, which defeats the point of it being targeted.
- Invite outside eyes. Mirrors, researchers, and rival vendors can pull the log and diff it against what they observe in the wild. A build that exists on a victim's device but never appears in the log, or a log entry that does not match the source it claims to come from, becomes a signal someone can act on.
A logged hash proves a specific binary shipped. It does not prove that binary was built from the source code the vendor published. Reproducible builds close that gap: when anyone can rebuild the source and get a bit-identical binary, the log entry becomes a link between shipped software and auditable source. The two techniques are far stronger together than either is alone.
Where it runs today
The idea has moved from research into a handful of production systems, though it is far from universal:
- The Go checksum database (sum.golang.org) is a transparency log of the hashes of Go module versions. When you build Go code, the toolchain checks that the modules it downloads match the hashes recorded in the log, so a tampered dependency version is detectable rather than silent.
- Sigstore's Rekor is a public transparency log for software signatures and attestations, widely used to record how open-source artifacts were signed and built.
- Browser and OS vendors have prototyped binary transparency for their own update channels, applying the CT model to the code they push to millions of devices.
The real limit is enforcement. A log only helps if clients actually require inclusion proofs and if someone is watching the log for anomalies. A record nobody audits is just a database. The strongest deployments pair mandatory client-side checking with active monitoring, so a bad entry gets both blocked at install time and noticed by a human.
| Question | Answered by signatures | Answered by binary transparency |
|---|---|---|
| Did this come from the right key? | Yes | Assumes it |
| Is everyone getting the same build? | No | Detectable |
| Was a past release quietly altered? | No | Consistency proofs catch it |
| Does the binary match its source? | No | Only with reproducible builds |
Why it matters for private software
For any tool whose users may face a capable adversary, the update channel is one of the most valuable things to attack. It reaches the device with the highest privilege, and it does so routinely. A messenger or email client can encrypt everything perfectly and still be undone by one poisoned update. Binary transparency does not prevent that update from being signed. It changes the calculation for whoever would ship it, because a targeted build now risks leaving a public trace.
This is the same reasoning behind Haven's move toward open, reproducible builds: the security claim of a private communication tool should not rest on trusting that the vendor is honest today and stays honest, but on artifacts an outsider can check. Publishing source, making builds reproducible, and logging what ships are three parts of one goal, which is to let people verify rather than trust. Binary transparency is the part that watches the door the update comes through.