Web and social media evidence: Prove what was online.

Screenshot or screen recording

Shows what was on screen: Yes

It is literally a picture of what the display showed.

Shows it hasn’t changed since: No

An image file can be edited at any time, and nothing in it records whether it has been.

Shows you reached the real website: No

Nothing in an image connects it to a website. The same picture can be made in a design tool, a browser’s developer tools, an app built to fake conversations, or AI. Screenshots as evidence: tell a real one from two fakes.

Shows what the website sent: No

It shows what the screen displayed, and the person capturing controls the screen. A page can be edited in the browser moments before the shot is taken.

The other side can check it without trusting you: No

The other side can only take the capturer’s word that the image is genuine.

Screenshot plus hash and timestamp

Shows what was on screen: Yes

The same picture of the display as a plain screenshot.

Shows it hasn’t changed since: Yes

A hash is a fingerprint of the file. Once an independent authority has timestamped it, any later change to the file is detectable. This part genuinely works.

Shows you reached the real website: No

The hash is taken after the image already exists. It proves the file has not changed, not where its content came from.

Shows what the website sent: No

A hashed, timestamped screenshot of a fabricated page passes every check. The full argument.

The other side can check it without trusting you: No

The other side can check the file has not changed since the timestamp, but not that it reflects anything a website ever sent.

HAR file (browser export)

Shows what was on screen: Partly

A HAR file is the record a browser’s developer tools export. Pages can only partly be rebuilt from it, and response bodies are sometimes left out.

Shows it hasn’t changed since: No

It is plain, editable text with no signature, so nothing records whether it has been changed.

Shows you reached the real website: No

It carries no certificate chain and no record of the secure connection, so nothing in it shows the real website was reached.

Shows what the website sent: No

It records what the browser says it handled, after the encryption was removed. Nothing inside it shows that a server sent any of it.

The other side can check it without trusting you: No

The other side has to take the word of whoever exported it.

Web archive (WARC)

Shows what was on screen: Replayed

The archive can be replayed to show the page as it was captured. Replay is a reconstruction by the archive software, not a picture of the original screen.

Shows it hasn’t changed since: If sealed

A WARC file carries content digests, but anyone who edits the file can simply recompute them. Only an external seal, such as a signature or a trusted timestamp over the file, makes changes detectable. Standard: WARC 1.1 specification (IIPC), basis of ISO 28500

Shows you reached the real website: No

The format has no standard place for the website’s certificate or the signature from the secure connection, so nothing inside a WARC shows the real server was reached. Standard: WARC 1.1 specification (IIPC), basis of ISO 28500

Shows what the website sent: No

A WARC records what the capturing software wrote down, after the encryption was removed. Archiving proxies write WARCs from whatever passes through them, so whoever controls the collector controls the record.

The other side can check it without trusting you: No

Checking a WARC means trusting whoever collected it. That is fine for a well-run archive, but it is trust, not proof.

Capture service run by a vendor

Shows what was on screen: Yes

The vendor’s own browser loads the page and records what it displayed.

Shows it hasn’t changed since: Yes

The vendor hashes and signs the capture, so later changes are detectable, provided you trust the vendor’s key.

Shows you reached the real website: Vendor’s word

The vendor’s browser connected to the site, but what you receive is the vendor’s own record of the page, not the website’s signed connection. You rely on the vendor’s statement that it reached the real site.

Shows what the website sent: Vendor’s word

The vendor sees the decrypted page and writes its own copy, so the record is only as good as the vendor’s honesty and security. Because the vendor is independent of you, this is a real improvement on capturing it yourself.

The other side can check it without trusting you: Trusts the vendor

The other side does not have to trust you, but it does have to trust the vendor, which can read everything it captures.

Network capture with session keys (PCAP + keylog)

Shows what was on screen: Rebuilt

The page can be rebuilt from the captured traffic. It is a reconstruction, not a picture of the screen.

Shows it hasn’t changed since: If sealed

A raw capture file can be edited like any other. Only a signature or a trusted timestamp over it makes changes detectable.

Shows you reached the real website: Full handshakes

When a connection starts with a full handshake, the website signs it with its certificate, which proves a session with the genuine certificate holder took place (though not when). Resumed sessions, which browsers use routinely, and older RSA key exchange carry no such signature, so they cannot prove it. Standard: TLS 1.3, RFC 8446, since revised as RFC 9846 (section 4.4.3)

Shows what the website sent: No

After the handshake, traffic is protected with keys that both ends hold. The capturing machine holds them too, so it can create traffic the website never sent, with valid cryptographic tags, or inject it into the capture. Nothing in the file tells the two apart. Standard: TLS 1.3, RFC 8446, since revised as RFC 9846 (sections 5.2 and 7)

The other side can check it without trusting you: No

The other side has to trust the machine that held the keys, which is the machine of the party making the case.

Shorenet, with our relay

Shows what was on screen: Yes, recorded

Shorenet keeps a recording of the screen, sealed with the capture, showing what was displayed. It can also rebuild the page from the traffic the website actually sent and extract stills from it for an exhibit. The recording shows what was displayed; the traffic shows what the website sent.

Shows it hasn’t changed since: Yes

The relay signs the encrypted traffic as it passes, and the whole capture is sealed with post-quantum and classical signatures together. Any change after sealing breaks them, including one made by the investigator.

Shows you reached the real website: Full handshakes

The website’s signed handshake is kept in the capture, with the same limit as any network capture: resumed sessions and older RSA key exchange carry no server signature, and Shorenet grades those down rather than rounding them up.

Shows what the website sent: Witnessed, full handshakes

Our relay signs the encrypted traffic as it passes, from the network side, without being able to read it, so faking what it witnessed would take far more than editing a file. We operate the relay: it is independent of the investigator, not of us. How the witness works, and its limits.

The other side can check it without trusting you: Trusts our relay and its keys

Built to be verified by anyone holding the capture, using published standards, with no Shorenet server, account or cooperation; the validator that does it is not published yet. What remains is trust in our relay, which we set out in full. How the witness works, and its limits.