The submitter surfaced research showing the SDK transmits facial photos and a persistent device fingerprint to third-party servers, despite Yoti's longstanding 'on-device estimation' marketing. The gap between what regulators, parents, and integrating sites' privacy policies described and what the SDK actually does is the core deception.
Argues that Yoti's transmission-vs-storage distinction is a defensible engineering choice but not what was communicated to users or integrating sites. The persistent device fingerprint surviving cookie clearing is particularly damning given the privacy-preserving framing.
Yoti distinguishes transmission from storage: images travel over TLS to a server so the age estimation model can run, then are deleted within a defined retention window. From an engineering standpoint, this is a normal architecture and the deletion policy preserves the privacy outcome users care about.
The UK Online Safety Act, EU age-assurance pilots, Australia's under-16 ban, and California's AB 1043 have spawned a multi-hundred-million-dollar market that forces sites to ship biometric capture to every visitor. Even when individual vendors behave well, the aggregate effect is mass collection of facial data and device fingerprints across the open web.
Researchers analyzing Yoti's widely deployed age verification SDK — the same one being rolled into UK Online Safety Act compliance flows, California's AB 1043 implementations, and a growing list of EU age-assurance pilots — found that the system transmits facial photographs and device fingerprints to third-party servers during what is marketed as an on-device, privacy-preserving check. The findings, published this week and surfacing on Hacker News with 145 points and a heated comment thread, directly contradict the vendor's longstanding positioning that its facial age estimation runs locally and discards images immediately.
According to the analysis, the SDK initiates outbound HTTPS calls carrying the user's selfie payload and a stable device identifier to endpoints not disclosed in the integrating site's privacy notice. The device fingerprint includes a combination of hardware attributes, browser canvas hashes, and a persistent identifier that survives cookie clearing. The researchers note that the photographs are sent over TLS but are nevertheless leaving the user's device — a meaningful distinction from Yoti's own marketing language, which has repeatedly emphasized "on-device estimation" and "images are not stored."
Yoti's response, paraphrased in the source reporting, draws a line between *transmission* and *storage*: the images go to a server for the model to run, but are deleted within a defined retention window. That's a defensible engineering choice. It is not, however, what the average regulator, parent, or end user understood from the marketing. And it is not what the site operators integrating the SDK were telling their own users in their privacy policies.
Age verification is the new compliance landgrab. The UK's Online Safety Act, the EU's age-assurance pilots, Australia's social media ban for under-16s, and California's AB 1043 have collectively created a multi-hundred-million-dollar market for "prove your user is over X" SDKs almost overnight. Yoti, Persona, Incode, Veriff, and a half-dozen others are scrambling to win integrations at adult sites, social platforms, alcohol retailers, and — soon — anyone hosting an LLM with even mildly spicy outputs.
The entire pitch of this market segment is "we take the privacy hit so you don't have to." Site operators don't want to be the data controller for a database of selfies tied to porn-viewing habits. Regulators don't want to mandate something that creates a new honeypot. The vendors stepped into that gap promising minimal-disclosure, on-device, ephemeral checks. That promise is doing enormous policy work — it's the load-bearing assumption behind every age-check law currently on the books or in markup.
If the load-bearing assumption is wrong, the entire regulatory edifice is wrong. A facial photograph plus a persistent device fingerprint, transmitted to a third party, is a textbook privacy hazard. It's the exact pattern the GDPR's Article 9 (special categories of personal data) was written to constrain. The UK ICO has been clear that biometric data used for identification triggers heightened obligations regardless of retention. A 30-day retention window does not make this category-of-data problem disappear; it just shortens it.
The community reaction on Hacker News is sharp and not particularly surprised. Top comments cluster around three themes: (1) the inevitability of this gap between marketing claims and engineering reality in any compliance-driven SDK market; (2) the structural problem that no site operator has the budget or expertise to audit every vendor's network behavior, so they take the data sheet at face value; and (3) genuine technical curiosity about why the inference is server-side at all — modern smartphones can run facial age estimation models locally in hundreds of milliseconds, and the vendor likely chose server-side for model-update agility and to keep proprietary weights off-device.
That last point is the real story. The economics of MLOps quietly drove a privacy-preserving product into being a privacy-leaking one, and the marketing never caught up. Keeping the model server-side lets Yoti retrain weekly, A/B test thresholds, and prevent reverse engineering. Those are real engineering wins. They are also, in aggregate, why the on-device promise was always slightly fictional.
If you're integrating an age-verification vendor — and if you ship anything user-facing in the UK, EU, Australia, or California, you probably will be in the next 18 months — three things just got more expensive.
First, vendor diligence is now your job, not your lawyer's. Spin up the SDK in a test harness, point it at mitmproxy or Charles, and document every outbound request. Compare the destinations to what's listed in the vendor's DPA and your own privacy policy. If the network trace doesn't match the data sheet, you are the data controller for whatever leaks — not the vendor. Plan a half-day of engineering time per vendor evaluation and budget for re-auditing on every SDK version bump.
Second, your privacy policy needs to name the sub-processor explicitly and describe what's transmitted, not what's stored. The standard language — "we use a third-party age verification service" — is no longer defensible if that service is shipping selfies to its own infrastructure. Get a Records of Processing Activities entry that lists the actual data categories in transit. Your DPO will not be happy, but they will be less unhappy than they'd be after a regulator's inquiry.
Third, consider whether a non-biometric path satisfies your compliance obligation. Credit card checks, government ID verification with on-device OCR, and inference-from-account-age all have their own privacy tradeoffs, but they don't require transmitting a facial photograph anywhere. The UK's age assurance code explicitly allows risk-based approaches; you do not have to use facial estimation. Several vendors offer it because it has the lowest friction, not because it's the most privacy-preserving option available.
Expect at least one EU data protection authority to open a formal inquiry within 90 days — the German and French regulators have been particularly aggressive on biometric processing without explicit consent, and this story has the kind of clean fact pattern they like to make examples of. Expect Yoti and its competitors to quietly ship SDK updates that move more inference on-device, accompanied by carefully worded blog posts about "continued investment in privacy." And expect the next round of age-verification laws — there are bills in markup in at least four U.S. states — to start specifying *how* verification must work, not just *that* it must happen. The black-box vendor era of age assurance is closing. The audited, specified, on-device era is what's coming, and it will be more expensive and more honest.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.