Product wants the whole liveness check on-device for latency and offline use — what do you require stays server-side?

## The decision in front of you Product has a legitimate case. Round trips cost hundreds of milliseconds on a bad connection, the check should work in a lift or on a plane, and keeping camera frames on the device is genuinely better for the user. They are asking to move everything — capture, model, comparison, verdict — into the app. The security position is not "no". It is a line drawn in a specific place, and being able to draw it — and to say what it costs — is the whole of the judgment here. ## The rule worth writing down Two sentences, applied to every component on the diagram: 1. **Anything we ship is fully known to the adversary.** Not "hard to extract" — known. Obfuscation and unusual formats buy a one-time delay, and the file is copied freely afterwards. 2. **Anything the client reports is a claim, not evidence.** A verdict, a score, a representation: all are numbers chosen by whoever controls the device. Everything follows from those. The model may ship, because it is a function and not a secret you can keep once it runs on a user's hardware. The *authorization* may not, because it is exactly the thing an adversary would otherwise be free to assert. ## What that concretely allows and forbids **Allowed on-device:** the encoder and any expensive computation; a prefilter that decides whether to bother the server; user-experience outcomes such as "move into the frame", "try again in better light", or an instant optimistic screen that is confirmed later. **Kept server-side:** the stored reference the comparison is made against; the accept threshold; the step-up policy; and the entitlement decision, taken together with everything the model does not see — the account's history, the device, the amount at stake. **Required to make the server half real:** a binding the client cannot forge — hardware-backed attestation of the device and app build, plus a fresh server-issued challenge — so the server is checking something rather than believing a report. ## Naming the cost honestly The honest answer to "can it work fully offline" is *not for anything that moves money*. That is a product limitation, and pretending otherwise by adding client-side integrity tricks is the failure mode: each trick is defeated once and then never again, and the team ends up with a decision they believe is protected and cannot say by what. The compromise that usually holds: local for the experience, server for the authorization, with the local result carried up and re-checked rather than trusted. Offline degrades to a lower-consequence tier — view balances, queue an action, prepare a submission — rather than to full capability. ## The controls that quietly vanish, and who pays for that This choice retires an entire class of assurance the organisation may not realise it was relying on. The vocabulary of *pricing an adversary through your endpoint* — making them pay per call, capping them per identity, returning less, watching how their traffic looks — presupposes they must come through you. After the bundle ships, none of it applies to the model. The assurance work does not disappear; it moves, and someone has to fund it: server-side checks, attestation plumbing, a client-version retirement process, and a red-team engagement scoped white-box rather than black-box. The second cost is on paper. Every robustness figure this system carries has to be re-quoted under white-box access, and that number will be worse, sometimes much worse. A lead's job is to make sure the register says so before an incident does, because the alternative is discovering during a response that the documented threat model described a deployment you stopped having when the model started shipping. ## The counter-argument, taken seriously There is a case for shipping the whole thing: for a low-consequence decision, the offline and privacy benefits can outweigh an adversary's ability to defeat it, and adding a round trip to satisfy a threat nobody is funding is its own kind of waste. The test I would apply is *what does a bypass get them*. If the answer is a slightly better recommendation or a skipped prompt, ship it all and stop spending. If the answer is a payment, an account recovery, or access to somebody else's data, the decision stays with us and the latency is a cost of doing that business. ## The sentence to leave the meeting with The model can go in the bundle; the decision cannot. What ships becomes the adversary's, what the client says is a claim, and the only control we keep is the one we compute ourselves from something they cannot mint — so the question is never how well we hide the file, but which decisions we are willing to let a hostile client make.