O4.07.2Provenance persistencedesign

Provenance labels must survive the content's journey

Aliases: content credentials · C2PA · signed provenance

What it is

Provenance labelling is the main engineering route against the failure of perceptual tests: bind content to a cryptographically signed metadata chain — who created it, with which tools, through which edits — and require that chain to survive the entire distribution journey. The representative standard is Content Credentials (C2PA). The hard part is not signing; it is surviving the journey.

Why it happens

The technical form is a digital signature over the content hash and creation metadata: signed at publish, verified by recomputing the hash. The difficulty is that every step of distribution can strip the metadata — screenshots, crops, recompression, platform transcoding — and distributors of fakes will deliberately choose the stripping path. "Persistence" is therefore the responsibility of the whole chain: creation tools write, platforms pass through, downloads retain, and secondary edits append signatures rather than wiping. The semantics of a broken chain are the critical design point: a verifier facing credential-free content must display "no credentials," never silently default to "authentic" — the absence of a label is itself information and must not degrade to a pass. That is also how signing differs from watermarking: a watermark hides in the content and can be adversarially removed; a signature is bound to it, and the act of removing the signature is itself visible (it shows as credential-free). The system is thus "credentials for the honest," not a lie detector — its value rises with coverage.

Where it stops holding

Content credentials are a voluntarily carried passport: unsigned synthetic content and genuine content stripped of credentials both display "no credentials" at the verifier, so the system binds nobody who opts out, and its governance value depends on platform and toolchain coverage. Privacy costs are real: credentials may embed capture-device information that identifies the author — the standard's redaction options and their default settings decide actual exposure. UI burden is real too: verification status beside every item is interface noise — aggregated display on a detail page with strong display reserved for key positions (news, official statements) is the workable compromise.

Applying it

  • Publish side: adopt content credentials — original content and official statements signed by default, with the editing toolchain passing credentials through untouched.
  • Verify side display rules: credentials present, show status with an edit-history summary; credentials absent, show "no source credentials" explicitly — rendering credential-free as neutral or trustworthy is banned.
  • Verification: a journey test — walk signed content through the full pipeline (download, screenshot, platform publish, forward), recording credential survival at each step; every break enters the fix list and gets re-tested.

Related

  • Same group: O4.07.1 Perceived authenticity fails as a test · O4.07.3 Publisher burden of proof
  • Nearby: O4.01.3 Verifiable beats decorative · O4.09.2 Third-party seals depend on verifiable issuers
  • Search terms: content credentials · C2PA · provenance chain

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O4.07.2