One of these is real.

The bar is not proof, it is doubt

This is the part that tends to get missed.

A screenshot does not stop being useful at the moment someone proves it was faked. It stops being useful at the moment someone can credibly suggest it might have been.

That is a much lower bar, and it has just been cleared for everybody. An opponent does not need to demonstrate tampering. They need only establish that tampering was available, trivial and undetectable, and the burden quietly moves to the party relying on the image to prove a negative they cannot prove.

So the question is not whether you were fooled today. It is what you would say in a witness box to someone who asked how you know.

Screenshots are still the default

This matters because the screenshot remains the standard way evidence from the web reaches a case file. Investigators take them. Solicitors bundle them. Claims handlers attach them. HR teams paste them into reports. They are accepted, filed, disclosed and relied on every day.

The assumption underneath that practice is that faking one convincingly is hard. It was never especially hard. It is now trivial, and the tools ship with every browser and sit behind every chat interface.

The practice has not caught up. It will, and when it does, a great deal of otherwise sound evidence is going to become arguable.

You cannot detect your way out of this

The instinct is to look for a detector. Something that examines the image and tells you whether to trust it.

That works, sometimes, for wholly generated images. It cannot work here.

Panel B has no generation artefacts because nothing was generated. No unusual compression, no telltale noise, no model fingerprint. It is a real capture of a real render. Every forensic property you might test is authentic, because it is authentic. It is simply authentic to a page that was altered before the shutter went.

Detection is also a race against whoever is generating, and anything you build gets beaten by the next model. But the deeper problem is not that fakes are improving. It is that the screenshot was never carrying the information you needed in the first place.

One of them did declare itself

Panel C arrived carrying a content credential: a signed manifest, conforming to the C2PA standard, stating that the image came from a generative model. Read with the right tool, it names itself.

That is worth having, and it is worth being exact about what it did.

It identified the fabrication and said nothing whatever about the authentic capture. Panel A carries no credential, so the manifest cannot tell you panel A is real. It can only tell you panel C is not. An absent credential means nothing at all, which is the situation almost every image is in.

It could not see panel B. Panel B is a real screenshot of a real render, so no participating tool ever touched it and there was nothing for a manifest to attach to. That is not a gap in the standard. A credential describes what a cooperating tool did to a file. It has no way to mark a file that no cooperating tool ever handled, which is exactly the route available to anyone with a browser.

And it did not survive being handled at all. Opening the file and saving it again removed it, in the ordinary tools we reached for. No crop, no format change, no compression involved. It does not take a hostile act to lose a content credential, or even a lossy pipeline. It takes a routine one. A screenshot of the screenshot loses it, as does a paste into a document, a messaging app, or a print to PDF. None of the surfaces these images actually travel through preserves it or shows it to anyone. By the time a screenshot reaches a case file it has usually been through several of them, and nobody along the way was looking.

None of that is an argument against content credentials. It is an argument about where the proof sits. A credential travels with the file, which means whoever holds the file can remove it. What you want is something the holder could not have produced and cannot take away.

The witness was there the whole time

When that page loaded, the server did something on your behalf that it cannot take back.

Modern web traffic is encrypted with authenticated encryption, which means every chunk of data the server sends carries a cryptographic tag computed over the exact bytes, with a key that exists only because of that specific connection with that specific server.

Change one byte and the tag no longer matches. The server produced that tag as a routine part of serving the page. It had no idea it was creating evidence. It could not have refused, and it cannot revoke it afterwards.

We call that the Unwitting Witness®. It is the difference between recording what a screen showed and holding proof of what a server sent. There is more on the mechanism in how it works.

How do you prove a screenshot is real?

One witness is not enough

An honest objection: the party doing the capturing also holds the session keys. In principle they could generate matching tags themselves. A tag alone proves the bytes are internally consistent, not that they ever crossed a wire.

So we do not rely on one witness.

• The server produces the tags, involuntarily, as described above.
• An independent relay sits in the network path and signs the encrypted traffic flowing from server to client as it passes. It never holds the session keys and never sees the content. It attests only that these exact encrypted bytes travelled this path at this moment. We operate it. The capturing party does not, and cannot.
• A timestamping authority anchors the bundle to a trusted clock.

To fabricate a bundle you would need both the session keys and control of the network path at or above the relay. The design gives one party the keys and denies them the path. Neither is sufficient alone, and no single party holds both. The same argument, at length, is in What does a screenshot actually prove?

What comes out

A capture produces a bundle: the encrypted traffic, the server's tags, the relay's signature, the timestamp, and everything needed to check them against published trust anchors.

The design point is that checking requires nothing from us at the time of checking. No live Shorenet service, no account, no permission, no cooperation.

That is only worth anything once the validator is public, and it is not yet. Shorenet is pre-deployment, and publishing it is part of deployment rather than an afterthought, because evidence that only the vendor can check is not evidence.

What you can see today is narrower, and worth being exact about: a demonstration of the decryption step, run in your own browser on a sample baked into that page. It is not the validator and it does not accept a bundle of your own.

Why this is about more than one screenshot

The same gap runs through a much larger category of casework than most people expect, and the law has already moved in a direction that makes it worse. We set that out in The law doesn't ask if it's fake.

Shorenet

Shorenet builds evidence technology for the web. Trawler captures browser traffic as a desktop application. Keel does the protocol work underneath. Pilot is the independent witness in the path.

If your work depends on web content being believed later, we should talk.

Book a walkthrough

We have deliberately not explained how the altered panel was made, or reproduced the instruction given to the chatbot. Neither is a secret and neither is difficult, which is rather the point, but a page arguing for evidential integrity should not double as a tutorial.