Client-side scanning examines content on a user's device, where it may already be readable before sending or after receiving. It can therefore create a disclosure path outside the encrypted delivery channel. Comparing an APK checksum does not prove that an app contains no scanning code. It answers a narrower question: whether the selected bytes match a particular digest.
Keeping these claims separate makes both encryption and software verification more useful.
Why scanning on a device changes the privacy boundary
An app must handle plaintext to show a message or prepare a photo for sending. A scanning feature can operate at that point, even if the subsequent network message is end-to-end encrypted. What leaves the device depends on the scanner's design: it might report a match, upload selected content or send other derived information.
The research paper Bugs in our Pockets examines risks including abuse, false positives and additional attack surface. These are reasons to inspect a proposed scanning system's data flows and governance. They do not establish that every on-device feature is surveillance, or that a particular law has imposed a universal scanning requirement.
A local feature under the user's control is not automatically equivalent to mandatory reporting. Ask who chooses the analysis, what triggers it, who can update its rules, and what data can leave the device.
Four different forms of software evidence
| Check | What it can establish | What it cannot establish by itself |
|---|---|---|
| SHA-256 checksum | The file matches a trusted reference digest | That the reference program is safe or matches source code |
| APK signature verification | The package signature verifies and identifies a signing certificate | That the signer is trustworthy or the code has no unwanted behavior |
| Reproducible build | Specified source and build inputs can produce the expected artifacts | That the source is free of vulnerabilities or harmful logic |
| Independent review and testing | Findings about a defined version and scope | A permanent guarantee covering every future update |
Android's apksigner documentation explains package verification and certificate reporting. The Reproducible Builds definition explains why source, build environment and instructions all matter when reproducing an artifact.
A source archive and a checksum printed next to it are not, alone, a reproducible-build result. Likewise, a valid signature on a malicious release is still a valid signature.
How to check a download without overreading the result
First identify the intended release and obtain its APK and expected digest from a trustworthy distribution path. Calculate the digest locally. If it differs, do not install the file while the discrepancy is unexplained: a different release, incomplete download or tampering can all produce a mismatch.
If it matches, record the release and result. You have established byte equality against that reference, not the absence of client-side scanning. If the same attacker can replace the download and the displayed checksum, the comparison may still pass. Independent references, signing-key continuity and release transparency help address different parts of that trust problem.
For a source-to-binary claim, look for documented build instructions and independently reproduced results for the actual release. Do not infer that property from the words “open source.”
Updates remain important
Software distribution can be attacked, but avoiding security updates indefinitely is not a sound general defense. Updates also repair exploitable vulnerabilities. Use a trusted update channel, review meaningful security notices and verify release evidence where your risk warrants it. An old version with a known flaw is not safer merely because its checksum once matched.
What Livara's Proof Lab establishes
Livara's Proof Lab offers a local APK-digest comparison and browser cryptographic demonstrations. The page states that it does not run the complete LVR1/LGS1 ratchets and does not constitute a protocol audit. Its threat model also explains the limitation when an attacker can replace both a file and its expected digest.
Those checks are useful within their scope. They do not prove that an installed phone is free of malware, that Livara has independently reproducible releases, or that its application cannot contain undisclosed behavior. Read the security documentation separately for the claimed message-protection boundaries.
The right question is not whether one badge says “verified.” It is which claim was tested, against which trusted reference, for which exact release.
