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

Capture CameraX, on device
Watermark VideoSeal, ONNX
Sign ECDSA P-256, TEE/StrongBox
Verify client-side
  1. 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.
  2. 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.
  3. Seal. The final file's SHA-256 is signed and appended as a trailer (a valid MP4 free box; 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.
  4. 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:

Capture signed + watermarked
exact copy (file transfer, download)
Platform re-encodes, strips metadata
Verifier exact → signature re-encoded → watermark

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.

ChannelTransformationOutcome
Photo → WhatsApp3072×4096 → 1536×2048, 8× smallerid exact (BCH: 16/18 bits corrected)
Photo → Instagramdownscaled 2.1×, HEICid exact (BCH: 18/18, at limit)
Photo → Telegram (photo mode)960×1280, heavy recompressionnot recovered
Photo → Instagram 1:1 crop25% of frame removednot recovered
Video → WhatsApp478×850 re-encodemark recovered, 80% agreement
Video → Telegram720×1280 re-encodemark recovered, 85%
Video → Instagram720×1280 re-encodemark recovered, 87%
Video → YouTube Shortsre-encoded to AV1mark recovered, 82%
Video → Instagram, editedcaption + sticker overlaymark recovered, 82%; edits visible in comparison
Video, lossless trim-c copy, trailer lost4/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

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

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}
}