← All notes

OS-level age verification: the law, the plumbing, and how to switch it off

July 10, 20264 min read

In July 2026 a federal complaint was unsealed (United States v. Peter Stokes, N.D. Ill.) showing something many suspected and few had seen in writing: Microsoft handed the FBI telemetry tied to the GDID — a unique identifier Windows assigns to every install — and with it they tracked a suspect across VPNs, proxies and three countries, arresting him as he boarded a flight in Helsinki. The lesson isn't about that case: it's that an identity channel at the operating-system level defeats any network-level anonymity. Your VPN encrypts traffic; it can do nothing if the OS underneath reports on its own.

With that lesson fresh, now look at what's being legislated.

The laws

  • H.R. 8250 (US federal — not yet passed by either chamber): would require every operating system provider to verify user age — with government ID or biometrics — and expose that data to applications through APIs. The text doesn't distinguish between Windows and a volunteer-run Linux distro; fines of $7,500 for noncompliance have been reported.
  • Colorado SB26-051 (introduced January 2026): a state framework for "age attestation" on computing devices — the OS hands apps a standardized signal with the user's age bracket.
  • California AB 1043 and Brazil Lei 15.211 (in force since March 17, 2026): the same wave, already live. Community projects started geo-blocking downloads from California and Brazil that very day as "preventive compliance" — a volunteer project with no user database has no other way to "comply".

The plumbing already exists

This is not hypothetical. The infrastructure is being built now, in software you're probably running:

  • systemd merged a birthDate field into its JSON user records in March 2026 (PR #40954). Exact date of birth — not brackets — readable by any process querying userdb, writable by administrators via homectl.
  • It coordinates with AccountsService (MR #176) and xdg-desktop-portal (PR #1922), with a D-Bus spec on the way: org.freedesktop.AgeVerification1.
  • MidnightBSD already shipped the whole thing: an aged(8) daemon, its agectl(8) CLI, the agev(3) library, and Unix groups per age bracket to gate packages. Footnote: the function that reads the age bracket parses 4 of its 5 response types incorrectly. That's how well this starts.
  • Whonix forum users called it what it is: "a new fingerprinting mechanism: age bracket". One more bit that tells you apart from everyone else.

The community's answer

  • Ageless Linux — the distro born from this: Debian stable base, no package that includes telemetry or age hooks, plus documentation for dismantling age-reporting infrastructure on other systems. They maintain a per-distro compliance tracker.
  • Liberated systemd — a systemd fork that reverts the birthDate field and stays in sync with upstream for everything else. There's an AUR package.
  • Artix refused outright, and holds the most elegant position: by not using systemd it's structurally immune — there's no userdb to store the field in.
  • Parrot OS: "we will do absolutely nothing to accommodate these restrictions until we are legally forced to". Zorin OS: it will not be implemented under any circumstances. Ubuntu, Fedora and Mint are still "discussing it".

What I did on my machine

I run Arch (CachyOS) with systemd 261 — the field already lives on my system. My answer was to pin the data layer to null before anything can write it, with a static user record:

// /etc/userdb/milo.user  (root:root 644)
{
  "userName": "milo",
  "uid": 1000,
  "birthDate": null
}

ln -s milo.user /etc/userdb/1000.user   # uid queries hit the same record
userdbctl user milo --json=pretty | grep birthDate
# "birthDate" : null

Why it works: records under /etc/userdb/ are served directly by the userdb multiplexer. Any process asking about my user gets an explicit birthDate: null, defined in a file only root can touch — not an empty field some future "set up your account" flow can fill in later. The symlink covers uid-based queries. The API layer (the AgeVerification portal) hasn't even landed on Arch; when it does, it already knows what answer it will find.

Is this immunity? No. It's a pin on the data layer of my install, for as long as the field lives upstream. The structural exit is not having systemd at all — which is exactly one of the reasons I'm moving to runit. While the federal bill remains unpassed, this is the window to decide how much of your identity your init system gets to know.

Sources: H.R. 8250 — age verification in every OS · Colorado SB26-051 · How distros are responding to age verification laws · Ageless Linux — compliance tracker · Per-distro age-reporting documentation · The GDID / Scattered Spider case · Ubuntu, Fedora and Mint eye age verification