userdb: add birthDate field to JSON user records by dylanmtaylor · Pull Request #40954 · systemd/systemd
github.com
Stores the user's birth date for age verification, as required by recent laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc. The xdg-desktop-portal project is addi...

Fork time? Maybe all the anti-systemd zealots were right all along…

Edit: To address whether it is likely that this change will affect users: Gnome is planning a stronger dependence on userdb, the part of systemd where this change is being implemented. https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/

Final Edit: The PR has been merged into main.

  • balsoft@lemmy.ml
    1017·
    3 days ago

    This seems to be an opt-in, user-supplied field that apps can use to implement parental controls easier. If you’re gonna do birth dates at all, this is the way.

    But IMO it should be more granular: there should be fields for WWW access, social media access, sex/nudity/violent content, and apps should respect those individually. Then parents can choose what is appropriate for their child at their development level.

    • Oinks@lemmy.blahaj.zone
      2·
      2 days ago

      In the xdg-desktop-portal PR there is a very interesting discussion about how OS level parental controls probably should work:

      The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.

      gnome-software, AppStream and malcontent use the OARS ratings system for tagging content with what might be age-restricted about it. This has a mapping to a CSM age (which is international), and that has mappings to most countries’ national ratings systems, and is designed for web content as well as games and films.

      Presumably an app would send a list of specific OARS tags (which exist for precisely this purpose) to the OS via xdg-desktop-portal, and the OS would respond by classifying each tag as acceptable or unacceptable. The app then is only responsible for not displaying the unacceptable content, and tweaks to the filters based on jurisdiction and new laws/amendments happens in a clearly defined place which is the portal implementation (which could be in an optional package, e.g. xdg-desktop-portal-content-controls).

      Of course that system wouldn’t comply with any of these new laws because they’re just bad. Even ignoring all technical considerations, most of them have a ridiculously broad scope (or large uncertainties). They’re very poor legislative work.