Why we store face embeddings, not images
Our biometric 'digital ID' keeps a 512-dimensional ArcFace embedding per user — never a raw photo. Here's the engineering + privacy reasoning.
We got asked this a lot during the closed pilot: why do you store a face embedding rather than a reference photo? The short answer: an embedding is a one-way projection that we need for matching, and it's dramatically safer to store than a photo.
A photo is identifiable by design. If a copy leaks, an attacker can perform any downstream task they want — face-search, deepfake inputs, or just identification in other contexts. A 512-dimensional ArcFace embedding is a fingerprint of the face: enough to compare against another embedding produced the same way, but not enough to reconstruct a recognizable image.
Operationally, embeddings are cheap to match. Verifying a login candidate is a cosine-similarity comparison against the user's stored vector — milliseconds, no model re-run beyond extracting the candidate's embedding.
We discard the candidate image the moment we've extracted its embedding. The embedding for the login attempt is compared against the stored one, then dropped. Only the enrollment embedding persists, and users can delete it from their digital-ID settings at any time.
Does this make the system unbreakable? No. But it does mean that a database breach gives an attacker vectors, not photos — and the rest of our architecture is designed so that vectors alone don't let them into another user's account.
— Platform engineering