TrustCam: capture-time provenance for photos and video with zero infrastructure
Status: minimum viable prototype
This is a feasibility study, not a product. Its purpose is to show that the architecture below holds together end to end on consumer hardware and real platforms. It has been tested on a single device model, results are single-run measurements, the Content Credentials signer uses development certificates, the "verified originals" registry is a static file, and no independent security audit has been performed.
Abstract
Detecting synthetic media after the fact is an arms race with no stable end state. The complementary approach is to make authentic captures provable at the moment they are taken. Existing provenance schemes (C2PA, in-camera signing) attach a signed manifest to the file, but social platforms recompress uploads and strip that metadata — exactly where media circulates. TrustCam combines two layers: a signature made by a hardware-backed key inside the phone, appended to the file, and an invisible watermark in the pixels carrying a random capture id. An exact copy is verified cryptographically; a re-encoded copy can still be traced back to its verified original for side-by-side comparison. The system requires no accounts and no servers: the proof travels inside the file and verification runs entirely in the browser.
Research question
Can a commodity Android phone, with no backend, produce photos and videos whose origin remains checkable by any third party — both for the exact file and for copies that have passed through WhatsApp, Telegram, Instagram and YouTube?
The prototype answers this for a defined set of channels and documents where the answer is no.
Method
- Identity. Each capture gets a random 128-bit id. The signing key is generated in the phone's secure hardware and is non-exportable; its Android Key Attestation chain is included in every proof.
- Watermark. The id is embedded into the pixels on the device with Meta's VideoSeal model. Photos carry all 128 bits protected by BCH(255,131); video, a much noisier channel, carries a 24-bit mark id in an 8× repetition code, bound to the capture id by the signed proof.
- Seal. The final file's SHA-256 is signed and appended as
a trailer (a valid MP4
freebox; ignored after a JPEG's EOI). When online, an RFC 3161 timestamp is added. Videos additionally sign each GOP independently, so a losslessly trimmed clip keeps verifiable segments. - Verify. If the trailer is present, the browser checks the signature and the attestation chain up to Google's pinned roots. If a platform stripped it, the browser runs the watermark detector, recovers the id, and shows the verified original next to the copy.
The two layers cover each other's failure mode:
Full specification in the architecture document.
Results
Captures from a Motorola moto g75 (TEE-backed key), shared through each platform once and verified with the published verifier. Each row is a single trial; every file is downloadable and can be re-verified.
| Channel | Transformation | Outcome |
|---|---|---|
| Photo → WhatsApp | 3072×4096 → 1536×2048, 8× smaller | id exact (BCH: 16/18 bits corrected) |
| Photo → Instagram | downscaled 2.1×, HEIC | id exact (BCH: 18/18, at limit) |
| Photo → Telegram (photo mode) | 960×1280, heavy recompression | not recovered |
| Photo → Instagram 1:1 crop | 25% of frame removed | not recovered |
| Video → WhatsApp | 478×850 re-encode | mark recovered, 80% agreement |
| Video → Telegram | 720×1280 re-encode | mark recovered, 85% |
| Video → Instagram | 720×1280 re-encode | mark recovered, 87% |
| Video → YouTube Shorts | re-encoded to AV1 | mark recovered, 82% |
| Video → Instagram, edited | caption + sticker overlay | mark recovered, 82%; edits visible in comparison |
| Video, lossless trim | -c copy, trailer lost | 4/5 GOP signatures valid; mark 97% |
Agreement = fraction of decoded watermark bits matching the expected repetition pattern. Lab robustness sweeps, on-device cost and methodology are in the research document.
Claims and limitations
- What a valid signature shows: this exact file was produced by a key held in this device's secure hardware, at the claimed time (third-party timestamped when online), and has not changed since.
- What a watermark match shows: only that the copy claims a given origin. The watermark model is open, so marks are forgeable; the match is evidence for human comparison, never authentication.
- What it cannot show: that the depicted scene is real. Filming a screen yields a genuinely signed recording of fake content (the analog hole). Pre-signing injection (virtual cameras) is mitigated by attestation, not eliminated.
- Scope of evidence: one device model, single trials per channel, platforms' behaviour at the time of testing. Video embedding runs at about 1 s per keyframe on a mid-range CPU; real-time is an open engineering task.
Context
Hardware-signed capture is already shipping (Leica, Sony, Google Pixel via C2PA), currently for photos and with metadata that does not survive platform upload. The EU AI Act's transparency obligations (Art. 50) apply from August 2026, and California AB 853 requires capture-device makers to embed provenance by default from January 2028. This prototype explores the gap those systems leave open: video, and copies after redistribution. Related work is reviewed in the research document.
Reproducing the results
- Verify any file in the browser: verifier
(nothing is uploaded), or from the command line with
verify.mjs, which runs the same modules. - Original captures and platform copies, including failures: demos.
- Experiment scripts, codecs and model exports:
spikes/; experiment reports:docs/. - Capture your own: install the Android APK (Android, sideloaded, no account).
Citation
@misc{galante2026trustcam,
author = {Galante, Gregorio},
title = {TrustCam: capture-time provenance for photos and video
with zero infrastructure},
year = {2026},
note = {Research prototype},
url = {https://trustcam.gregoriogalante.com}
}