How verification works

1. Why "trust us less" is the design goal

Most evidence systems ask you to trust the vendor. The recording is safe because the company says its storage is secure, its staff are honest, and its logs are complete. That is an assurance, not a proof — and in an adversarial setting, where the person challenging the footage is often the person it is being used against, an assurance from the other side's supplier is worth very little.

Duress Evidence is built the other way around. The goal is that the value of our word approaches zero: the properties that matter — that a recording has not been altered since it was captured, and that its place in the record cannot be quietly rewritten — are things you can check yourself, without an account, without our servers, and without our permission. This page is the map of how you do that.

2. What a disclosure bundle is

When a recording is disclosed — to a court, a lawyer, an oversight body — it travels as a disclosure bundle: a single file that carries the recording's manifest (the list of media segments and the SHA-256 hash of each), the signatures over that manifest, the transparency-log inclusion proof, the signed tree head the proof resolves against, and the public keys involved. Optionally the media segments themselves travel alongside it.

Everything the verifier needs to reach a verdict is inside the bundle. That is deliberate: a check that needs to phone home to us is a check we can watch, shape, or fail on purpose. The bundle is self-contained so the verification can be too.

3. The public transparency log

Every record is committed to an append-only transparency log — the same class of structure that underpins Certificate Transparency for the web's TLS certificates (RFC 6962), and the newer RFC 9162 that supersedes it. Two properties make it useful:

• Append-only. Entries can be added but not edited or removed. The log periodically publishes a signed tree head: a signature over the size of the log and the Merkle root of everything in it at that moment.
• Inclusion proofs. For any entry, the log can produce a short cryptographic proof that it sits under a given signed tree head. A bundle carries that proof, so you can confirm the manifest was logged — under a tree head the log signed — rather than presented only to you.

The effect is that the history of a record is committed to copies we do not get to rewrite after the fact. Change one logged entry and every inclusion proof issued after it stops verifying, visibly.

4. The offline verifier

The verifier is a single web page that runs entirely in your browser. Drag a disclosure bundle onto it — and, if you want the byte-level check too, the media segment files — and it works through the record step by step:

1. Segment bytes. Each media segment is hashed and compared to the hash the manifest recorded for it at capture. (Runs only if you supply the media files.)
2. Merkle root. The segment hashes are combined into an RFC 6962 tree and the root is compared to the one sealed in the manifest, so segments cannot be reordered, dropped or substituted.
3. Signatures. Each signature over the canonical manifest is checked against the bundled public keys, including that the signing key was in service at the time.
4. Log inclusion. An inclusion proof places the manifest in the transparency log under the signed tree head, and the tree head's own signature is checked.

Two things make this more than a convenience. First, it is zero-install and account-free: a regulator or a defence lawyer runs it without asking anyone, which is the difference between a check that gets used and one that does not. Second, it is offline: once the page has loaded it makes no network requests of any kind, so you can save it to a disk, pull the network cable, and it still works. A verification step that reaches back to our servers is one we could interfere with; there are none.

The verifier never rounds up. Every step reports passed, failed, or not run — and where your browser cannot perform a particular signature check, that step is marked "not checkable in this browser" and is never silently counted as a pass.

5. Open canonicalisation

A signature only means something if everyone agrees on exactly which bytes were signed. If the manifest can be serialised two different ways — a space here, keys in a different order there — then "the signature verifies" becomes a matter of whose serialiser you used, and the guarantee dissolves.

So Duress Evidence uses one canonical form: object keys sorted at every level, arrays kept in order, no insignificant whitespace, a defined treatment of every value type. The manifest is hashed and signed in that form, and the verifier reproduces exactly the same form before it checks anything. The rules are not a trade secret — they are simple enough to state in a paragraph and are implemented in the open in the verifier page itself, which you can read in full with your browser's view source. Anyone can re-implement them and get byte-for-byte the same result, which is what makes an independent verifier possible at all.

6. What it proves — and the honest cap

Passing every check earns one specific verdict, and we hold the language to exactly what was established:

STRUCTURE VERIFIED (unwitnessed v1)

That verdict means the record is internally consistent and append-only, and its signatures are valid: the bytes match their hashes, the hashes build the sealed root, the manifest is signed, and it is included under a signed tree head. It is never phrased as a plain "verified", and it is never a Duress-attested seal of approval.

We state this here, on the verifier, and in the verdict itself, for the same reason: a verifier that overclaims is worse than no verifier, because it launders a weaker guarantee into a stronger-sounding one. When witnesses are established, the cap will move and this page will say so.

7. The keys still need an independent source

Unless you obtained them separately, the public keys used for the signature checks arrive inside the bundle itself. That means a bundle can be perfectly internally consistent and still not be from us — internal consistency and provenance are different questions. Before you rely on a signature, cross-check the signing keys against a key list you obtained independently, not one that travelled with the thing it is vouching for. The verifier flags this in its own results rather than glossing over it.

8. What we publish that you can hold us to

"You don't have to trust us" only means something if the pieces are actually open. Our commitment, and what it looks like in practice:

• The verifier is readable. It is a single self-contained page with no external code; its checks and its canonicalisation are in the page source, open to inspection and re-implementation.
• The canonicalisation rules are documented. The exact serialisation a signature is computed over is specified, not left to a particular library.
• The log's signed tree heads are public. The transparency log is append-only and its checkpoints are published, so inclusion can be checked against a head we cannot quietly change.
• The verdict language is fixed to the guarantee. The cap in §6 is enforced in the verifier's own code, not left to a marketing choice.

Where a capability is not built yet — witness cosigning is the live example — we say so on this page and in the product rather than describing the destination as if it had arrived. If you are evaluating us and a claim here is not backed by something you can check, that is a bug in this page; tell us at the address in §10.

9. Is this court-admissible?

Admissibility is a decision a court makes, not a property a vendor can grant — so the honest answer is in two parts. What we can prove is integrity from the point of ingest: that a recording has not changed since it entered the record, that its chain of custody is append-only, and that every access carried a stated reason. What a court decides about admissibility depends on the matter, the jurisdiction, and questions that sit outside our system — how the recording was obtained, relevance, and the rules of evidence that apply.

What we provide is the part that is ours to provide: a verifiable chain of custody and an independent verifier, so that when integrity is questioned, the answer is a check anyone can run rather than an assurance anyone has to accept. We do not, and cannot honestly, promise that any given recording will be admitted.

10. Questions and disclosure requests

For questions about the trust model, a disclosure bundle you have been given, or an evaluation, write to support@duress.com. If a claim on this page is not backed by something you can independently check, we treat that as a defect and want to hear about it.

Related reading: About Duress Evidence, the offline verifier, our Terms and Privacy Policy.