Remove Sora C2PA Content Credentials

OpenAI Sora attaches a C2PA Content Credentials manifest to every video frame and still image it produces. The manifest contains the claim_generator string, signing certificate, and assertions linking the output to your OpenAI account. Once you share a Sora frame on social or in a client deck, that manifest goes with it — anyone with a free C2PA viewer can read it. GhostMeta detects the Sora signature in the JPEG APP11 segment, shows you what's there, then strips it via canvas re-encode. Inside a Sora JPEG, the manifest lives in one or more APP11 segments that reassemble into a single JUMBF superbox: a c2pa claim box, a hard-binding hash assertion bound to the pixel data, and a signature box holding a certificate-chain (COSE) signature. Because the binding is a hash, even a light crop or filter applied later leaves a broken-but-still-present manifest that a viewer flags as tampered rather than absent — which can look worse than an untouched credential. Stock libraries and ad networks that scan uploads on ingest increasingly read this box and either label the asset, push it to manual review, or reject it outright, so a single un-stripped Sora frame can stall an entire batch submission.

FAQ

Does Sora embed identifiable info?

Sora's C2PA manifest carries a claim_generator string, the signing certificate chain, and timestamped assertions. It does not embed your raw OpenAI email by default, but the chain ties the output to OpenAI as the producer.

Will Sora videos still play after stripping?

Yes. The C2PA manifest sits in metadata containers — its removal does not affect the H.264/H.265 stream. For video frames exported as stills, GhostMeta handles the JPEG normally.

Can I still verify the image is real after stripping?

No — that is the point. C2PA is a provenance chain. Once stripped, no third-party tool can prove the image came from Sora. Only strip when you control the publishing context.

Where exactly does Sora store the C2PA data in a JPEG frame?

It sits in the APP11 marker segments, not APP1 (which holds EXIF/XMP). C2PA splits a manifest larger than 64KB across several APP11 segments that a reader concatenates into one JUMBF box, identified by the 'JP' marker and a box-instance number. GhostMeta walks the JPEG segment list, recognises every APP11 fragment as part of the Sora manifest, and drops them all on canvas re-encode so no partial box survives.

If I crop a Sora frame in a normal editor, is the credential gone?

No. A basic crop only changes the pixels; the APP11 manifest is copied through by most editors untouched. Worse, the hard-binding hash no longer matches the new pixels, so a C2PA viewer reports the asset as modified rather than clean. To actually clear it you need to remove the JUMBF box, which is what GhostMeta does by re-encoding from a bare canvas with no metadata carried over.

Does stripping a single exported Sora still also remove its 'soft binding'?

GhostMeta removes everything stored in the file: the APP11/JUMBF manifest, plus any EXIF, XMP or IPTC. What it cannot remove is a soft binding — a fingerprint Sora may compute from the pixels and register server-side — because that is not data inside your file and would survive re-encoding. For metadata-based provenance, though, a re-encoded frame carries no readable C2PA at all.