Verifiability
How the opposing party verifies your evidence
Evidence only you can validate is not evidence — it is your assertion. The five independent ways anyone, including your opponent, can verify a bundle.
One question dismantles most «certification» tools: who can check that it is true? If the answer is «the vendor, from its own website», then you do not have evidence — you have a company's assertion, and its strength equals that company's reputation and commercial survival.
The principle that looks like an own goal
A forensic package should be built so that whoever opposes you can examine it to the bottom, with their own tools, without asking you for anything and without trusting whoever produced it.
It looks like a commercial own goal. It is the exact opposite, for an asymmetric reason: if the opposing party can verify everything and finds nothing, they have nothing left to argue. The technical challenge exhausts itself before it starts, and the discussion returns to the merits — exactly where you need it.
If you think you can challenge a LOCUS bundle, good: that is precisely what it is designed for. Trust never concentrates on whoever produced the evidence.
Five independent paths
1. The public verification page
The most immediate route: a short code or the acquisition identifier typed into a browser. It recomputes fingerprints, timestamps and signature in real time. No tools, accessible to anyone — a judge included, from their own computer. It is the only one of the five that needs a connection and goes through our servers, which is precisely why it is not the only one.
2. interactive.html
A file inside the package. Double-click, it opens in any browser with no connection, recomputes the hashes locally using the browser's own cryptographic functions and compares them with the ones signed in the manifest. No data leaves the verifier's computer: there is no upload, so there is no way for us to know anyone is checking.
3. verify.sh and verify.bat
Scripts for macOS/Linux and Windows, also inside the package. The point that matters: they use system tools — shasum, sha256sum, certutil, openssl — not LOCUS code. A verifier can read them: they are plain text, a few dozen lines. They run five numbered steps: content integrity, completeness (no smuggled files), integrity of supporting files, and the two timestamps.
4. Locus Validator
A desktop application for macOS, Windows and Linux. Drop the package in and get a traffic-light report plus a validation PDF. No registration, no telemetry, and it ships the timestamping authorities' certificates: it works on an air-gapped machine. For anyone wanting a readable verdict without the command line.
5. The commands by hand
For anyone unwilling to trust any tool, ours or otherwise. This is the method that removes every doubt about the vendor, because it runs nothing we wrote:
shasum -a 256 -c manifest-sha256.txt
shasum -a 256 -c tagmanifest-sha256.txt
openssl ts -verify -data data/media.jpg -in data/tsa.tsr -CAfile tsa-ca.pem
openssl ts -verify -data tagmanifest-sha256.txt -in tagmanifest-sha256.txt.tsr -CAfile tsa-ca.pemOn Linux the first command becomes sha256sum -c. One practical warning that saves half an hour of confusion: on macOS the system OpenSSL is actually LibreSSL, which does not implement the ts subcommand — you need real OpenSSL, installable via a package manager. It is not a problem with the bundle.
What actually gets checked
The serious objections, and honest answers
«The software could be lying»
A legitimate objection, and the reason method 5 exists. Timestamps are issued by third-party authorities and verified against their public CA; hashes are recomputed with system tools. None of these steps requires running our code. If the software were lying, the manual commands would say so.
«The content is not on your servers — how can I trust it?»
That is backwards: precisely because the media never reaches us, we cannot have altered it. For photos, what goes up to the server is the histogram — not the image. You are the custodian of the evidence, and that has a flip side worth stating: if you lose the bundle, we cannot rebuild it. Keep a backup.
«The date could be forged»
Not the RFC 3161 one: it is signed by an external authority and verifiable against its CA. You can forge a phone clock — which is why the phone clock is not the guarantee, and is recorded separately along with its own drift.
«It is a processed JPEG, not raw sensor data»
True, and it is declared in the signed manifest. No smartphone delivers raw sensor data through the standard pipeline: the image is the output of the device's computational processing. We do not hide it, we write it down.
What verification does not say
An all-green report asserts something precise: this package is intact, and this content existed at that instant. It does not assert that the scene is genuine, nor that the acquisition was lawful or procedurally valid.
These are sharp boundaries, and it is good that they are: a tool promising the rest as well would be less credible, not more. The full walkthrough, with every command, is on the how to validate a bundle page.
Continue with the chain of custody and does a photograph have legal value?