The site's author reframes facial recognition as a credential-management failure rather than a privacy debate. Faces are derived from permanent physical features, cannot be rotated like passwords, and data subjects have no read or delete access to the template databases being built by airports, retailers, schools, and consumer apps.
Endorses the site's rhetorical move as 'the right one' — treating a face as a primary key you cannot rotate exposes why every engineering instinct around credential breaches breaks down here. The entire architecture of modern auth assumes burnable, revocable tokens, which biometrics fundamentally are not.
A recurring wave of commenters argue that with Clearview AI's 50-billion-image corpus, PimEyes' $30/month reverse search, and ubiquitous CCTV, individual opt-out is theater. Their face is already in a dozen databases, so adding one more changes nothing meaningful.
A counter-wave points to Illinois' Biometric Information Privacy Act settlements and GDPR Article 9's special-category protections as proof that legal frameworks can claw back biometric data. Individual avoidance is a coping mechanism; statutory consent regimes and class-action damages are what actually reshape vendor behavior.
A smaller, sharper thread of working engineers argues that the rollout pace — CBP biometric exit at most major US international airports, TSA domestic kiosks expanding faster than GAO audits, Clearview's scraped corpus — has already outpaced both lawsuits and personal opt-out strategies. The infrastructure is being built faster than either lever can respond.
A single-page site, nevergivethemyourface.com, hit 542 points on Hacker News this week with a thesis that fits on a business card: don't let anyone scan your face if you can possibly avoid it. The site's author lays out the case in plain language — airports, stadiums, retail loss-prevention systems, school pickup lanes, gym entry kiosks, and an expanding catalog of consumer apps are all quietly building face-template databases that you, the data subject, have no read access to and no delete button for.
The comment thread mirrored a pattern that's become familiar on HN whenever biometrics surface: a wave of pragmatic defeatism ("my face is already in a dozen places"), a counter-wave of regulatory optimism (BIPA, GDPR Article 9, Illinois settlements), and a smaller, sharper thread of working engineers pointing out that the technical reality has already overtaken both. Clearview AI's scraped corpus crossed 50 billion images last year. PimEyes will reverse-search any face against the open web for $30/month. The CBP biometric exit program now covers most major US international airports, and TSA's facial-matching kiosks are rolling out to domestic checkpoints faster than the GAO can audit them.
The site's core move is rhetorical, but it's the right rhetorical move: it reframes "facial recognition" from a privacy debate into a credential-management problem. Your face, in this framing, isn't a privacy attribute — it's a primary key. And it's a primary key you cannot rotate.
Every engineer who has ever responded to a password-database breach understands the rotation problem intuitively. Customer hashes leak, you force a reset, users grumble, the system heals. The reason that loop works is that passwords are arbitrary tokens — replaceable, revocable, scoped per service. The entire architecture of modern auth assumes you can burn a credential and mint a new one.
A face template is the opposite. It's derived from a permanent physical feature, it's broadly recognizable across vendors (the embeddings differ but the underlying invariants don't), and once it's enrolled in System A, any future System B that scans you in a coffee shop can match the new capture against the old enrollment with nothing more than a vector similarity check. There is no "rotate face" endpoint. There is no breach-notification email that helps. The blast radius of a single enrollment extends forward in time indefinitely, across every operator who later acquires the template, the database, or the model weights trained on it.
This is the part the privacy debate keeps fumbling. GDPR Article 9 treats biometric data as a special category, which is correct but insufficient — the regulation imagines biometrics as something a controller holds and might mishandle, with the remedy being deletion. Deletion from one controller doesn't help when the same template lives in fourteen others, three of which scraped you without consent and one of which is a foreign state actor. The correct mental model isn't "my face is in a database." It's "my face is a leaked password that I cannot change, and every new scanner is a new login attempt against the leak."
The HN thread surfaced a few empirical anchors worth holding onto. Facial recognition accuracy on standard benchmarks (NIST FRVT) is now well past 99.5% for cooperative captures, and the gap between vendor systems has collapsed — meaning the era when "different vendors won't match each other" is gone. Template inversion attacks (reconstructing recognizable face images from stored embeddings) have moved from academic curiosity to demonstrated capability; a 2024 paper from researchers at the University of Maryland showed reconstruction quality sufficient to fool a separate FR system at >70% rates. The "it's just a hash" defense is dead.
Meanwhile, the offense keeps compounding. Apple's Vision Pro and Meta's Ray-Ban smartglasses are normalizing always-on face capture in public space. The Clearview-style scraper model has been copied by smaller, less scrupulous operators across at least a dozen jurisdictions. Stadium operators are signing multi-year contracts with FR vendors for ticketless entry. The infrastructure is being built faster than the legal frameworks that might constrain it, and the templates being enrolled today will outlive the regulatory regimes drafted to govern them.
If you ship software that touches biometrics, the editorial line on this site translates directly to a few engineering positions worth taking. Default to on-device matching. If you must enroll a face for a feature — unlock, KYC, age-gate — keep the template on the user's device, never round-trip it to your servers, and never persist it server-side even temporarily. Apple's Secure Enclave model is the reference architecture; copy it. The moment a template lands in your S3 bucket, you own a liability that no amount of encryption-at-rest meaningfully reduces, because the threat model is not "someone steals my bucket" — it's "my company gets acquired in five years and the new owner monetizes the templates."
Treat "face login" as a feature you should talk users out of. The UX win is real and the security loss is permanent. If your product offers face unlock as one of several options, instrument the consent flow honestly — tell users their face template will be stored in [these specific places], retained for [this duration], shared with [these processors], and cannot be rotated if compromised. Watch the adoption rate drop. That drop is the correct signal.
Audit your vendors' data practices, not their marketing. Most FR SDKs (AWS Rekognition, Azure Face, the smaller ones) have data-residency and retention controls that are off by default. Verify, in code, that you're not silently uploading face crops to a vendor's training pipeline. The Clearview consent decree last year specifically prohibited future scraping of non-consenting individuals; that prohibition is only as good as the audit log you keep when you call someone else's API.
The brutal honesty of nevergivethemyourface.com is that the leak has already happened for most people reading this — your face is in Clearview, your face is on LinkedIn, your face is in a stadium FR database from a concert you went to in 2022. The site isn't pretending the situation is recoverable. It's arguing that the *marginal* enrollment still matters, because every new scanner you avoid is one fewer operator with a fresh, high-quality template tied to a specific timestamped location. That argument generalizes: the engineering response isn't to fix biometric auth, it's to stop building systems that demand it. The credential you can't rotate is the credential you shouldn't be collecting.
It ends with "The platforms need you far more than you need them". And I think this is the misconception. No, they don't. The amount of people who will sign this, is a fraction of a fraction of a "platform"'s users. They will not care if they lose 50,000 users out of 2
This is a little bit of a tangent compared to the post, but can someone explain to me why it's NOW that we have multiple countries (USA, Canada, UK, Australia, and probably others that I am not aware of) all looking at age verification for a technology (the internet and all the things it lets y
Can't we even write a short text like this without LLMs anymore, not even when it's really important, when it's about humans against the inhumane?
> They are built to know who you are: your name, your date of birth, your document number, your face. This is not age verification at all. It is forced identity tracking.This doesn't have to be the case. https://www.w3.org/TR/digital-credentials/ seems a sensible sys
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I quit facebook over a decade ago. Then, a few months back, I was under some pressure to sell something, and the facebook marketplace appears to be the way to go locally. So I tried to create a facebook account.They wanted to scan my face, and in a moment of weakness, I performed the ritual. Thirty