Age verification on Systemd and Flatpak
Operating-system level “age verification” features being added to systemd, Flatpak and other Linux components—partly to comply with California’s AB1043 and similar laws—are raising alarms about privacy, anonymity, and centralization. Commenters distinguish between local, parent-controlled age indication and true online age verification, but many fear any standardized age API will become a tracking vector and a foundation for broader identity mandates. There is also concern that tying applications like browsers to systemd-only age APIs will marginalize non-systemd Linux and *BSD systems, effectively giving governments and large vendors new leverage over open platforms.
Scope of the change and why now
- systemd has added a field to store user date of birth and a way for apps to query an age/age range; some see this as minor plumbing, others as a major shift.
- Several commenters ask why this is being implemented now, linking it to recent age‑assurance laws rather than intrinsic technical need.
- Some argue open source generally accepts features when someone contributes them, especially when corporate users need regulatory compliance.
Legislative drivers (mainly California AB1043)
- Described behavior: OS must ask for age/DOB, trust user input; apps must query the OS for an age range (<13, 13–15, 16–17, 18+).
- The law does not require browsers to send age to websites, but knowing age can create “actual knowledge” obligations under other child‑protection rules.
- Some see this as a “cheap” political compromise that avoids ID uploads and face scans; others see it as step one toward more invasive schemes.
Privacy, tracking, and “age indication” vs “verification”
- Strong concern that any standardized age field becomes another fingerprinting/tracking vector, even if falsifiable and only a range.
- Distinction raised between:
- “Age indication”: local, offline DOB stored on device, parent‑set, apps see only bracket.
- “Age verification/assurance”: ID checks, biometrics, inferences via third parties.
- Many fear indication will normalize OS‑level prompts and pave the way to hard verification and broader data sharing.
Systemd, lock‑in, and non‑Linux concerns
- Worry that major apps (e.g., browsers) will eventually rely on a systemd age API, marginalizing *BSD and non‑systemd distros.
- Some argue the answer is to avoid systemd now; others dismiss the feature as trivial compared to existing systemd integration.
- A few predict that if key software hard‑requires such APIs, critics of systemd “lock‑in” will be vindicated.
Parenting, platforms, and alternative designs
- Several argue responsibility should lie with parents and OS‑level tools (install locks, firewalls, content filters), not universal age signals to apps.
- Alternative model proposed: services advertise their own age rating; the OS enforces locally, without exposing user age outward.
- Others counter that apps need age to tailor content lists or comply with law; if OS doesn’t provide it, apps will roll their own.
Broader fears: end of anonymity and regulatory creep
- Many see OS‑level age APIs as part of a longer arc toward removing online anonymity, tying devices and browsers to verified identities, TPMs, and web attestation.
- Comparisons are made to crypto wars, accessibility/privacy mandates, and “do something” moral panics around social media harms to children.
- Some view the current implementation as mostly harmless; others argue even harmless‑seeming metadata mandates shift the Overton window and should be resisted.