Age verification on Systemd and Flatpak

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.