What a capture proves, what witnesses it, and why you do not have to trust us.

The problem with capturing at the screen

Every web capture method in common use, from a screenshot upward, records what the operator's machine displayed. Hashing that file and timestamping it proves the file has not changed since. It does not prove the file reflects anything a server ever sent.

The first fix is to stop capturing the screen and capture the encrypted session instead, sealing it on the device. That is a genuine improvement and not a cosmetic one. The record becomes the conversation rather than a picture of it, it carries the server's own authentication tags, it can be timestamped by an independent authority, and any later change to it breaks the signatures over it. Against a screenshot this is a different class of exhibit.

It still stops short of one thing, and it is better that we mark the spot than that someone else does. Here is the whole of it:

The reason for that last row is worth understanding, because it is a property of TLS rather than a shortcoming of anyone's product, and it holds for every version in current use. The keys protecting the traffic are symmetric: both ends derive the same material from the handshake, so the client necessarily holds the key protecting the server's responses. That is how it reads them at all. Anyone holding that key can produce records that look like the server's, carrying valid authentication tags.

The server does sign during the handshake, and in TLS 1.3 that signature covers the handshake transcript. In TLS 1.2 the equivalent signature covers the key exchange parameters and the two random values, and in the older RSA key-transport suites the server does not sign the exchange at all. In none of these does the server sign the application data that follows. So on every version the same split applies: "a genuine session with this certificate holder happened" is provable from the device alone, and "this is what they sent" is not.

No amount of device hardening changes that, because the device can only vouch for what it was given. What hardening does change is cost and detectability, and that is worth having: sealing the capture in-process so there is no editable file sitting in the gap between writing and sealing, keeping the session keys out of a loose plaintext file, and attributing every captured flow to the socket and process of the browser we launched, so that traffic injected from anywhere else has no socket or the wrong process and is refused. Those measures are designed and partly prototyped rather than shipped, and we will say when that changes.

Even complete, they would raise the bar rather than close the gap. They are capture-time assertions by the device, which is engineering assurance and not cryptographic proof. A device compromised at the kernel, or one with code injected into the live browser, can fabricate content and lie about its origin in the same breath. The two tiers therefore differ in kind and not in degree, which is why the relay exists and why the rest of this page is about it.

So there is a ladder rather than a switch. A screenshot proves almost nothing about the event. A sealed device capture is tamper-evident, timestamped, and honest about being device-asserted. Only a witness the operator does not control reaches independently witnessed.

That gap is tolerable only while nobody contests the capture. It is not a safe place to be as challenges to digital evidence become routine. The argument is set out at length in What does a screenshot actually prove? and in The law doesn't ask if it's fake.

Capture below the browser

Shorenet's capture engine records at the operating system level, using the OS packet capture interface, rather than instrumenting a browser or recording a screen.

What it records is the encrypted session as it actually crossed the network: TCP, TLS 1.2 and 1.3, ECH, QUIC, HTTP/1 through 3, and WebSocket. Because capture sits below the browser, there is no extension, no injected code, and no modification of the page under examination.

Shorenet is delivered as a desktop application. It is browser-traffic capture delivered as a desktop app, not a browser plugin. Nothing that happens while a page is rendered can alter what was already recorded on the wire, so a page edited in developer tools and the captured session simply disagree. macOS is the platform available today, with a Windows build in release preparation.

On which point, the evidential strength does not run in the order the release schedule suggests, and it is worth saying so plainly. The device holds a signing key of its own, and whether that key's custody can be proved to somebody else differs by platform. On Windows, the TPM 2.0 chip allows a chain to be verified from the device's attestation key back to a pinned silicon vendor root, so hardware custody is something the validator checks rather than something we assert. On macOS, the Secure Enclave offers no equivalent a third party can verify, so we grade it as software and make no hardware claim for it at all. We would rather mark our own currently shipping platform down than claim a residency we cannot demonstrate to an examiner.

Be careful about what a TPM is doing here, because the word carries more freight than the mechanism. We use it for identity only. It establishes which physical device holds the signing key, rooted in the chip and checkable back to its manufacturer. It does not attest the state of the machine: no measurement of the running software is collected, none is carried in the evidence, and the verifier rejects any attestation that is not a key-certification. So a TPM here does not tell you the collecting computer was healthy, uncompromised or running what it should have been. Anyone offering you that from a TPM is overselling it.

Which means hardware custody, however well proved, is a separate question from whether the content is authentic, and does not touch it. A device can only ever vouch for what it was given, and proving which device vouched does not change what it was given. That gap is closed by the relay and by nothing else, for the reason the next two sections set out.

Where the two do combine is in how strong a record can get. On Windows, with the relay in the path, a bundle carries hardware-rooted device identity, an independent witness to the content, and a freshness check on the device's attestation made against a party the device does not control. That is the strongest configuration the design allows: on those three axes, device identity, content provenance, and the freshness of the device's attestation, it is the only one where each has an answer a third party can check. It leaves untouched everything this page says elsewhere it cannot reach, which is the health of the machine, who was at the keyboard, whether what was served is true, and the faithfulness of the reconstruction. Without the relay, a TPM capture keeps its hardware-rooted identity and its content binding, but the freshness of the device's own attestation then rests on the independent timestamp rather than on an external witness, and the validator says so in as many words rather than rounding it up.

The server's own authentication tags

TLS does not only encrypt. It authenticates. Every record a server sends carries an authentication tag computed over that exact content under the session key, which is what lets a browser detect alteration in transit. Browsers check these tags constantly, discard them, and nobody thinks about them again.

Shorenet preserves them in the evidence bundle. In a genuine capture they are a by-product of the target server serving the content, produced without it knowing they would be kept, without its cooperation, and without any relationship between that server and Shorenet or the investigator. Nothing is asked of the service and nothing is broken.

This is the Unwitting Witness®.

Being precise about what this carries on its own, because the distinction is the hinge of the whole design. As set out above, the key is symmetric and the collecting machine holds it too, so a valid tag proves the content was authenticated by a holder of that session key rather than by the server specifically. Standing alone, the tags tie the session to whoever controlled the certificate and do not rule out fabrication by the machine that did the collecting. It is the relay in the next section that closes this, by witnessing the ciphertext off the device before that machine could have authored it. Only the two together support the conclusion that the server produced this traffic.

Two further things it does not establish, in any combination: who was operating an account, and whether anything depicted is true.

The independent relay

The server's own tags are necessary but not sufficient. An operator who holds the session keys and also controls the network path could still, in principle, fabricate. Closing that requires a witness the operator does not control.

Shorenet operates a relay that carries the session and separately signs the ciphertext travelling from server to client. Direction is established by the tunnel itself rather than by anything inside the traffic, so it cannot be asserted by an endpoint.

The relay never holds the session keys and never sees plaintext. It witnesses that a server sent this, with no capacity to see what "this" is. That property is what makes independent witnessing deployable at all: the witness can attest without ever being exposed to the material.

Fabricating a session would require both the session keys and control of the network path at or upstream of the witness. The investigating party holds the keys. The architecture denies them the path.

Two limits, stated before anyone else states them. First, the relay's signature establishes passage, not time: trusted time comes from the timestamp authority in the next step, not from the relay. Second, the relay is independent of the investigating party, not of us. We operate it, its authority to sign comes from a certificate we issue with a fixed validity window, and its signing key is held in software rather than in tamper-resistant hardware. A compromise of that host, or extraction of that key, would permit signatures indistinguishable from genuine ones until the key is revoked. What the design removes is the ability of the party holding the session keys to fabricate on their own: it raises the requirement from compromising one party to compromising two. That is a meaningful raising of the bar and it is not an absolute guarantee, and any supplier who tells you otherwise should be asked for their custody model in writing.

Sealing and timestamping

The completed bundle is timestamped against an RFC 3161 authority, anchoring it to a time that does not depend on the operator's clock. The authority receives only a cryptographic summary of the capture and never the evidence itself, so timestamping discloses nothing about the content. It is the one witness in the chain that is neither the collector, nor the server, nor us.

There is a distinction here we would rather draw than have flattened. Who asked for the timestamp matters as much as who issued it. A request made by the capture host is a genuine bound and a real defence against backdating, because the operator cannot make the time earlier than it is, but the operator still chooses when to ask. A request made by the relay instead takes that choice away: the operator's machine is out of the loop for the timing entirely. Both are honest timestamps. They are not the same claim, and a bundle records which one it carries rather than blurring them.

Phrased the way it should be phrased in a witness box, this establishes that the capture was sealed no later than that time. It does not by itself prove the capture was made at that time. The distinction is small in wording and large in cross-examination, so we hold to it.

The bundle is then signed with two algorithms together: ML-DSA-87, a post-quantum lattice signature standardised by NIST, alongside a classical elliptic curve signature, Ed25519. Both must verify. Evidence has a long life, and a bundle sealed today may be challenged in a decade, so the signature is built to survive advances that would break a classical scheme on its own.

For accuracy: that signature is applied to the session as a whole rather than to each packet individually. Individual packets are bound into the one signed commitment by the summary structure above, so altering a single packet still breaks the session signature. It is one signature covering everything, not millions of small ones.

The result is a .keel bundle: the captured session, the server's authentication tags, the relay attestation, and the timestamp, sealed together. It is one file. It can be copied, hashed, written to a disk, attached to a case file and disclosed like any other exhibit.

Verification, without us

This is the part that matters most, and it is the reason for everything above.

Any party holding the bundle can check it: the investigator, the prosecutor, the defence expert, the court's own adviser. The outcome is binary. The bundle verifies against its witnesses, or it does not. There is no model, no confidence score, and no error rate to accept on trust. Verification needs:

• No Shorenet server. Nothing is sent to us. We have no way of knowing a check ever happened.
• No account, licence or subscription. There is nothing to register for and nothing that can expire.
• No network connection, once the validator and the bundle are on the machine, so it can be done on an air-gapped workstation. One honest cost of working offline: whether a signing key was later revoked is checked against a live revocation list, and an offline check cannot see a revocation issued after the copy it holds.
• No continued cooperation from us. If Shorenet ceased trading tomorrow, every bundle already produced would remain verifiable.

That is a property of where the evidence sits rather than of our goodwill. The captured evidence and every witness statement over it travel inside the bundle, and the signature, encryption and timestamping algorithms are public standards rather than anything of our invention. At that step an examiner is checking arithmetic, not accepting a claim.

One thing deliberately does not travel inside the bundle: the list of authorities the validator is willing to trust. Those roots live in the validator, not in the evidence, and the reason is worth stating because it looks like an omission and is the opposite. A bundle that carried its own trust anchors would let whoever produced it nominate who vouches for it, which is no check at all. The examiner's own copy of the validator decides what counts as a trustworthy authority, and the bundle only gets to present material to it.

On the validator itself we will state the position as it stands rather than as we would like it to sound. Shorenet is pre-deployment and the validator is not yet published, which is a commercial decision about protecting intellectual property before deployment rather than a technical constraint. Our commitment is to release it, with the bundle format specification, under an open licence before the product is used in live casework, so that an examiner or an opposing expert can read it, run it, and write an independent implementation reaching the same verdict without our code. Evaluation partners are given the validator and the specification directly in the meantime. Until that public release happens, this is a commitment we are making rather than something you can check, and it should be weighed as one.

See a real decryption run in your own browser, with no Shorenet server involved, as an illustration of the final step.

Where the boundaries are

Our standing rule is to state the boundary before opposing counsel does.

We do not detect synthetic content. If a server serves a fabricated image, our evidence proves faithfully that the server served it, and says nothing about whether the depicted event occurred. Content authenticity and capture provenance are different questions.

We do not identify people. We prove that a page as served displayed a given account handle. We do not prove who was at the keyboard. Attribution to a person comes from subscriber data, device examination, and the rest of the investigation.

We prove transmission, not truth. The claim is narrow and deliberately so: that a specific server sent specific bytes to a specific client, sealed no later than an independently certified time, attested in transit by a party that cannot read the content and does not answer to the investigating party. We are not disinterested in the general sense and we will not claim to be: we sell this, and we operate and certify the relay. The independence that matters evidentially is independence from whoever is making the case.

Cryptography proves the bytes, never the interpretation. Rendering captured bytes back into a readable page or message is parsing, which is engineering rather than mathematics. Where a reconstruction is uncertain we fail closed and quarantine it rather than present a best guess, on the view that a wrong exhibit reaching a courtroom is far worse than a missing one. We test our parsers against independent reference implementations we did not write, and treat disagreement as a defect in ours.

The reasoning behind each of these is published in full, boundaries included, in Shorenet Research.

Current status

Shorenet is pre-deployment. The capture engine is running and four UK patent applications are filed. We are not going to show you a customer list or a case study, because there is not one to show, and a technology asking to be trusted on unverifiable claims about other people's cases would be making exactly the mistake this product exists to correct.

We are looking for a law enforcement unit willing to host an evaluation against real casework, under proper controls: a capture of a service your unit actually deals with, verified by your own people on your own equipment, followed by a session in which you try to break the reasoning. If that is something your unit would consider, we would like to hear from you.

We are also exhibiting at the NPCC Innovation and Digital Summit, ACC Liverpool, 19-22 October 2026, Stand G9.