Ubuntu’s earlier public statement said there were no concrete plans on how, or even whether, Ubuntu would change in response to California AB 1043, and that the mailing-list discussion was informal. That was reassuring at the time. But there are now active patches and integration work in the open, and that changes the situation materially. (Ubuntu Community Hub)
So this needs to be stated clearly and without ambiguity:
Ubuntu must not implement OS-level age verification, age signaling, age-bracket APIs, or any equivalent mechanism in any form.
Not in the installer.
Not in provisioning.
Not in AccountsService.
Not through systemd userdb.
Not through xdg-desktop-portal.
Not as a “minimal” age bracket.
Not as a future token.
Not as a jurisdiction-specific compromise.
Not as a temporary measure.
Not at all.
The most serious mistake here is not a particular choice of daemon, D-Bus interface, storage format, or packaging strategy. The mistake is accepting the premise that Ubuntu should be discussing how to build an OS-level surveillance and control apparatus, an authoritarian surveillance mechanism disguised as “age verification” or “age signaling”, into a general-purpose free operating system at all.
It should not.
What is being proposed is not a normal compliance feature. It is an attempt to insert a standardized user-classification and disclosure mechanism into the operating system layer for third-party applications and services, under legal pressure and under an emotional pretext. That has no place in Ubuntu.
The “age bracket only” framing does not solve the real problem. An OS-level age signal is still an OS-level identity attribute. Once exposed through a standard API, it becomes a fingerprinting primitive, a gating mechanism, and a compliance wedge for future expansion. The issue is not merely how many bits are disclosed. The issue is that the operating system is being pushed into the role of a policy-enforcement endpoint.
That should be rejected outright.
And this is no longer hypothetical. The implementation path is visible:
- Ubuntu desktop provisioning PR #1338 adds a required
birthDatefield to user provisioning, says the form cannot be submitted without it, and explicitly depends on AccountsService, systemd PR #40954, and xdg-desktop-portal PR #1922. (GitHub) - Ubuntu desktop provisioning PR #1339 writes
BirthDateinto the target AccountsService keyfile. (GitHub) - systemd PR #40954 adds
birthDateto JSON user records specifically for age-verification laws. (GitHub) - systemd issue #40974 is already discussing
ageGroupas an alternative, which does not solve the problem, but repackages it. (GitHub) - xdg-desktop-portal PR #1922 is where an app-facing portal/API is being normalized. (GitHub)
- Archinstall PR #4290 shows the same direction at installer level elsewhere, by writing
birthDateinto/etc/userdb/<user>.user. (GitHub)
This is exactly why people are alarmed. Once the discussion shifts from “should this exist at all?” to “where should it live?” or “which component should store it?”, too much has already been conceded. The question becomes how to package the mechanism, rather than whether Ubuntu should reject it on principle.
Ubuntu should reject it on principle.
This is also not an isolated issue. It is part of a broader pattern in which child-safety rhetoric is used to create urgency, apply emotional pressure, and normalize technical mechanisms for inspection, classification, and access that would otherwise be unacceptable. That is not sound policy-making. It is coercive framing. Ubuntu should not help launder that into ordinary platform infrastructure. (GitHub)
There is another important point here: refusal must not take the form of geo-fencing users out of free software either. Ubuntu must remain accessible to everyone. A free operating system should not be turned into a territorially fragmented compliance product, and users should not be abandoned because of where they live.
So I am asking for a clear public commitment:
Ubuntu should state that it will not implement, ship, standardize, modularize, or otherwise facilitate OS-level age verification or age signaling in any Ubuntu component.
And because this is now spread across multiple layers, we need a clear record of every relevant change under discussion so that the community can track them closely and, if necessary later, revert them one by one:
- Ubuntu desktop provisioning PR #1338
- Ubuntu desktop provisioning PR #1339
- systemd PR #40954
- systemd issue #40974
- xdg-desktop-portal PR #1922
- Archinstall PR #4290
- AccountsService MR !176, as referenced by the Ubuntu and systemd work (GitHub)
This should stop now, before one more line is normalized.
Debian and Ubuntu must also be prepared to remove these changes downstream if upstream merges them. Refusal cannot stop at “we did not author the patch ourselves.” If upstream projects ship this machinery, Debian and Ubuntu should strip it from their packages. And if they do not, I will do that work myself.
I also want to be explicit about where my own red line is. If Ubuntu or Debian crosses it and begins implementing any of this, whether directly or by quietly inheriting it from upstream, I will treat that as a matter of principle, protest, and basic decency. I will support, build, or help lead a fork with this functionality removed. That is not a threat or an ultimatum. It is simply the consequence of refusing to collaborate in the construction of this kind of apparatus.
Ubuntu should refuse this absolutely.