At some point in the last two years, you have probably held your phone up to your face to verify your identity for a bank, a financial app or an insurance service.
You took a selfie. The app told you to blink or turn your head. It said "verification complete." You moved on.
What you probably did not think about: where did that image of your face go?
The answer depends entirely on how the app was built. And the difference matters more than most people realize.
Two completely different things that look identical
When an app asks you to take a selfie for the verification, it is doing one of two fundamentally different things.
Option 1: On-device matching
Your phone's camera captures an image. Software on the device analyzes that image, extracts a mathematical representation of your facial geometry and compares it to a reference, either a photo from your ID document or a stored template from a previous session. The comparison happens on the device. The image never leaves.
What gets sent to the server: the result of the comparison (match or no match), possibly some metadata about the session. Not your face.
Option 2: Server-side matching
Your phone's camera captures an image. That image is uploaded to the company's servers. Software running on those servers analyzes the image and performs the comparison. The result comes back to your device.
What gets sent to the server: your actual face image. Which is then processed and, depending on the company's data retention policy, possibly stored.
From your perspective, both experiences look identical. You take a selfie. The app processes it. You are verified. The difference is invisible in the UX and invisible in most privacy policies unless you read carefully.
Why this distinction matters
A face image that never left your device cannot be part of a server-side data breach. A face image uploaded to a server can be.
Biometric data has a property that passwords do not: you cannot change it. If your password is in a breached database, you change the password. If your face geometry is in a breached database, you cannot change your face. The liability from a biometric data breach is permanent.
This is not theoretical. The 2019 Biostar 2 breach exposed fingerprints and facial recognition data for over a million people. The data is still out there. The people whose biometrics were exposed cannot un-expose them.
On-device processing eliminates this risk category for that specific interaction. The image is analyzed and discarded on the device. There is no server-side copy to breach.
The Illinois Biometric Information Privacy Act (BIPA) requires informed written consent before collecting biometric data and gives individuals a private right of action against violators. It has produced billions of dollars in settlements. The legal pressure toward on-device processing is increasing alongside the privacy pressure.
What liveness detection is actually doing
Most face verification flows include liveness detection: the instruction to blink, turn your head or follow a dot on screen. This is not about verifying your identity. It is about verifying that you are a real person present in real time, not someone holding up a photo of the account holder.
Liveness detection can be implemented on-device or server-side, independently of where the identity matching happens. An app can do on-device liveness detection and server-side identity matching, or vice versa.
The reason liveness matters has become more pressing in the last two years. Static photo spoofing, where someone holds up a printed photo or a phone screen showing the target's face, is a known attack. More recently, deepfake video spoofing has emerged as a viable attack method: presenting a synthetic video of the target to the camera rather than the real face. Good liveness detection catches static photos. More sophisticated liveness detection can detect video playback. The most sophisticated systems analyze micro-movements, lighting reflections on the eye and other signals that are harder to spoof in synthetic video.
Selfie Check as a concrete example
I came across Selfie Check while researching how different apps approach this trade-off.
Selfie Check is described as a low-friction, anonymous verification method that uses a selfie and a uniqueness signal to help platforms prevent bot abuse. The key design point: selfie photos never leave the user's device.
The "uniqueness signal" part is worth unpacking. The goal is not just to verify that you are a real person but that you have not already verified in a different account on the same platform. This is the one-person-one-account problem that on-device face matching alone does not solve. A uniqueness signal is a way to check for duplicate registrations without centralizing the face data.
This sits at a lower assurance level with an Orb, it is designed for lower-friction use cases where you need to distinguish humans from bots without requiring the full verification process. The trade-off is explicit: less assurance, less friction, less data collected.
The practical point for anyone evaluating an app that asks for a selfie: look for explicit language about on-device processing and whether the selfie is retained. The apps that do this well say so clearly. The ones that do not say so clearly probably are not doing it.
What to look for when an app asks for your face
These are not foolproof signals, but they are worth checking:
Does the privacy policy mention biometric data explicitly? Under BIPA and similar regulations, collection of biometric data requires disclosure. Absence of any biometric data mention in a privacy policy from a company that asks for your face is a red flag.
Does the app work offline for the verification step? If face verification works without a network connection, it is almost certainly on-device. Server-side matching requires a network round-trip.
Does the privacy policy specify how long biometric data is retained? Reputable on-device systems can honestly say that no biometric data is retained on their servers because none is ever sent. If retention periods are specified in months or years, the data is going somewhere.
Does the company describe their approach in engineering terms? Companies that use on-device processing tend to describe it specifically in their security documentation, because it is a genuine differentiator they want people to know about.
The honest caveat: most people will not read privacy policies or engineering documentation before taking a selfie for a bank verification. The practical takeaway is that these systems are not all equivalent, even when they look identical, and the variance in what happens to your face image is larger than most users assume.
Related reading
Top comments (0)