Skip to content

Revert "userdb: add birthDate field to JSON user records (#40954)"#41179

Closed
paramazo wants to merge 1 commit intosystemd:mainfrom
paramazo:main
Closed

Revert "userdb: add birthDate field to JSON user records (#40954)"#41179
paramazo wants to merge 1 commit intosystemd:mainfrom
paramazo:main

Conversation

@paramazo
Copy link
Copy Markdown

@paramazo paramazo commented Mar 19, 2026

This reverts commit acb6624, reversing changes made to ba1caf0.

Revert "userdb: add birthDate field to JSON user records (#40954)"

After extensive community discussion, legal review and consideration of
privacy implications, we have decided not to implement OS-level age
attestation / age bracket signaling as initially prototyped.

Reasons for revert:

  • Privacy & freedom concerns:

    • Introducing birth date storage or age queries (even local-only) creates
      a new class of sensitive user data in the OS that didn't exist before.
    • It risks normalizing permission-like checks inside the desktop session
      and could be extended to far more invasive controls in the future.
  • Open Source philosophy mismatch:

    • Community-driven distributions (especially non-corporate ones) have
      neither the structure nor the desire to act as identity / age authorities.
    • Forcing account creation or age input breaks the "just works, no account
      required" experience that many users value in Linux.
  • Practical & enforcement issues:

    • No reliable way to enforce truthful input without invasive verification
      (which we explicitly refuse).
    • Minimal/local implementation still exposes users to website/app blocks
      if sites decide to distrust non-signaling OSes → creates a de-facto
      requirement anyway.
  • Legal / jurisdictional overreach:

    • Laws like California's AB 1043, Colorado SB 26-051 etc. appear poorly
      drafted for volunteer / decentralized projects.
    • Many distributions (MidnightBSD, Ageless Linux forks, …) already chose
      non-compliance + geo/licensing blocks instead → precedent exists to
      simply not comply rather than build half-measures.
  • No upstream consensus:

    • freedesktop.org merge request closed after pushback.
    • Major distros (Ubuntu, Fedora, …) either paused, rejected or never
      committed concrete changes.
    • systemd PR remains draft/unmerged in many views.

We may revisit if:

  • A zero-knowledge / cryptographic age-proof standard emerges that requires
    no birth date storage.
  • Courts strike down or clarify the laws to exempt small/OSS projects.
  • A truly privacy-preserving, opt-in community consensus forms.

For now: keep the system free of age-related metadata and APIs.

See-also: https://discussion.fedoraproject.org/t/california-age-verification/181968
See-also: https://blog.system76.com/post/system76-on-age-verification

@github-actions github-actions bot added documentation util-lib tests sysupdate please-review PR is ready for (re-)review by a maintainer labels Mar 19, 2026
@systemd systemd locked as too heated and limited conversation to collaborators Mar 19, 2026
@poettering
Copy link
Copy Markdown
Member

poettering commented Mar 19, 2026

It's an optional field in the userdb JSON object. It's not a policy engine, not an API for apps. We just define the field, so that it's standardized iff people want to store the date there, but it's entirely optional.

Hence, please move your discussion elsewhere, you are misunderstanding what systemd does here. It enforces zero policy, it leaves that up for other parts of the system.

And sorry, I am really not interested in these discussions here. it's not the right place for this, and please don't bring it here. Thank you.

@poettering poettering closed this Mar 19, 2026
@github-actions github-actions bot removed the please-review PR is ready for (re-)review by a maintainer label Mar 19, 2026
@systemd systemd deleted a comment from ta13579 Mar 19, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Development

Successfully merging this pull request may close these issues.

2 participants