How a call is proven
Witness proves that the video on a call is coming live off a camera its owner registered in advance, and lets the viewer's own browser check that proof.
Proven, not detected
A deepfake detector looks at the content of a video and scores it as real or fake. That puts it in an arms race with the generators it is trying to catch. Each new generator is built to get past the detectors of the day, and a detector that published its model would hand the next one a target to train against.
Witness never judges what is in the frames. It proves where they came from. That is why its verifier can be published while a detector's model cannot. A proof's soundness does not depend on anyone keeping a secret.
The journey of one call
Four stages, from enrolling a person and their camera once to the viewer's browser showing a face.
-
Once, at enrolment
Every camera sensor has a physical fingerprint. Tiny differences between its light-sensitive cells leave a faint, fixed pattern in every frame it takes, known in the published research as photo-response non-uniformity, or PRNU. Each sensor's pattern is its own, which is what makes it a fingerprint.
Done once per camera. The fingerprint itself never leaves the Mac. - The Witness camera extension on the Mac captures frames, and a sensor-fingerprint extractor derives the camera's PRNU pattern from them.
- Some cameras smooth their picture in dim light, and the smoothing hides the pattern. The extension builds the fingerprint only from frames the camera reports it did not smooth, so enrolment asks for good light. Calls are then checked in whatever light the room has.
- The pattern becomes a cancellable template, which we call an Impression. If it were ever exposed, it can be retired and a new one issued that cannot be linked to the old.
- The Mac produces a zero-knowledge enrolment proof, and the service checks it.
- The camera is added to the registry, a Merkle tree of the enrolled cameras.
- The registry's signed root is published to a transparency log, an append-only record that independent witnesses cosign. Changing its history would take those witnesses colluding, not one operator acting alone.
The person is enrolled once too, from their passport. We never hold a copy of it.
- Their iPhone reads the chip in their passport and, using ZKPassport's open-source proving code, proves in zero knowledge that the passport is genuine and that the face in front of the phone matches its photo.
- From the proof we learn their name, which we keep, and the passport number, which we never keep. The number is turned straight into a one-way digest, so the phone can later show it is reading the same passport. A one-way identifier also means one passport can make only one identity. No scan of the passport and no date of birth ever reaches us.
- The passport photo travels from the phone to their Mac encrypted, so only that Mac can open it. We pass it on without being able to read it, and delete it once the Mac has it. Their computer keeps a reference made from the photo, never the photo itself. Our record of them holds only a key made from the photo with a secret that stays on their devices, so it cannot be turned back into a face, and we cannot match a face against it.
- The face checks run only with their consent, and turning them off deletes that key. Their name is shown to a viewer only if they choose.
-
Starting a call
The words belong to this call. The key lets later signatures be traced to the Witness app. - The Mac app creates the call.
- The nine words the viewer will type are derived from the call's binding and a round of a public randomness beacon (drand), which ties them to this call.
- The app registers an Apple App Attest key, which lets the service tell that later signatures come from an app we signed, on a genuine Mac with its security settings on. Apple does not say which version of the app it is; the service checks the version the app states against its own minimum.
-
During the call, every few seconds
Windows of video, hash-chained, each carrying a sealed face picture, folded batch by batch into receipts. - Frames are grouped into short windows.
- Each window is checked against the enrolled fingerprint.
- A small sealed face picture is cut from the same frames.
- The windows are hash-chained, each committing to the one before, so a window cannot be dropped or moved without breaking the chain.
- The app posts a signed checkpoint, which is an App Attest assertion over the head of the chain.
- Batches of windows, a few seconds apart, are folded into a zero-knowledge receipt proving that those windows passed, together with a membership proof that the camera is in the registry. Neither reveals the fingerprint or which camera it is.
The frames themselves never leave the Mac. What travels is the chain, the receipts, and the face picture, encrypted under a key the service never holds.
-
The viewer
The service is a courier, not the judge. - The viewer opens the link and types the nine words the caller read out. The browser turns them into a key, and only a value derived from them is sent. The page then shows three words, which the viewer reads out and the caller types into the Witness app to let them in.
- The browser itself re-folds the hash chain, re-verifies the receipts and the membership proof with the same verifier compiled to WebAssembly, checks the signature on the registry root, and checks that the root is in the transparency log with the witnesses' cosignatures.
- Only then does it show the face picture.
The service carries the evidence from one end to the other. It is a courier, not the judge.
What the proof covers, and what it does not
The proof covers the camera and the face in the ring, nothing more. That face was in front of a camera enrolled to this person, and what the ring shows is what the camera extension cut from those frames and sealed into the proof. Video swapped into the meeting by software, from a file or a face-swapping tool, never touches it, because the proof reads the camera and not the meeting app. The video in your meeting app is not checked by Witness. Compare it with the picture in the ring.
The proof does not prove a live person is in front of the lens. A deepfake can still reach a viewer three ways.
- A screen or a mask held in front of the enrolled camera is captured like anything else, and the passport face check, where it runs, judges on appearance alone.
- A computer with its protections switched off can be fed frames ahead of the camera extension, and if they carry the enrolled sensor's pattern the camera check passes. On a Mac, Apple lets the app's signing key work only while System Integrity Protection and full security mode are on, so such a Mac cannot sign its checks. The page then does not say that Apple confirmed the Mac's security settings, and the passport face result is withdrawn.
- Hardware spliced into the camera module inside the computer is beyond anything software can attest.
The voice is not checked at all. The face in the ring is the face, not the speaker. Only the person using Witness is checked, and nothing here speaks for anyone else on the call. Whether the face on your call is the face in the ring, and who is talking, are yours to judge.
Checked by your own browser
The verify page carries an instrument panel. It shows how long it has been since the last signed check arrived, how long since the last receipt, how many windows each check vouched for, and how many windows the viewer's browser has re-folded itself, timed on the viewer's machine. Beside it, a ledger lists each check the page re-did locally.
It exists so that the viewer does not have to take the service's word, or ours. Every number on it is measured or received. Where evidence is missing, the page says so rather than drawing over the gap, so absence is reported as absence. A cross is something Witness did not check on that call, not something it found false. The viewer can also save the call's receipt, one file holding exactly what the browser verified and the keys it verified against, for anyone to re-check later without the page.
The receipt verifier is being published as open source, at github.com/Apertrue/witness-verify.
How this was reviewed
In October 2026 the circuits, the receipt verifier, the admission scheme that lets a viewer in with the nine words, and the service were reviewed in house before launch, and the findings were fixed. An independent external review is the next milestone.
Where it runs
The person on camera needs a MacBook with Apple silicon on macOS 27 or later, an iPhone, and a passport with a chip. Witness verifies the MacBook's built-in camera, not an external webcam. Not every country's passport can be read yet, and the app says so if it cannot read one. Driving licences and identity cards are not accepted today. The viewer needs only a modern browser. The live-call product runs inside Google Meet, Microsoft Teams or Zoom in the browser, where Witness Camera is chosen like any other camera.
Windows is next. It does not yet have an equivalent frame-integrity path.