From camera to checkable media

When you see a photo or video online, content provenance is the record of what happened to it before it reached you. The industry open standard is C2PA (the Coalition for Content Provenance and Authenticity), which defines how to embed signed provenance (often shown to users as Content Credentials) in media files. That foundation is a major step forward. On top of it, fightfake.ai is working on two additions: hardware-rooted signing at capture, and mathematical proofs of what was edited.

At capture, the device should sign inside protected hardware. After that, footage is almost always edited (cut, grade, compress, redact). C2PA lets the editor list those changes and re-sign. A signature alone is an attestation: the party holding the key could misreport a colour grade while swapping a face, and the check would still pass. Secure capture keys and edit proofs close that gap.

fightfake.ai does not replace C2PA. It uses the same C2PA manifests that some cameras and editors already embed in photos and videos (inside the file, as a signed Content Credentials / provenance record). Standard C2PA fields stay in place, for example declared actions (c2pa.actions), a hard binding over the file bytes (c2pa.hash.bmff), and the digital signatures that protect the manifest. Existing C2PA tools can still read and validate those parts.

fightfake.ai extends that manifest with custom assertions under org.zkedit.*:

• org.zkedit.capture: a fingerprint of the original pixels (h1), signed at capture. That is what later proofs anchor to.
• org.zkedit.edit_proof: which allowed edit was applied, fingerprints of the original and edited pixels (h1 and h2), and a reference to a zero-knowledge proof file.

Example: a newsroom publishes the edited video with its C2PA manifest plus proof.bin; they can keep the original capture private. A fightfake-aware checker confirms the C2PA chain and that the proof matches: only the declared edit, nothing else. A standard C2PA viewer still sees a valid Content Credentials package; it simply does not evaluate the ZK proof until fightfake-aware tooling is present.