provenote

limitations

Every limit here is someone else’s finding.

Documented, citable limits of C2PA provenance itself, or of this tool — never something provenote inferred on its own authority. Sources are linked, not paraphrased into a stronger claim than they support.

What this page is not

provenote does not claim to have discovered any of the limits below. It does not name any incumbent product as “broken” — where a real-world failure is cited, it is cited to that vendor’s own public bug tracker. It never assesses whether any particular image is authentic, real, or AI-generated, and it never will — a valid C2PA chain is a claim about bytes and a signer, not a verdict on content.

Provenance is not authenticity

This is the foundational distinction every claim below sits on top of, and it is C2PA’s own coalition saying it, not a critique from outside:

“C2PA provides provenance signals, not proof of authenticity.” — arXiv:2604.24890, “What is C2PA?”, quoting the distinction C2PA’s own documentation draws
“Provenance information alone cannot tell you whether the digital content is true, accurate or factual.” — C2PA Explainer, spec version 2.4. This sentence sits in running prose — there is no dedicated, prominent “Limitations” section in either the spec or the Explainer.

Fixture 2 in the Gallery of Limits makes this concrete: a cryptographically valid signature, cleanly attached to a scene that never happened.

A missing chain is not evidence of anything

A file that never carried C2PA data and a file whose valid manifest was stripped a moment ago are, by design, indistinguishable:

“An image with no Content Credentials is like a box of cereal without any nutrition information, so you don’t know what’s in it or where it came from.” — Content Authenticity Initiative FAQ

The same FAQ concedes stripping is a real, unrecoverable-by-default event: recovery of a stripped manifest depends on “a lookup process using either a watermarked ID or a perceptual content-aware hash” — a best-effort lookup against a separate registry, not a guarantee, and not something this tool (or any client-side reader) can do on its own. Fixture 1 in the Gallery demonstrates this literally: the stripped file and the never-signed file are byte-for-byte identical.

An “Invalid” verdict does not distinguish tampering from tooling age

Two live GitHub issues against the field’s reference verifier document this directly, not hypothetically:

  • contentauth/verify-site#316 — a vendor’s images, re-signed with a newer, fully legitimate version of c2patool, began showing “This file may have been tampered with” purely from an assertion-schema rename (c2pa.actions → c2pa.actions.v2).
  • contentauth/verify-site#336 — the same vendor reports millions of older, honestly-signed images failing with the identical message, traced to assertion.action.ingredientMismatch, again with no tampering involved.

Fixture 3 in the Gallery reproduces the underlying mechanism directly: an ordinary post-signing re-encode by a tool that has never heard of C2PA, and a deliberate single-byte edit, land on the exact same validator output.

Six documented protocol-level findings

arXiv:2604.24890, “Verifying Provenance of Digital Media: Why the C2PA Specifications Fall Short” (Golaszewski, Krawetz, Sherman, et al. — Cyber Defense Lab, UMBC; Hacker Factor; NSA) is the first formal-methods analysis of C2PA’s core protocols. Its six Key Findings, named as the paper names them:

  1. Timestamps can be forged or altered. Nothing in the signed manifest data references the timestamp, so it can be stripped and replaced without invalidating the signature.
  2. Revoked or compromised credentials are still accepted. Conforming validators often skip or mishandle revocation checks — the spec makes strict revocation checking optional and disallows CRLs. A Nikon Z6 III credential revoked around November 2025 still validated as trusted in Adobe’s own Inspect tool six months later.
  3. Different tools produce contradictory results. The same file is labeled valid by one conforming validator and invalid by another.
  4. Parts of files can be modified without detection. C2PA’s byte-range “exclusions” mechanism lets some file regions sit outside the hard-binding hash by design, so they can be edited post-signing with no signature break — demonstrated by altering GPS location data in a Pixel 10 Pro test image without a validator flagging it.
  5. Credentials expire and become unverifiable. Certificates back C2PA signatures and expire on a timescale shorter than standard legal or records-retention windows (the paper cites 22–25 months as typical) — an Arizona Secretary of State pilot image that validated in January 2025 failed validation roughly a year later, with the file itself unchanged.
  6. Certification does not ensure compliance. The C2PA Conformance Program is largely self-attested; no source-code review is required to earn “Conformant” status.
“C2PA should not yet be relied upon for high-stakes uses such as financial disclosures, journalism, or legal evidence.” — arXiv:2604.24890, Executive Summary

These six findings are protocol-specific (timestamp binding, revocation, cross-validator consistency, exclusion ranges, certificate expiry, conformance rigor) and do not cover manifest stripping, re-signing, or capture-time (“analog hole”) attacks — this page cites those to C2PA’s own spec design and CAI’s own FAQ above, not to this paper, so nothing here is attributed to a source that didn’t make the claim.

provenote’s own dependence on the official parser

Every result this tool shows comes from @contentauth/c2pa-web, the official client-side C2PA reader, running unmodified in your browser. provenote does not re-implement cryptographic verification, does not second-guess the library’s validation_state, and cannot detect a bug in that library if one exists — it is a plain-language front end for what the official parser reports, not an independent verifier. If the official library is wrong, provenote is wrong in exactly the same way, honestly labeled or not.

Sources