RIP most Linux distros
It is optional.
1 Like
What do you all think of Lennert Potteringâs statement on this?
if people run apps unsandboxed these apps get access to any file in $HOME and a tonload more stuff of the system. And that data is a lot more valuable than the birthday is. Hence, letâs maybe not waste discussion around isolating apps from that single piece of information that is the birthday, while leaving everything else wide open.
The answer to the PII issues is hence not restrictions in userdb, the answer is proper app sandboxing. And that even already exists in flatpak! It restricts access to $HOME already, and to userdb too! And thatâs the way to do it!
Hence, just embrace app sandboxing! And if you come to me and say âhey, I run all my apps without sandboxing, but i want the birthday hidden anywayâ then I can only say, your model is really really broken. Fix your security model first, then come back.
So, I think userdb should reveal the birthday to per-user code, because that per-user code then can consume this and provide a portal or something to properly sandboxed apps that provides a more restrictive api, i.e. age brackets and so on. But that kind of stuff is outside of the scope of systemd, here in systemd we just provide you with a way to maintain the original data, the precise policy enforcement on it must happen in the sandbox.
This makes sense to me in some respects, but is a reductive hackers way of looking at things I guess. Because we understand the models he is basically saying that average users who will be exploited by these laws (most noteably children) arenât a concern and itâs on them or maybe assumes that will magically happen from some portion of the Linux community teaches them.
I do find it tempting to hand wave away the concerns of how this mainly applies to less technical users, but that is kind of what we did towards DMCA laws and its still very illegal to copy some files where all this resulted in were digital archivist undergrounds and businesses + terrible policy like this rode the enshittification wave and participated in their own surveillance through analyzing our psychology through unconsenting algorithms.
If we donât care about this now, it still affects us. One largely different thing from the DMCA laws is the awareness the public has about these exploitations and enshittification that acts as a motivator that sparks the public to listen to what activists have argued for years.
7 Likes
I donât see this as a big deal. As long as the operating system is free, users can provide a spoofed value or patch out the birthdate field from the source entirely. This is not the same as âage verification.â Besides, not all Linux distros run systemd anyway.
4 Likes
Except Qubes OS, although technically it is a Xen distribution:
Whatâs a bit sad to me is that kids that are playing around with some form of Linux, wonât get the privacy by default experience.
On the one hand this could be the perfect opportunity to teach kids how to circumvent government surveillance, but then on the other hand, it will normalize the âprivacy is deadâ narrative.
2 Likes
This is because of laws like CA AB 1043 (Age Bracketing) and NY S8102A which are designed to force age-assurance into the OS and hardware level.
âThe scope is total. If a system (like Linux/systemd) doesnât âsignalâ a userâs age bracket, that user is simply blocked by compliant websites. The âslippery slopeâ is already here. Weâve moved from porn to CA AB 728 (regulating skin cream/retinol). It effectively turns your local operating system into a mandatory digital ID checkpoint.
5 Likes
Users who are forced to disclose a birthdate could give the Unix-ish 1970-01-01. Giving this date would be a privacy win individually and a fingerprinting resistance win if done collectively. This script sets the birthdate field to this date.
I second the slippery slope concerns. Complying with this would set a bad precedent and establish momentum for future forced changes to software that we all run.
7 Likes
This gets at a conflicting narrative brought up in Seeing Like A State, which points out the folly in manufacturing order through central reporting and metrics. This builds a monoculture, kills innovation, centralizes power, ignores consent, and removes agency to solve problems with localized context.
The conflict arises from increasingly large collections of society become tempted to solve problems with giant policy band-aids but these have shown to increasingly create new unanticipated problems when applied at course levels of society.
Thatâs not to say we shouldnât have course collaborative global standards, but we have to be increasingly careful about the effects of standards at coarse levels of society. Most global standards like the UN declaration of human rights should simply be ethical expressions (as opposed to law, policies, or truths) that fall within moral prescriptivism and quasi-realism. This builds a foundational safety net that does build some norms while minimizing the risk of continually adding all societal norms and building an entirely homogenized and monoculture society.
From there it becomes important to work with a lot of existing state structures to move almost all governing responsibility towards more municipal governing bodies. This action also needs to be done carefully as lives and outcomes currently depend on large state programs. So ensuring the passage of responsibility to smaller municipal entities isnât exploited is a deep part of decentralization research and a real danger of doing these things too haphazardly. This could be managed with a well researched framework, but it needs to be prioritized at a time where we are on more stable footing in regards to global tensions.
Anyways⌠the real outcome of this policy in particular will likely push more of those who need it into the dark web. Anyone who suggests this will take away our ability to do anything needs to realize this only builds a stronger case and more attention to creating a safer dark web for those who need it and as such all the bad things that any well-intentioned politician is claiming this will solve, will move into the dark web along with all the good stuff that they arenât considering.
2 Likes
Just a thermometer, are you considering using an alternative non-systemd init going forward?
- Yes
- No
0
voters
Feel free to reply with your thoughts about the topic if you want to collaborate with a constructive understand about the situation.
The comments about this are everywhere but not so much in the forum. I was just watching a video about I2P and many people commenting about the age verification on systemd.
1 Like
Why would systemd adding an optional field to their schema so itâs available if you choose to use it lead anyone to boycott systemd? Can someone explain to me what the problem with the change systemd made here is exactly?
5 Likes
The only issue I can think of it is that systemd did not create resistance over the age verification movement. However, the amount of bullshit that is being spread on Linux communities about systemd becoming the bad guy is absurd. People are spreading a lot of misinformation on the matter.
1 Like
Iâm also a bit confused about some comments, which is why Iâve been looking into different perspectives. Iâm feeling quite uninformed on the specifics, but after reading through the debate, it seems the discomfort stems from a âslippery slopeâ concern regarding where this might lead.
Iâve seen a few arguments that highlight the divide:
ââI donât want optional fields on my computer. The init system should be just that, an init system.â
âthe guy who made the pr to systemd literally just added a json field to a json that literally has the option for you to put your address, he didnt even add a question during account creation or any backends, literally just a technical changeâ
âthatâs how it happens, they arent going to drop the whole age verification in one PR. Itâs built bit by bit until itâs too late to reject. That guy Dylan made half a dozen PRs to other projects too like flatpak to add age-verification related code. He said himself that is the ultimate point.
Btw, he tried pushing a change to Arch to collect the age during install, so youâre wrong on your last point.â
âitâs just one little trivial thing, it basically doesnât matter, then we donât need itâ
ââabsolute naivete of believing that it would end at âjust adding a field.â Please keep using windows and leave the people who love freedom alone.â
I think the confusion stems from the fact that people are looking at this through two different lenses.
Technically, the PR simply adds an optional birthday field to the systemd-homed JSON schema.
Philosophically, however, many in the community see this as âscope creep.â The concern isnât just one JSON field; itâs the precedent of an init-adjacent suite handling identity metadata. The pushback is amplified because the same contributor proposed similar changes to other parts of the ecosystem, like archinstall, leading to fears that these âoptionalâ hooks will eventually become a standardized infrastructure for mandatory age gates.
4 Likes
(I know youâre not making these arguments but I want to respond to some of them)
This is frankly nonsensical
First, that ship has sailed with systemd long long ago. Second, this change wasnât part of the init system, it was part of systemd-userdb.
Donât see what that has to do with this systemd change but ok?
Focus on the changes that arenât just adding a field to a schema then? This change doesnât remove freedom, if anything it provides more freedom by allowing me to store my birthdate in a well defined location associated with my account. What if I choose to do that? Arbitrarily preventing me from doing so would be the anti-freedom choice if anything no?
Also, without this, it could just be stored in a text file, so not merging doesnât prevent any future changes which will use it. All this does is provide upstream support for distros which will need to comply with the law and will be using systemd-userdb to store the data one way or another, thus making the OS maintainersâ lives easier.
Again, this change wasnât in the init system, it was in systemd-userdb which exists entirely to handle identity metadata already.
Push back on that change then
3 Likes
If systemd were to adopt age censorship, which flows directly to all the major Linux distros (including Arch, Fedora, NixOS, âŚ) recommended by PG, would PG recommend against these distros? What other distros would be recommended then? Did you have any discussion on that topic or is it too soon?
2 Likes
Systemd wonât have any part in age censorship, systemd-userdb simply now supports a birth date field in its schema for optional use by any OS that so chooses.
1 Like
I voted in response to the question as presented. I have always had in the back of my mind there are non-systemd options but I havenât given it serious consideration yet. I donât think I would switch from systemd solely on the grounds it added birthDate.
3 Likes
My thought process has been similar to this regarding systemd and Linux init systems.
2 Likes
If you use Android (dwarfs desktop Linux users by perhaps 40x), youâre already using a non-systemd option 
Android Desktop is around the corner.
3 Likes