Why browser-based face liveness cannot be trusted
The camera is a device driver. The detection runs in JavaScript. The result is a field in an HTTP request. At no point does the server observe anything an attacker cannot manufacture.
Why can't a browser liveness check be trusted?
Because it asks the client to report on itself, and the client is the thing under attack. The camera is a driver, the detection is JavaScript, and the result is a field in an HTTP request. At no point does the server observe anything an attacker cannot manufacture.
- Client-side liveness violates the basic rule that a security decision cannot be delegated to the party being evaluated.
- Virtual camera drivers inject synthetic video at the operating-system level, below anything a browser can observe.
- Hardware authenticators avoid the problem by keeping the biometric local and having the server verify a signature instead of a claim.
Part of Privileged identity and account recovery
Three places the attack lands
A browser liveness check has three layers, and each can be attacked independently. An attacker only needs the cheapest one.
| Layer | Attack | Cost |
|---|---|---|
| The video source | Virtual camera driver presenting synthetic video as a real device | Free software, minutes to set up |
| The detection logic | Patch the page, hook the library, alter the DOM | Trivial — the code is delivered to the attacker |
| The reported result | Replay or forge the request carrying the boolean | Trivial — it is an HTTP request |
The third row is the one that ends the discussion. Whatever sophistication the detection has, its output is a value in a request the client composes.
Why virtual cameras defeat the premise
Browsers request video from the operating system's media stack. A virtual camera driver registers as a capture device and supplies frames from a file, a stream or a real-time synthesis pipeline.
From the browser's position this is indistinguishable from a physical camera, because at the API level it is a camera. The frames arrive through the same interface with the same metadata.
This is not an exotic capability. Virtual camera software is standard in streaming and video production, which means the tooling is mature, free and entirely legitimate in its primary use.
Server-side analysis is better and still bounded
Sending frames to the server and analysing them there removes the patched-detector and forged-boolean problems. It is a real improvement and several vendors do it well.
What it does not remove is the injected source. The server now analyses video it received; it still has no way to establish that the video came from a physical sensor pointed at a person rather than from a driver.
The result is a probabilistic contest — detection quality versus synthesis quality — where the synthesis side improves continuously and the detector must generalise to techniques that did not exist when it was trained. That contest has a structural shape that favours the attacker over time.
The alternative: verify a signature, not a claim
Platform authenticators invert the trust relationship. The biometric never leaves the device and is never transmitted or evaluated by the server.
# Client-side liveness
client → server: { "live": true, "confidence": 0.97 }
# Server must decide whether to believe a claim from an
# untrusted client about an untrusted input.
# Platform authenticator
server → client: challenge (bound to the action)
# Secure element requires a local user-verification gesture,
# then signs. The private key never leaves the hardware.
client → server: signature + authenticator data (UV flag set)
# Server verifies the signature against a registered public key.The server is no longer reasoning about video. It is checking a signature produced by hardware it enrolled, which either verifies or does not.
What this design does not claim
Three honest limits.
- It does not prove who the person is. It proves possession of an enrolled authenticator plus a successful local user-verification gesture. Binding that authenticator to a real, identified human is a separate enrolment problem.
- It does not prevent coercion. Someone forced to unlock their device produces a valid signature. No remote mechanism solves this.
- It does not prevent enrolled-device sharing. A person who hands their unlocked device to someone else has defeated it. Attestation about authenticator type helps at the margin; it does not solve it.
These are the sort of limits that a client-side liveness vendor also has, usually without stating them.
Where identity verification still belongs
Document and biometric verification has a genuine role at enrolment: establishing, once, that this authenticator belongs to this identified person. That is a high-stakes, low-frequency event where the cost of a thorough check is justified.
The mistake is using the same mechanism for repeated authorisation, where it is high-frequency, low-margin and facing an attacker who can iterate. Verify identity carefully at enrolment; verify possession cryptographically thereafter.
What the alternative does and does not claim
| Limit | Detail |
|---|---|
| Does not prove identity | It proves possession of an enrolled credential plus a local verification gesture |
| Does not prevent coercion | Someone forced to unlock produces a valid signature |
| Does not prevent device sharing | Handing over an unlocked device defeats it |
These are the kinds of limits a client-side liveness vendor also has, usually without stating them. The difference is that the server is checking a signature rather than believing a claim about video.
Objections and honest limits
“Server-side analysis fixes it.” It removes the patched-detector and forged-boolean problems, which is a real improvement. It cannot establish that the frames came from a physical sensor rather than a driver.
“So drop identity verification entirely?” No. Use it at enrolment, where a thorough one-time check is justified. Do not use it as the repeated authorisation mechanism against an attacker who can iterate.
Where each mechanism belongs
- Identity verification at enrolment. Once, thoroughly, high stakes.
- Cryptographic possession thereafter. Repeated, cheap, unforgeable.
- Never trust a client-reported liveness boolean. It is a field in a request the client composed.
- If you must analyse video, do it server-side. And know it cannot establish sensor provenance.
Terms used here
- Virtual camera
- A software driver registering as a capture device, supplying synthetic frames through the same API as a real camera.
- Presentation attack
- Defeating a biometric check by presenting synthetic or borrowed evidence to the sensor.
- Injection attack
- Supplying synthetic frames below the application layer, so the capture path never sees a real sensor.
Frequently asked questions
Is server-side liveness analysis good enough? It is substantially better than client-side and remains a probabilistic contest against improving synthesis. It cannot establish that the frames came from a physical sensor.
Does a platform authenticator prove identity? No. It proves possession of an enrolled credential plus a local user-verification gesture. Binding that credential to a real person happens at enrolment.
What about coerced authentication? A person forced to unlock their device produces a valid signature. No remote authentication mechanism addresses coercion; it is a physical-security problem.
Should we drop identity verification entirely? No. Use it at enrolment, where a thorough one-time check is justified. Do not use it as the repeated authorisation mechanism.
Is server-side liveness good enough? It is substantially better than client-side and remains a probabilistic contest against improving synthesis. It cannot establish that frames came from a physical sensor.
Should identity verification be dropped? No. Use it at enrolment where a thorough one-time check is justified, not as the repeated authorisation mechanism.
Where this fits in Manav
Manav requires a fresh assertion bound to the specific action, from a credential under the person's sole control and verified against a published key.