Verifying Witness footage
For lawyers, newsrooms, investigators and courts receiving a recording.
You do not need the app, the developer, or any cooperation from whoever filmed it. Everything needed to check a Witness recording travels with the footage, and the verification uses standard OpenSSL rather than anything proprietary.
What you should have received
A Witness session folder contains three kinds of file:
- The video. Either the individual
.mp4chunks, or a single consolidatedrecording_rear.mp4/recording_front.mp4once the session was merged. - The manifest.
manifest_<session-id>.json, listing every chunk with its SHA-256 hash, capture times in UTC, and GPS coordinates. - The time-stamp token.
timestamp_<session-id>.tsr, a signed RFC 3161 response from an independent authority.
If the time-stamp file is missing, the authority was unreachable when the recording ended. That is a gap in corroboration, not a sign of tampering. The hashes remain checkable.
Step 1. Do the videos match the manifest?
Compute the SHA-256 of a video file:
shasum -a 256 recording_rear.mp4 # macOS / Linux
certutil -hashfile recording_rear.mp4 SHA256 # Windows
Open the manifest and find the corresponding entry. Every chunk appears with a sha256 field, and consolidated videos appear under mergedVideos. The values must match exactly.
A mismatch means the file is not byte-for-byte what the phone recorded. Note that any re-encoding will cause this, including the re-compression applied automatically by most messaging apps and social platforms. If footage reached you through WhatsApp, Signal, email or a social upload, expect the hash to differ, and ask for the original file.
Step 2. Is the manifest itself authentic and dated?
This is the step that does not rely on trusting the person who filmed it. The time-stamp token was issued by a third party who signed a hash of the manifest at a moment they attest to.
openssl ts -verify \
-data manifest_<session-id>.json \
-in timestamp_<session-id>.tsr \
-CAfile <authority-ca-cert>.pem
A successful run prints Verification: OK. The manifest names the authority it used in its timestampAuthority field; the CA certificate comes from that authority's website.
A failure here is not automatically evidence of tampering. The most common cause by far is a missing or wrong CA certificate, which is a local configuration problem. Read the token's contents (step 3) before drawing any conclusion.
Step 3. Read what the authority actually attested
To inspect the token directly, without CA validation:
openssl ts -reply -in timestamp_<session-id>.tsr -text
This prints the status, the timestamp, and the message digest the authority signed. Confirm that digest equals the SHA-256 of the manifest file:
shasum -a 256 manifest_<session-id>.json
If the two match, the authority signed this manifest, unmodified, at the time shown.
What the chain establishes
- Each video file hashes to a value listed in the manifest, so the footage is exactly what was recorded.
- The manifest hashes to the digest inside the time-stamp token, so the list of hashes has not been edited.
- The token is signed by an independent authority at a specific time, so that manifest, and therefore that footage, existed in this form at that moment.
Editing the video breaks step 1. Editing the manifest to match the edited video breaks step 2. Reproducing the token requires the authority's private key. The three checks together are what makes the record hard to fake, and each one is independently checkable by you.
What it does not establish
Being precise about this matters if the material is going to be relied on.
- It proves the footage existed at a time and has not changed since. It does not prove what the footage depicts, nor that it was recorded when it appears to have been, only that it cannot postdate the timestamp.
- Locations come from the device's GPS and inherit its accuracy, which is recorded per chunk in the manifest.
- Capture times come from the device clock and are corroborated, not replaced, by the time-stamp token.
- Absence of a manifest or token means the material is unverified by these means, not that it is false.
The instructions shipped with the footage
Every manifest carries its own verification note, so the method travels with the evidence even if this page does not:
This manifest is counter-signed by an independent RFC 3161 time-stamp authority, proving it existed unmodified before the time in the accompanying .tsr file. Because every chunk's SHA-256 is listed above, that proof extends to the footage itself. To verify:
openssl ts -verify -data <this file> -in <timestampFileName> -CAfile <authority CA cert>. Any edit to this manifest, or to any file whose hash it lists, breaks the check.
Questions about a specific recording
If you are examining Witness footage professionally and something does not check out, get in touch: olmaster13@gmail.com. Note that the developer holds no copy of any recording and cannot retrieve, confirm or produce footage. The app has no server. Assistance is limited to explaining the format and the verification process.