When we shipped face verification, we were upfront about what it actually defends against: a static photo held up to the camera. A guided head-turn liveness check (more on that below) closes that specific hole — a flat photo can't produce a real left-and-right head movement — and we capture a reference photo so an admin has a final human review.
But we were equally upfront about what it doesn't defend against: a coworker's face, matched correctly, from a coworker's own phone that's already unlocked and sitting on a desk. Buddy punching doesn't require deception if the punching device belongs to the person being punched for. That's a real gap, and closing it needed a second, independent control — not a better camera trick.
The second gate: approved devices
So face check-in now requires two things to both be true, not one: a matching, live face, and a device an admin has explicitly approved for that person. The two checks are deliberately decoupled:
- Enrolling your face is fully self-serve — it's your own biometric template, nobody needs to approve you having a face.
- Trusting a device for check-in is not self-serve. The first time someone tries face check-in from a browser, that device registers itself in a pending state and shows up on the Team page for an admin to approve or reject.
- Until approved, that specific device simply can't be used for a face check-in — the person can still check in with GPS or a manual method in the meantime.
This means the actual attack this closes — 'here, use my unlocked phone to check in, I'm running late' — now requires an admin to have pre-approved that specific phone for that specific person, which defeats the entire premise of borrowing someone else's already-trusted device.
What a 'device' actually is here
We're not fingerprinting hardware — browsers don't expose that, and pretending otherwise would be dishonest marketing. A device is a random, server-issued identifier stored in the browser's local storage the first time face check-in is set up. It identifies 'this browser install,' not a person or a piece of silicon. Clearing browser data or switching browsers means re-registering (and re-approving) a 'new' device — a deliberate, honest tradeoff in favor of not claiming a capability we don't have.
On liveness, and what we don't claim
The blink-detection liveness check computes Eye Aspect Ratio from live facial landmarks and requires an actual blink before accepting a match — a well-established, published technique (Soukupová & Čech, 2016), not something we invented. It's genuinely effective against the common case: someone holding up a photo or a paused video frame.
It is not, and we don't claim it to be, a defense against a sophisticated video replay of someone actually blinking. No purely client-side check can be, because the client making the request is fundamentally not trusted — that's true of literally every browser-based liveness system, not a shortcoming unique to ours. What device approval adds is a check that doesn't rely on the camera at all: even a perfect deepfake video gets nowhere without an admin-approved device behind it.
Two independent, honestly-scoped controls beat one over-claimed one. That's the actual design principle here, more than any specific algorithm.