Social Media Provenance Challenge

There’s technology just becoming available that would make it much easier to distinguish fake media posted to social networks from the real thing, There’s work to do, but it’s straightforward stuff and we can get there. Here’s how.

What success looks like · Nadia lives in LA; let’s call this the Nadia Story. She has a reasonably popular social media account with a reputation for posting good pictures of urban life. She’s not terribly political, just a talented street photog. Her handle is “HotShotLA@hotpix.example”.

She’s in Venice Beach the afternoon of Sunday August 9, 2026, when ICE comes through to take down a vendor selling cheap Asian ladies’ wear. She gets a great shot of an enforcer carrying away an armful of pretty dresses while two more have the merchant bent over his countertop in handcuffs. None of the agents are in uniform, all are masked.

She signs into her “HotShotLA” account on hotpix.social and drafts a post saying “ICE raids Venice Beach”. When she uploads the picture, there’s a pop-up asking “Sign this image?” Nadia knows what this means, and selects “Yes”. By midnight her post goes viral.

Anyone who sees Nadia’s post also sees a little “Cr” glyph in the photo’s top right corner. When they mouse over it, a little pop-up says “Posted by @HotSHotLA to hotpix.example at 5:40 PM on August 9th, 2026”.

The “@HotShotLA” part of the message is a link. Anyone who clicks on it is taken to Nadia’s account and gets a flavor for what kind of person she is and the quality of her work. Most people are inclined to believe the photo is real.

Marco is a MAGA. He grabs Nadia’s picture and posts it to his social-media account with the caption “Criminal illegals terrorize New Orleans. Lock ’em up!” He’s not technical and doesn’t bother stripping the metadata. Since the picture is already signed, he doesn’t get the “Sign this picture?” prompt. Anyone who sees his post will see the “Cr” glyph and mousing over it makes it pretty clear that this picture isn’t what he says it is. Several MAGA-averse commenters gleefully point this out. By the time Marco takes the post down, his credibility is damaged.

Maggie, another MAGA, has an account at “TradWifePatriot@maga.example” and is more technical. She strips the picture’s metadata before posting it with a caption along the same lines as Marco’s. When she gets the “Sign this picture?” prompt, she says No, so when people see it, there won’t be a “Cr” glyph. Hostile commenters point this out and accuse her of posting a fake. It is less likely that her post will go viral.

Mahmoud is a another loud-voiced MAGA who follows Maggie. He grabs the stripped picture and, when he posts it, says “Yes” to signing. In his post the image will show up with the “Cr” and credit it to him, with a “posted” date well after Nadia’s initial post. Now, the picture’s credibility will be tied to Mahmoud’s; it will at least be obvious that the source is highly partisan. Also, there’s a chance that someone will notice what Mahmoud did and point out that obviously, he stole Nadia’s picture.

How it’s done · The rest of this piece explains in some detail how the Nadia Story can be supported by technology that already exists, with a few adjustments. If jargon like “PKIX” and “TLS” and “Nginx” are foreign to you, you’re unlikely to enjoy the rest of this piece very much. But if the Nadia Story appeals to you, you might want to share the fact that it’s achievable without too much effort.

I’m not a really deep expert on the specs nor really on PKI, so it’s possible that I’ve got some things wrong. Therefore, this blog piece will be a semi-living document in that I’ll correct any convincingly-reported errors, with the goal that it accurately describes a realistic technical roadmap to the Nadia Story.

By this time I’ve posted enough times about C2PA that I’m going to assume people know what it is and how it works. For my long, thorough explainer, see On C2PA. Or, just check out the Content Credentials Web site.

Tl;dr: C2PA is a bunch of assertions about an image, stored in its metadata, with a digital signature that includes the assertions and the bits of the picture.

This discussion assumes the use of C2PA and also an under-development related specification from the Creator Assertions Working Group (CAWG), called Identity Assertion.

Not all the pieces are quite ready to support the Nadia Story. But for each gap, there’s a clear path forward to closing it.

“Sign this picture?” · C2PA and CAWG specify many assertions you can make about a piece of media, and you could argue that plenty of them would add value to a social-media post. There’s room for endless discussion about this, in which I have zero interest. At the moment, I can’t think about any other problems because I can’t stop thinking about the provenance problem. Let’s address that first.

In that spirit: When a piece of media is uploaded to a social-network service, there are two facts that the server knows, absolutely and unambiguously: Who uploaded it (because they have to be signed in to do so) and when. In the current state of the specification drafts, “Who” is the cawg.social_media property from the draft Identity Assertion spec, section 8.1.2.5.1, and “When” is the c2pa.time-stamp property from the C2PA specification, section 18.17.3.

I think these two pieces of information are basically all you need for a big improvement in social network media provenance, so let’s stick with them.

What key? · Let’s go back to Nadia’s success story. For this to work, it needs to be digitally signed in a way that will convince a tech-savvy human and a PKIX validation library that the signature could only have been applied by the server at hotpix.example.

The C2PA people have been thinking about this. They are working on a Verified News Publishers List, to be maintained and managed by, uh, that’s not clear to me. The idea is that C2PA software would, when validating a digital signature, verify that the PKIX cert is from one of the members of the Publishers List.

This doesn’t feel like it’s going to work for decentralized social media, which has tens of thousands of independent servers run by co-ops, academic departments, municipal governments, or just a gaggle of friends who kick in on Patreon. And anyhow, Fediverse instances don’t want to be “Verified News Publishers”, they’re just online conversation platforms.

Fortunately, there’s already a keypair and PKIX certificate in place on every social-media server, the one it uses to support TLS connections. The one at tbray.org, that’s being used used right now to protect your interaction with this blog, is in /etc/letsencrypt/live/ and is obviously not generally readable.

That cert will contain the public key corresponding to the host’s private key, the cert's ancestry, and the host name. It’s all OpenSSL or any other PKIX library needs to verify that yes, this could only have been signed by hotpix.example. However, there will be objections.

Objection: “hotpix.example is not a Verified News Publisher!” True enough, the C2PA validation libraries are just going to have to learn to accept that kind of cert and if that requires adjustments to the C2PA specs, so be it.

Objection: “That cert was issued for the purpose of encrypting TLS connections, not for some weird photo provenance application. Look at the OID!” OK, but (I don’t want to hurt any feelings here) who cares? The math does what the math does, and it works.

Objection: “I have to be super-careful about protecting my private key and I don’t want to give a copy to the hippies running the social-media server.” These people have a point, but in fact in most cases, social media is all that server’s doing. Having said that, it would be great if there were extensions to Nginx and Apache httpd where you could request that it sign the assertions for you. Neither would be rocket science, although you’d have to be careful about controlling access to that entry point.

OK, so we sign Nadia’s account/time/pixels assertions with our host’s TLS key, and ship it off into the world. What’s next?

How to validate? · Verifying these assertions is going to require a PKI library to pick apart the assertions and do the signature check. We already have c2pa-rs, MIT and Apache-licensed Rust. Rust libraries can be linked into from lots of other programming languages but in the normal course of affairs I’d expect there to be native implementations in those languages. Once again, all these technologies are old as dirt, absolutely no rocket science reuired.

But there is a question: What’s the trust chain for validating the cert? Once again, this is not rocket science: A validating application could grab the Curl project’s CA certificates extracted from Mozilla and refresh it every week or two.

Most modern operating systems have the concept of the “default browser” — it’d be nice if there it offered a way to retrieve its root-of-trust cert list.

What am I missing? · This feels a little too easy, something that could be done in months not years. Perhaps I’m oversimplifying. Having said that, I think the most important thing to get right is the scenarios, what effect we want to achieve, what I’m calling the Nadia Story. What do you think?

---

---