stablepixel

A call is folded into zero-knowledge proofs (a running chain of NeutronNova + Vega proofs by Microsoft Research) of a sensor’s fingerprint (PRNU, a sort of optical DNA) against its prior enrolled sealed lock (we call an ‘Impression’). An Impression is the finished result of the sensor’s sign-stable photodiodes appearing steadily throughout an aggregate of flats (acting as a biometric key or credential), scrambled into a cancellable template using our version of a BioHashing technique adapted to cameras (see our papers: https://apertrue.photo/papers). These templates are stored in a registry and its history independently cosigned by witnesses including Google’s TrustFabric (staging), Geomys, and Mullvad.

Happily, call apps’ video encoders all but compress fingerprints completely away so the risk of leakage is low, but if it happens, a cancellable template can be retired and struck anew, completely different from the old. Furthermore, fingerprint attacks including even from the insider are flagged as of macOS 27, with Apple vouching for our genuine app on a genuine Mac with protections on, so our security doesn’t depend on compression hiding the fingerprint.

The proof additionally cuts a picture of the face on a call and an app-signed comparison is made against a sealed reference of the user’s passport photo, extracted during user identity enrolment. User identity is proven in zero-knowledge (by ZKPassport), strictly only ever held on personal devices (the passport photo travels encrypted between phone and computer via our service so we can never read it, and the photo is immediately discarded with just the reference kept). There is no need for new hardware or to visit anywhere for enrolment, and the prover may choose to include their passport name for call verification or withhold it. In either case, this means you know exactly who you’re dealing with or, at least, that a passport-verified human is on the other end, and the prover keeps their privacy. Indeed, the full flow requires the proving individual to own a passport. An optional work-email domain proof proves that the person on the other end owns a mailbox at a particular domain, allowing, for example, me to prove that I work for Apertrue because I own an @apertrue.photo email address.

At the beginning of a call, the proving side will read out nine words stretched by Argon2id, linking the proofs to the call, which the verifier types in to open the verification page and decrypt the call evidence. You can view a previously verified call here: https://witness.apertrue.photo/verify/sample. Along with an evidence wall, the verifying party can check the face in the left-corner of this page against the face they see in their call app. This sample, being a saved receipt, won’t show a face, but a live call will.

It’ll use about 5% of an M5’s processor and about 20% of an M1 as the prover talks.

The analog hole still exists so a convincing screen held up to the camera or mask may slip through, but it would require physical access to the person’s enrolled computer which eliminates practically all of the remote impersonation threat. An insider could in theory play themselves in a fake recording held up on screen, perhaps to impersonate a more intelligent version of themselves to fool a job interviewer. Or they could hand their enrolled device to a friend or colleague wearing a hyper-realistic silicone or resin mask, and again the sensor and face comparison checks would both pass. If the prover tries to deceive the verifier by using an accomplice and then scurries off in a hurry, the verifier can make a mid-call check that the passport holder is alive in front of their phone, stopping someone else using their device without them.

It’s worth pointing out that Witness doesn’t say anything about the user’s voice.

If you’ve got this far, I appreciate you reading through to the end. Any feedback is most welcome. Thank you.

Having studied Japanese at university and living there for a bit my interest naturally flowed in that direction, so I ran a quick check on OpenAI's tokeniser, nothing close to an actual study. I ran two tests of everyday English and its Japanese equivalent and another using more technical vocabulary across both languages. These were my results: Tokeniser Everyday JP/EN Technical JP/EN GPT-3 2.69x (183/68) 3.48x (233/67) GPT-4 2.16x (147/68) 2.53x (167/66) GPT-5.x 1.49x (101/68) 1.74x (115/66) It shows that the gap clearly has shrunk a fair bit with Japanese going from 2.7x English on GPT-3 to 1.5x on GPT-5.x for everyday text. The same passage of text yielded flat results for English across each tokeniser, so all the improvement went into Japanese. I also found that the Japanese polite form used to cost extra on GPT-3 but is now effectively free. The polite version of the Japanese passage was 9 characters longer (133 vs 124), and contained endings such as ました, ません and でした which have all become single tokens in newer tokenisers. Perhaps most interestingly, katakana loanwords seemed to add a lot of extra cost. For example, a word like パスワード(password) is split into four tokens (パ / ス / ワ / ード), while "password" is one token in English. In this example, the exact katakana string likely did not appear frequently enough in the training data, unlike the common hiragana clusters such as the polite endings, and the English word “password”, which earned their own tokens. The newer tokenisers continue to split less common kanji (like 靴 and 濡) into byte pieces, but katakana stands out as even everyday words are broken apart. It'd be interesting to run these checks on the same Qwen, Gemma, Llama tokenisers the study uses.

Can echo this, I've also fallen foul of keychain behaviour. In my case I found a lookup that passed the account name as raw bytes instead of text didn't match my item. On macOS it matched all items with a blank account (strictly, generic password items), which on my computer meant items from GitHub CLI, Malwarebytes, and Adobe Creative Cloud. The app I was building silently used one of those as its key, and would change whenever one of those apps would update its entry. The fix was to make sure the account is passed as a string and that it has a service name so that lookup either matches exactly my item or none. The API takes a loosely typed dictionary, so wrong types throw no errors, just different behaviour. I now always test against the real keychain and not a mock.