Every few months, another state legislature drafts a bill demanding that apps and websites verify the age of their users. The proposals arrive with earnest language about protecting children. They leave behind a trail of technical contradictions, surveillance infrastructure, and collateral damage to open-source software developers who have no capacity — and no business model — to comply. But what if the entire legislative premise is wrong? What if the mechanism for age-based restrictions already exists, sitting unused inside the devices people carry every day?
That’s the argument GrapheneOS made in a post on its Mastodon instance in May 2025, and it lands with force. The privacy-focused Android-based operating system’s developers pointed out that mobile and desktop operating systems already support user profiles — including restricted profiles for children — and that parental controls at the OS level are a far more rational place to enforce age-appropriate access than inside every individual app and website on the internet.
“Platforms could simply check if the OS user profile is a child profile and restrict content accordingly,” GrapheneOS wrote. The group argued that this approach would eliminate the need for invasive identity verification, avoid the creation of centralized age databases, and keep the responsibility where it logically belongs: with device manufacturers and operating system vendors who already control the software stack.
Short version: the infrastructure is already built. Nobody in government is asking companies to use it.
Why Legislatures Keep Getting This Backward
The wave of age verification bills sweeping U.S. statehouses has been covered extensively. WebProNews reported that System76, the Linux hardware maker, publicly accused the movement of serving a dual purpose: giving Big Tech a liability shield while handing governments a surveillance mechanism. The company’s CEO, Carl Richell, warned that these bills would create “a digital checkpoint at the door of every website and app” — an outcome that would harm privacy for everyone, not just minors.
The bills vary in their specifics, but the structural logic is the same across nearly all of them. They place the burden of age verification on the application or service provider. That means every social media platform, every browser-based game, every messaging app, every forum, and — depending on the bill’s language — every piece of software that a minor could theoretically access must implement some form of age-gating. The compliance mechanism typically involves either government-issued ID verification, biometric estimation, or third-party age verification services.
Each of these methods creates a new data collection point. Each one introduces privacy risk. And each one is architecturally absurd when compared to the alternative GrapheneOS describes.
Consider what happens under the current legislative model. A 14-year-old picks up a phone. The phone’s operating system knows nothing about the user’s age, or pretends not to. The child opens an app. The app is now legally required to determine whether this user is a minor — despite having no native mechanism to do so and no prior relationship with the user. So the app asks for an ID scan, or a face scan, or routes the request through a third-party verification service that itself becomes a honeypot for sensitive personal data.
Now consider the GrapheneOS model. The parent sets up a child profile on the device at the operating system level. The OS flags that profile as belonging to a minor. Apps query the OS for the profile type and adjust content or access accordingly. No ID scan. No biometric capture. No third-party data broker. No new attack surface.
The difference is not marginal. It’s categorical.
Android already supports multiple user profiles, including restricted profiles that limit access to apps and content. Apple’s iOS offers Screen Time and Family Sharing features that allow parents to control what children can access. Windows has family safety settings. ChromeOS has supervised user accounts. The bones of this system exist on every major platform. What’s missing is a standardized API that apps can query to determine whether the current user profile belongs to a minor — and a regulatory framework that incentivizes its use.
GrapheneOS went further, noting that their own OS supports multiple user profiles with strong isolation between them, meaning a child’s profile is genuinely sandboxed from an adult’s profile on the same device. They argued that this kind of OS-level enforcement is not only more private but more effective, because it can’t be circumvented by simply lying about your age in an app’s sign-up form — the single most common workaround children already use.
This is a point that deserves emphasis. Every age verification system that relies on self-declaration at the app level — “Enter your date of birth” — is trivially defeated by any child old enough to do basic arithmetic. And the more invasive systems that require ID or biometric checks create friction and risk for adults while doing little to stop a determined teenager who borrows a parent’s phone or uses a VPN to appear as if they’re in a jurisdiction without such requirements.
The OS-level approach doesn’t have this weakness. A child using a child profile can’t simply claim to be an adult, because the profile type is set by the device administrator — typically a parent. The enforcement happens below the application layer, where the user can’t override it without the parent’s credentials.
The Open-Source Casualty Problem Hasn’t Gone Away
One of the most persistent criticisms of age verification legislation is its impact on open-source software. WebProNews detailed how California’s AB 1043 would force a surveillance mandate on every developer, including volunteer maintainers of open-source projects who have no legal team, no revenue, and no ability to implement age verification. Illinois’ SB 3977 drew similar criticism for language broad enough to capture open-source tools in its compliance net.
The problem is straightforward. A volunteer who maintains a Linux distribution or a free messaging app cannot integrate a government ID verification system. They don’t have the infrastructure. They don’t have the legal budget. And philosophically, many of them got into open-source development specifically because they believe software should respect user privacy, not undermine it.
Colorado considered an exemption for open-source software in its own age verification bill, a move WebProNews called significant. But exemptions are patches on a flawed design. If the underlying legislative architecture is wrong — if age verification is being mandated at the wrong layer of the technology stack — then exemptions just reduce the damage without fixing the cause.
The GrapheneOS argument cuts through this entirely. If age restrictions are enforced at the OS level, individual apps don’t need to implement verification at all. Open-source developers are off the hook. Commercial developers are off the hook. The only entities with new obligations are OS vendors — Apple, Google, Microsoft, and the Linux desktop environment projects — who already have the technical capacity and, in the case of the commercial players, the legal and financial resources to implement standardized child profile APIs.
This reframing also addresses the concern raised by WebProNews that Big Tech companies are quietly supporting age verification mandates because compliance costs create barriers to entry for smaller competitors. If the mandate shifts to the OS level, the compliance cost shifts to the platform vendors who already dominate the market. Smaller app developers and open-source projects are no longer forced to build surveillance infrastructure they can’t afford and don’t want.
There’s a political dimension here too. The age verification movement has attracted support from both parties — conservatives who want to restrict children’s access to explicit content, and progressives who want to hold tech companies accountable for harms to minors. But neither camp has seriously engaged with the technical reality that the app-level approach is both less effective and more invasive than the OS-level alternative. The legislative debate has been captured by a model that serves the interests of identity verification companies and large platforms while imposing costs on everyone else.
And the identity verification industry is not a neutral party. Companies like Yoti, Jumio, and Clear have a direct financial interest in laws that mandate their services. When every app and website in the country needs an age verification provider, those companies stand to gain enormously. The OS-level model threatens that business entirely, which may explain why it hasn’t gained traction in legislative discussions despite being technically superior.
California’s 2027 deadline for compliance under its age verification mandate is approaching, and developers across the state — and across the country, given California’s outsized regulatory influence — are beginning to grapple with what compliance actually looks like. For many, it looks expensive, invasive, and technically dubious. For open-source projects, it looks impossible.
GrapheneOS isn’t the first to suggest that parental controls belong at the device level rather than the application level. But the project’s credibility on security and privacy issues gives the argument unusual weight. This is a team that has built an entire operating system around the principle that users should control their own data. When they say the current legislative approach is architecturally wrong, it’s not a lobbying position. It’s an engineering assessment.
The question is whether any legislature is listening. So far, the evidence is not encouraging. California’s AB 1043 sparked a firestorm among developers and privacy advocates, but the bill advanced anyway. Illinois and other states have followed similar paths. The political incentive to “do something” about children’s online safety is powerful, and the technical nuances of where age verification should be implemented don’t make for compelling campaign ads.
But the technical nuances matter. They determine whether the resulting system actually protects children or merely creates the appearance of protection while building a surveillance apparatus that tracks every adult’s online activity. They determine whether open-source software can survive in a regulatory environment designed around commercial assumptions. And they determine whether the internet remains a space where small developers and independent projects can operate without a compliance department.
What Would an OS-Level Standard Actually Look Like?
If policymakers took the GrapheneOS argument seriously, the practical implementation would require coordination between OS vendors and app developers on a standardized API. The concept is not complicated. The OS maintains a profile type — adult, child, or teen — set by the device owner or administrator. Apps query this profile type through a system-level API. Based on the response, the app adjusts its content, features, or access restrictions.
No personal data leaves the device. No identity documents are scanned. No biometric templates are stored on remote servers. The age determination is made once, at device setup, by the person who actually has authority over the child: the parent.
There are legitimate questions about edge cases. What about shared devices without multiple profiles? What about children who use devices not set up by their parents? What about desktop Linux distributions where the concept of a managed child profile is less mature? These are real engineering problems, but they’re solvable engineering problems — and they’re far less severe than the problems created by the current app-level mandate approach.
Google and Apple could implement a standardized child profile API within a single OS update cycle. Microsoft could do the same for Windows. The Linux community would need more time, but projects like GNOME and KDE already have parental control features in various stages of development. A regulatory mandate aimed at OS vendors — requiring them to offer standardized child profile functionality and a queryable API — would be narrower, more effective, and less invasive than the current crop of bills that attempt to deputize every app developer as an age verification checkpoint.
The irony of the current situation is thick. Governments are demanding that thousands of individual software developers each build their own age verification systems — a fragmented, inconsistent, privacy-destroying approach — when a handful of OS vendors could solve the problem centrally with a single standardized feature. It’s like requiring every store in a mall to individually verify the age of every customer, when the mall itself could simply check IDs at the entrance.
Except even that analogy is too generous to the current approach, because the OS-level model doesn’t require ID checks at all. It requires parental configuration. The parent decides. The OS enforces. The app respects the OS’s determination. Done.
Whether this argument breaks through the legislative noise remains to be seen. The age verification industry has lobbyists. Open-source developers and privacy-focused OS projects generally do not. But the technical case is strong, and it’s getting harder to ignore as the practical consequences of app-level mandates become clearer. States like California are on a collision course with technical reality, and projects like GrapheneOS are making sure the collision is well-documented.
The children these laws claim to protect deserve better than security theater. They deserve systems that actually work — and that don’t require every adult in the country to hand over their identity papers to use the internet.
WebProNews is an iEntry Publication