How Witness works

The mechanics, in enough detail to evaluate rather than trust.

The design constraint

Ordinary camera apps write one file and finish it when you press stop. If the recording is interrupted, whether the phone is taken, smashed, or the battery dies, that file is often unfinalised and unplayable, and in any case it is still sitting on the device that was taken.

Witness inverts this. The recording is treated as a stream to be evacuated continuously, and every design decision follows from that.

1. Recording in chunks

Video is written in segments of roughly 15 seconds. Each segment is finalised as a complete, independently playable file the moment it ends, and the next one begins immediately.

Fifteen seconds is a deliberate trade. Shorter chunks mean less footage sits in the gap between "captured" and "safely uploaded," which is the window where evidence can be lost. Longer chunks would upload more efficiently but widen that window. Fifteen seconds keeps the exposure small while remaining practical on cellular.

2. Hashing before anything moves

As soon as a chunk is finalised, Witness computes its SHA-256 hash, a 64-character fingerprint that changes completely if even one byte of the file changes.

The hash is computed on the device, before the file is uploaded anywhere. That ordering matters: it means the fingerprint describes the footage as it came off the camera, not as it arrived somewhere else.

3. Uploading during the recording

Each chunk uploads as soon as it exists, over cellular or Wi-Fi, using a background transfer session so uploads continue even if the app is suspended or the phone is locked.

Three behaviours matter under stress:

• Nothing is deleted locally until receipt is confirmed. A chunk stays on the device until the storage provider acknowledges it. A failed upload is retried with exponential backoff, and the queue flushes the moment connectivity returns.
• Uploads are idempotent. A retry after a partial failure lands on the same destination file rather than creating duplicates.
• Degraded networks get a stand-in. If the queue is visibly falling behind, with several chunks outstanding or repeated failures, Witness encodes a small low-resolution copy of each new chunk and sends that first, so something arrives during the event. The full-quality file follows and replaces it once the network allows. On a healthy connection this never happens and no extra copy is made.

4. The session manifest

Alongside the footage, Witness maintains a manifest for each recording session: a JSON document listing every chunk, its SHA-256 hash, its capture start and end times in UTC, and its GPS coordinates with accuracy.

The manifest is rewritten and re-uploaded as the recording proceeds, overwriting the same file. This means custody records exist in your storage during the encounter, not only if the session is ended normally. If the phone is seized mid-recording, the manifest describing everything captured so far is already safe.

5. Trusted time-stamping

A timestamp written by your own phone proves little; a device's clock can be changed. So when a session finishes, Witness takes a SHA-256 hash of the completed manifest and submits it to an independent RFC 3161 time-stamp authority, which returns a cryptographically signed token asserting that this exact hash was presented at that exact moment.

The result is a claim that does not depend on trusting the person who made the recording: the footage hashes to the manifest, the manifest hashes to the value in the token, and the token is signed by a third party who has no stake in the matter. Together they establish that the footage existed in precisely this form at that time and has not been modified since.

6. Consolidation

Once every chunk of a session is confirmed uploaded, Witness merges them into a single continuous video per camera, uploads that, and then removes the small chunks, leaving one clean file per camera rather than a folder of fragments. The manifest retains every original per-chunk hash, so the fragmented record remains verifiable after the fragments themselves are gone.

This only ever runs after the individual chunks are safely stored, so nothing is at risk while it happens.

Where footage goes

Witness has no server. Nothing passes through infrastructure belonging to the developer, which is also why the developer cannot produce your footage if asked. There is no copy to produce.

What survives what

Verifying it later

Everything above is worth nothing if a court, editor or opposing party cannot check it independently. The verification steps travel inside every manifest, and are written out in full here: how to verify Witness footage →