Chapter 05 · 7 min read
Biometrics, Liveness, and the Deepfake Problem
Why "selfie verification" as a meme has aged poorly. The progression from photo-match to active liveness to passive 3D liveness, and what's coming next.
For most of the 2010s, "verify the user" meant "ask them to upload a photo of themselves holding their ID." It worked because faking it was inconvenient.
By 2024, deepfake video generation costs about $0.10 per minute and runs on a laptop. The "hold your ID" verification is now trivial to defeat. The verification industry has spent five years racing to stay ahead.
The four generations of liveness
| Gen | Era | How it works | How it's defeated |
|---|---|---|---|
| 1 | 2010–2017 | Static selfie + ID photo, compared by humans or face-match models | Photo of a printed photo |
| 2 | 2017–2020 | Active liveness: blink, turn head, follow a dot | Pre-recorded video on a second screen |
| 3 | 2020–2024 | Passive liveness: detects screen reflections, micro-movements, depth via camera fusion | Hardware injection attacks (virtual cameras) |
| 4 | 2024+ | 3D liveness with infrared depth, randomized challenges, server-side challenge response | Active research |
What "passive 3D liveness" actually means
The current best-in-class systems use the front-facing camera to construct a depth map of the user's face by analyzing micro-movements and parallax across rapid successive frames. A static photo or screen has no depth signal; a deepfake video lacks the consistent micro-movement patterns of a real face.
Combined with:
- Texture analysis (does the skin have real subsurface scattering, or screen-pixel artifacts?)
- Reflection analysis (does the eye reflect the room, or a screen?)
- Server-issued randomized challenges (turn head left, blink twice, smile) sent after the session opens, so they can't be pre-rendered.
...passive 3D liveness has a present-day spoof rate around 0.1%. That's good. Not great. Improving fast.
Hardware injection attacks
The frontier of attack: instead of holding a phone up to a screen, attackers patch their browser to inject fake camera frames directly into the WebRTC pipeline. Tools to do this exist on GitHub.
Defense:
- Verify the camera frames originate from a real device by analyzing metadata + timing patterns.
- Use device attestation APIs (App Attest on iOS, Play Integrity on Android) to confirm the app is genuine.
- For high-risk verifications, require the verification to happen in a native mobile app rather than a browser.
The biometric data privacy minefield
Even if your liveness check is perfect, you need to be careful what you do with the biometric data afterward.
| Law | Jurisdiction | Key requirement |
|---|---|---|
| BIPA | Illinois | Written consent before collection. $1k–$5k per violation. Class actions are common. |
| CCPA / CPRA | California | Biometric data is a protected category requiring opt-in. |
| GDPR Art. 9 | EU | Biometric data is "special category" — explicit consent required, with right to erasure. |
| Texas CUBI | Texas | Mostly statutory; AG enforcement only. |
The safest pattern: don't store the biometric template or raw image. Run liveness during the session, return a result, discard the data. If you do store, encrypt with a per-user key derived from the user's session, not your master key.
What to actually use
If you're building today, your liveness layer should be:
- Passive 3D liveness as the default.
- Server-side randomized active challenge as a fallback for high-risk sessions.
- Hardware attestation for native apps doing high-value verifications.
- Zero biometric storage unless your customer explicitly opts in for re-verification.
And keep an eye on the deepfake landscape. It changes every six months.