By ByteBot
On June 26, 2026, a thread on Hacker News titled “The ‘papers, please’ era of the internet will decimate your privacy” hit 784 points and 358 comments — one of the most engaged developer conversations this week. It wasn’t idle debate. Google Play’s Age Signals API started returning live age data for Texas users on May 28. Brazil went live in March. Australia moved from monitoring to active enforcement on March 31, with formal investigations now underway against Facebook, Instagram, Snapchat, TikTok, and YouTube. If you ship software that reaches consumers, this is already your compliance problem.
The Compliance Clock Is Already Running
Age verification laws have moved faster than most developers realize. Texas’s SB2420 went live January 1, 2026. Google’s Play Age Signals API followed with Texas coverage on May 28, 2026 — meaning your Android app may already be receiving age signals for users who created accounts after that date, whether you’ve handled them or not. Utah and Louisiana are next. Brazil has been active since March 17 via Google Play. The EFF published a major global analysis this week cataloguing laws in Australia, UK, Indonesia, Malaysia, and Brazil, calling the collective shift a “growing global threat” to privacy.
Australia’s model is the most demanding. Platforms aren’t just required to gate account creation — they must implement continuous behavioral monitoring, detect circumvention attempts including VPN use, and maintain an ongoing compliance posture. The eSafety Commissioner expects “successive validation,” not a single checkbox at signup. Five major platforms are currently under formal enforcement investigation. Fines reach $49.5M AUD per platform.
The developer action here is straightforward: audit which jurisdictions your users are in and check your Google Play integration. If you’re reaching Texas, Brazil, Utah, or Louisiana users on Android and haven’t integrated the Age Signals API, you’re non-compliant today.
What You’re Allowed to Do With Age Data (And What’s Forbidden)
Google’s Age Signals API comes with usage restrictions that are stricter than most developers expect. You may only use age signals to deliver age-appropriate content and experiences in compliance with applicable laws. The following are explicitly prohibited: advertising targeting, marketing personalization, user profiling, and analytics. Violation means API access termination and app suspension from Google Play.
Integration requires adding the dependency to your build.gradle:
implementation 'com.google.android.play:age-signals:0.0.3'
The API supports devices running Android 6.0 (API level 23) and higher, returning age ranges of 0–12, 13–15, 16–17, and 18+. The critical rule: query the API in real time, make your content decision, and discard the result. Do not store age signal data. It must never touch your analytics pipeline or ad targeting system. Keep the compliance logic architecturally isolated from everything else in your stack.
The Third-Party Vendor Trap
Many developers will reach for a third-party age verification vendor as the path of least resistance. This is the wrong call. The EFF’s analysis identifies leading vendors as collecting facial photos, device fingerprints, and government-issued IDs — then sharing that data with third parties. These are what the EFF calls “single points of failure”: centralized databases of the most sensitive user data that exist, sitting in the systems of companies most of your users have never heard of.
Contracting with a vendor doesn’t transfer your GDPR or CCPA liability if they breach your users’ biometric data. You are still on the hook. The correct architecture is to use platform-native APIs — Google Play Age Signals for Android, Apple’s equivalent for iOS — which handle verification without your app ever touching a government ID or facial scan. This isn’t just the privacy-respecting choice; it’s the liability-limiting one.
Related: LastPass Data Breach 2026: Klue OAuth Attack Hits 8 Firms
Why It Mostly Won’t Work — And What Comes Next
The technical case against mandatory age verification is airtight. Research shows most websites that implement age verification don’t actually enforce it. UK VPN adoption surged measurably after the Online Safety Act took effect — users bypass, they don’t comply. The Hacker News community identified what’s now called the “homeless problem”: anonymous age tokens are trivially redistributable, making any credential-based system easy to share around. The EFF’s verdict is blunt: “there isn’t one” viable age verification method that achieves effectiveness, privacy, and practicality simultaneously.
The technically sound long-term path is zero-knowledge proofs. Google has already integrated ZKP age verification into Google Wallet, with Bumble as the launch partner. ZKPs can prove “user is 18+” without revealing identity or storing biometrics anywhere. The EU Digital Identity Wallet is building interoperable ZKP age verification for the bloc. However, ZKPs still require a government-issued root identity document — you’re not eliminating identity verification, just moving it to a government system rather than a private vendor. That’s a meaningful improvement, but it doesn’t solve the underlying surveillance architecture problem.
Key Takeaways
- Google Play Age Signals API is live in Texas (May 28, 2026) and Brazil (March 17, 2026); Utah and Louisiana follow. Audit your Android app’s compliance status now.
- Age signal data is strictly firewalled: no advertising, no profiling, no analytics. Architectural isolation from your normal data pipeline is mandatory, not optional.
- Avoid third-party biometric vendors entirely. Platform-native APIs handle verification without you ever storing sensitive identity data — and eliminate a major liability vector.
- Age verification demonstrably drives VPN adoption, not compliance. The laws are real; the effectiveness is not. Build for compliance without pretending it solves the underlying problem.
- Zero-knowledge proofs are the right long-term architecture. Watch Google Wallet ZKP integration and the EU Digital Identity Wallet for where this standard is heading.
