Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Objections to systemd age-attestation changes go overboard [LWN.net]
[go: Go Back, main page]
|
|
Log in / Subscribe / Register

Objections to systemd age-attestation changes go overboard

By Joe Brockmeier
March 31, 2026

In early March, Dylan M. Taylor submitted a pull request to add a field to store a user's birth date in systemd's JSON user records. This was done to allow applications to store the date to facilitate compliance with age-attestation and -verification laws. It was to be expected that some members of the community would object; the actual response, however, has been shockingly hostile. Some of this has been fueled by a misinformation campaign that has targeted the systemd project and Taylor specifically, resulting in Taylor being doxxed and receiving death threats. Such behavior is not just problematic; it is also deeply misguided given the actual nature of the changes.

Age-attestation and -verification laws that place requirements on operating-system providers have passed in California and Brazil, and are being discussed in many other states and locations. This has led a number of Linux distributions to consider ways that they can comply with the laws if necessary. One idea that is being worked on is to add parental controls to the XDG Accounts portal which is a mechanism that allows applications to query for information about users, such as their name or avatar image. It can gather this information from various data sources, including systemd.

Taylor's changes would allow a system administrator to set and modify each user's birth date stored as birthDate in the YYYY-MM-DD format. Unprivileged users would not be able to modify the date, but could query it, so applications could retrieve the user's age via the Accounts portal. Note that this change does not automatically require or even prompt a user to provide their birth date; it only provides a way for applications to store the date. In other words, Taylor has only implemented one feature that could be used in a larger age-attestation system. His work does not implement an attestation system on its own, nor would such systems be prevented if the change were reverted; the birth date could simply be housed in another data store.

There have been some reasonable objections to the feature; as one example, Jeremy Soller, who works for System76, said that the company had been in talks with legislators, and it might be that open-source operating systems would be exempted from these laws in the end. Even if that does not happen, he worried that a dependency on systemd "which is decidedly unportable to non-Linux" systems, would require two implementations to exist.

Zbigniew Jędrzejewski-Szmek replied that while it was possible California's law would be changed, "similar ideas are popping up in other contexts and it's unlikely that they'll all go away". Ultimately, Luca Boccassi merged Taylor's changes after a bit of back-and-forth about the implementation.

Age attestation vs. verification

It is worth calling out that there is also a substantial difference between age attestation and age verification; attestation allows users or administrators of a system to provide information about their age. The person controlling the device is supplying the information. What is being discussed, for Linux systems, is a way for the user or administrator to supply the user's birth date. How that will be implemented for various desktop environments and distributions is still up in the air; the systemd birthDate field would be a small piece of any attestation systems that wind up being implemented.

The most important distinction is that an attestation system is under the control of the local administrator of a system; no documents are being checked or handed to a third party. Nothing prevents a person controlling the Linux system from supplying a random date rather than the accurate date. The services used for age attestation could also be disabled entirely by the administrator of the system, of course. Just because a Linux distribution ships a feature does not mean that users of the distribution are obliged to keep it turned on; but it should serve to satisfy the legal requirements placed on operating-system suppliers.

Age verification, on the other hand, generally requires furnishing a third party with some kind of proof—such as government identification—about one's birth date. There are many reasons to strongly object to age-verification schemes; privacy concerns and the potential for identity theft when third-party providers inevitably suffer data breaches are two that quickly come to mind. However, age verification is not what is being considered here. The fact that the two are being conflated, though, is not surprising—especially since Taylor used the term "age verification" in his pull request.

Controversy

As a rule, it does not take a great deal to cause a controversy in the open-source community. We are, to put it mildly, an opinionated bunch. Many people choose to use Linux because they wish to have full control over their operating system and applications; a change that offers exactly zero real benefit to the user other than compliance with a poorly thought-out law is not going to spark joy. One could predict a certain amount of objection and opposition to implementing age attestation no matter what.

However, the controversy appears to have been helped along by a few actors looking to stir the pot. In a discussion on the Debian developer mailing list about age-attestation systems, Otto Kekäläinen pointed to a site called The TBOTE Project that has been publishing information on the lobbying campaign to push an age-assurance law that has been introduced in a number of states across the US. Age assurance means that a device provides attestation of a user's age that has been verified, rather than self-supplied. For example, New York's Senate Bill S8102A requires "manufacturers of internet-enabled devices to conduct age assurance to determine a user's age category". This means that a device owner will likely need to perform some kind of age verification, and then the result would be stored locally.

The site also dedicates a section to the systemd project. To say it is conspiratorial in nature would be an understatement. It attempts to cast the systemd change as a sinister plot that has "altered the identity infrastructure of every major Linux distribution". While the site does not shy away from casting a spotlight on individuals in the systemd project, it does not disclose the person or persons who are behind The TBOTE Project. Aaron Rainbolt said that the site had been "used as part of a doxxing/harrassment attack" against an individual, which seems to refer to Taylor. "Given that the person running this repo actively helps doxx people, I consider them (semi-)malicious".

The TBOTE Project site is not alone in trying to fan the flames. Sam Bent, who describes himself as a YouTuber and content creator on his LinkedIn profile, published a hit piece against Taylor on March 20. It would also be best described as "malicious"; the less said about its contents the better, but it seems to have inspired some number of personal attacks against Taylor well beyond the usual objections in a GitHub pull-request comment thread. In an interview with the "It's FOSS" web site, Taylor described some of the backlash he has received; it is far beyond what an open-source contributor (or anyone else) should ever have to put up with:

I understood that the change was not going to be popular, but I was expecting civil discourse and a level-headed response. Things like death threats and harassment are not okay, especially when it negatively impacts unrelated third parties. However, the doxxing (and I am NOT just talking about my name, email and resume – that stuff is on my website, and is reasonably public. I don't commit with a pseudonym and I think it's reasonable to critique my contributions), hate mail, racism, homophobia, antisemitism, editing of my photo, turning my profile picture into memes and making fun of my appearance, etc. made me lose a bit of faith in the FOSS community. I'm really disappointed at the reaction. We should do better than this.

The unpleasant truth

The frustration and anger over government and industry pushes for age verification is justified; taking it out on open-source maintainers or projects is not. Reasonable people can disagree whether it is likely that, say, California would choose to prosecute Linux vendors or projects for non-compliance. We can certainly hope that logic would prevail, but one only needs to look around at the world today to determine that logic wins the day much less often than it should. Hoping that legal authorities will choose to overlook a project, or that the stars will align to provide a positive legal outcome, is not an effective strategy when it comes to avoiding real legal risk.

If a person or project wishes to take on that risk to challenge such laws, that is commendable; but demanding that another person or project take on such risks is unreasonable. The monetary costs of mounting a defense against a state government, even if ultimately successful, would be substantial and more than many projects could afford.

The efforts to push age-verification laws and similar unpleasantness did not show up on the open-source community's doorstep without warning. These political winds have been gathering strength for years; if they are to be challenged, they need to be dealt with by movements and organizations designed to take them on. Rather than harassing individual maintainers, for example, concerned people would do better to put their weight behind organizations like the Electronic Frontier Foundation (EFF) that have spent decades fighting exactly this sort of thing.

It is possible to counter legislative threats to open source and privacy without lobbing death threats at open-source maintainers (or anyone else). The European Union's Cyber Resilience Act (CRA) is a somewhat recent example. The CRA sets automatic security update and incident report requirements for products with digital elements; in non-legislative speak, this means software and devices that run software. The original drafts of the legislation would have saddled freely available open-source software with the same requirements as commercial products.

One might consider it reasonable and even desirable, for example, to require the manufacturer of a router, mobile phone, or car-entertainment system to provide security updates. But the same requirements would have applied to open-source maintainers and projects even when no money had changed hands. That, of course would have been a disaster for open source. FOSS organizations, such as the Eclipse Foundation, Linux Foundation Europe, Open Source Initiative, as well as several others pushed back politely, but firmly, and succeeded in having the CRA draft modified to exempt open-source software.

Attacking open-source maintainers, projects, or Linux distributions is not going to stop government and industry pushes for age verification. In fact, it will not be effective at anything except contributing to maintainer burnout, weakening the larger community, and perhaps encouraging developers to do more behind closed doors—or to stop contributing entirely.


to post comments

They're also fixing the wrong problem

Posted Mar 31, 2026 14:05 UTC (Tue) by davecb (subscriber, #1574) [Link] (7 responses)

I have a short article on that bug at https://leaflessca.wordpress.com/2026/02/09/wrong-ban/

This is complimentary to Marco Fioretti's https://mfioretti.substack.com/p/on-wrong-things-to-tell-...

They're also fixing the wrong problem

Posted Mar 31, 2026 14:14 UTC (Tue) by dskoll (subscriber, #1630) [Link] (5 responses)

I don't think banning cell phones for people under 16 is the right approach either (other than in class, where of course they should be banned.)

What needs to be banned is the business model that makes social media so toxic: "Engagement"-based models funded by targeted advertising. "Engagement" fuels rage-bait and misinformation, and targeted advertising violates privacy. Social media platforms should be forced to adopt the following rules:

  • No advertising on the site.
  • No sponsored posts. People see only material from people or groups they follow, and nothing else.
  • Content is shown in strictly reverse-chronological order without any algorithmic tricks to alter what a user sees.
  • The only acceptable form of revenue generation is subscription fees or donations.

There are already platforms that follow this model, such as Mastodon, which relies on donations, and Hey Café, which relies on subscription fees from PRO users. Both of those platforms are vastly more pleasant and less harmful than traditional social media sites.

They're also fixing the wrong problem

Posted Mar 31, 2026 16:04 UTC (Tue) by ballombe (subscriber, #9523) [Link] (3 responses)

For a society to be democratic, any social space need to be controlled by elected representative. There is no reason so-called social media should be exempt from this rule.

They're also fixing the wrong problem

Posted Mar 31, 2026 16:12 UTC (Tue) by mb (subscriber, #50428) [Link]

>For a society to be democratic, any social space need to be controlled by elected representative.

Ehm, no?
The social space that is my living room for instance doesn't have to be controlled by representatives, elected or not.

And neither does anything on the internet *have to* be controlled by elected representatives in a democratic society.
These things are orthogonal.

They're also fixing the wrong problem

Posted Mar 31, 2026 23:55 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Thats too short to convey enough nuance, but I think oversight should scale with risk, so small orgs may have little regulation (and more competition) and large platforms vastly more, including having government regulators on the board of directors, representing the people, along with unions representing the workers and shareholders representing capital.

They're also fixing the wrong problem

Posted Apr 1, 2026 2:11 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

Elected representatives of who? Are you saying that my discussion group about how to make base 12 the base used in society has to accept decimalists, and even let decimalists vote against any discussion on the base question? The tyranny of the majority is a real thing.

They're also fixing the wrong problem

Posted Mar 31, 2026 16:22 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

Content is shown in strictly reverse-chronological order without any algorithmic tricks to alter what a user sees

I would actually make this rule a little less strict. Reverse chronological is great for most users, and it should always be available as the default. But some users have a legitimate need for algorithmic help, especially popular users hoping to interact with fans who reply to their posts. Those users should be able to choose other algorithms if they really want to. I follow one YouTuber who has mostly given up on Mastodon because it doesn't give him the tools he needs to deal with his feed, and he's still a pretty small fish by the standards of modern celebrity. The key is that the algorithm should be under the user's control (with a sensible default) rather than whatever is in the best interest of the platform.

They're also fixing the wrong problem

Posted Mar 31, 2026 14:17 UTC (Tue) by jzb (editor, #7867) [Link]

Indeed. I kept the article focused on the aspects that specifically concern the systemd change and reactions, but yes... I place no confidence in the idea that technical age restrictions are going to "protect children".

+1 against death threats and harassment

Posted Mar 31, 2026 15:53 UTC (Tue) by IanKelling (subscriber, #89418) [Link] (2 responses)

Never ok, circumstances don't matter.

+1 against death threats and harassment

Posted Mar 31, 2026 16:06 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

Agreed.

This change is bad, and should not happen, and we should fight this the way we fought "crypto is a munition" back in the day. But under no circumstances does someone deserve death threats, no matter how misguided their work is.

+1 against death threats and harassment

Posted Mar 31, 2026 17:17 UTC (Tue) by farnz (subscriber, #17727) [Link]

Especially since the threats are going to someone trying to make compliance with bad laws manageable, instead of someone advocating for bad laws (still wouldn't be OK, of course).

To make an analogy to "crypto is a munition" days, it'd be like threatening Debian FTP masters for having a separate non-US archive to main, since that makes it easier to comply with the laws on crypto exports ("just" don't mirror non-US if you're inside the USA).

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 15:57 UTC (Tue) by bluca (subscriber, #118303) [Link] (61 responses)

Seems worth noting that most user databases that can run on Linux already had this field, and strangely nobody cared.

LDAP and common implementations:

"DateOfBirth is a Attribute that represents the Date Of Birth and often part of a Birth Record"

https://ldapwiki.com/wiki/Wiki.jsp?page=DateOfBirth

Same in OpenID:

"string End-User's birthday, represented as an ISO 8601-1 [ISO8601‑1] YYYY-MM-DD format."

https://openid.net/specs/openid-connect-core-1_0.html#Sta...

Pretty sure FreeIPA also has it, but google fails me right now

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 17:14 UTC (Tue) by pizza (subscriber, #46) [Link]

> Seems worth noting that most user databases that can run on Linux already had this field, and strangely nobody cared.

See also: ActiveDirectory (==Samba) and even Netware Directory (whose successors were ported to Linux IIRC)

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 17:39 UTC (Tue) by jadedctrl (subscriber, #178426) [Link] (49 responses)

This time around, the field is being added due to legal and political pressure. Adding a field because you fancy it is one thing, but being forced to in service of surveillance is another.

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 21:50 UTC (Tue) by bluca (subscriber, #118303) [Link] (6 responses)

This sounds like just an excuse to get angry at the wrong people

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 9:55 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (5 responses)

People following and working to implement unjust rules (when nobody even asked them to) aren't entirely blameless.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:37 UTC (Wed) by cortana (subscriber, #24596) [Link] (4 responses)

I don't see the injustice in providing the facility for a parent to provide the birth date of their child so that programs that their child may run can choose to show them appropriate content.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:48 UTC (Wed) by dskoll (subscriber, #1630) [Link]

I have no problem with parental controls as long as it's the parents who choose to use them, rather than having them mandated by the government.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:51 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

Well give a read to these laws. The birthdate must not be disclosed, the age ranges are all over the place. So one implementation that stores the birthdate is already wrong.

Plus, I very much object to letting everyone know "this person is a child"… exposing them to people who are especially interested.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 3, 2026 12:48 UTC (Fri) by anselm (subscriber, #2796) [Link]

So one implementation that stores the birthdate is already wrong.

Nobody says that if the date of birth is stored in the user database, it must be available as-is to all comers. It can just be one of the inputs to a yet-to-be-designed age attestation system that does not leak the actual date of birth to anyone (unless that is what the law requires, which would obviously suck).

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 4, 2026 2:01 UTC (Sat) by salimma (subscriber, #34460) [Link]

Precisely. The birthdate is all over the place, so a good way to be able to answer the question "is the user over the age of N" is to store the birthday (or something close to it like the birth year" ... but then use it to answer that question without disclosing that data

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 23:43 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (41 responses)

Adding a field because you fancy it is one thing, but being forced to in service of surveillance is another.

While I agree with the reason people feel different, I think the characterization of what's going on is a bit off. The goal in a lot of ways is to allow some kind of age control without surveillance. As I understand it, the idea is that each system would be able to provide a response about the user's age, but that number would be entirely under the control of the person who runs the system. If you want to set your birthday on your system to be January 1, 1970, or April 20, 420 AD, or any other date that suits your whimsy, you would be free to do so. It still isn't ideal that you have to tell the world how old you allegedly are in order to access web sites, but it's still much better than being required to register with some age verification service that would be one more part of the surveillance capitalist system. And as bluca said, the anger is misdirected; get angry at the people applying the legal and political pressure, not ones feeling it.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 5:25 UTC (Wed) by mb (subscriber, #50428) [Link] (40 responses)

>the anger is misdirected; get angry at the people applying the legal and political pressure, not ones feeling it.

Yeah, this reasoning is wrong, though.
If two parties do wrong things, it's Ok to be mad at both of them.

Almost all people in the world have no way to vote against or even protest against the people establishing the legal and political pressure.
And systemd are not only the ones feeling the pressure, they are also the ones forwarding the pressure to the users.

The whole world is sick about your awful political system, not just due to this minor reason from the article.
It's your job as US citizen to forward that pressure.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 8:49 UTC (Wed) by taladar (subscriber, #68407) [Link] (38 responses)

But systemd is not forwarding the pressure to the users. They are just implementing a central way to store a piece of optional data that will likely be required by others who are forwarding the pressure (e.g. websites) in the near future in some jurisdictions.

I for one would not prefer the establishment of secondary alternate per account databases on Linux systems instead of adding a field like "date of birth" that has been in virtually any other account database for ages, to this particular central one.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 10:11 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (15 responses)

Please… they are contributing to the enforcement of terribly written laws. I encourage you to go and read them actually, to get a clear idea of how badly written they are.

Anyway I don't think that "I only implemented part of the feature, not all of it!" is a valid defence.

Plus in some places they forbid the user's birth date to be disclosed for privacy, so having it on a file is already wrong anyway. As I said, terribly written laws that aren't possible to enforce anyway.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:13 UTC (Wed) by pizza (subscriber, #46) [Link] (14 responses)

> Anyway I don't think that "I only implemented part of the feature, not all of it!" is a valid defence.

Following your argument, everyone that contributed to oh, the entire networking stack is also complicit.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:17 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (13 responses)

If they happen to be time travellers from the future who went back in time and implemented networking just so later on create age verification sure. Otherwise I doubt that they are guilty of anything related.

The systemd change is done specifically to comply with age verification laws (and in my opinion it violates some of them so it's not even a good idea to merge it whatever your opinions on the topic might be).

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:42 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)

> If they happen to be time travellers from the future who went back in time and implemented networking just so later on create age verification sure

In other words, everyone going forward is automatically complicit, because they're continuing to implement+improve the overall system instead of immediately NOPEing out.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:13 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (11 responses)

This sounds like a parody of a lawyer. Intent matters.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:29 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> Intent matters.

Willfully ignoring the law rarely turns out well.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:14 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (4 responses)

Do you have any legal precedents to link here? I am very curious.

Remember that PGP was forbidden and then it wasn't. Now it's just subject to a campaign of "asymmetric signatures are too difficult for people to understand"

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 3:01 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Remember that PGP was forbidden and then it wasn't

s/then/after three years of very expensive legal headaches for Zimmerman/

...headaches that he deliberately brought upon himself by intentionally violating the law and daring the government to go after him.

...It's okay to volunteer yourself for martyrdom, but what I see here is a whole lot of folks saying "not it, you do it instead"

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:55 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

It's not ok to remove privacy for everyone just to comply with the laws of some backward theocracy.

Moreover if you do go and read these laws, what they are doing is actually violating them, so if one wants to avoid all the punishments you're for some reason inventing, breaking these laws by action instead of inaction doesn't seem too helpful.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 15:25 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> It's not ok to remove privacy for everyone just to comply with the laws of some backward theocracy.

....Unless you live/operate in that backwards theocracy.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 16:33 UTC (Thu) by farnz (subscriber, #17727) [Link]

And this is why it needs to remain opt-in; people in that backwards theocracy may be compelled to opt-in by local laws (or may not - depending on the place's legal system, there may be no mechanism to compel individual admins to opt-in, only to compel businesses), but the rest of the world can simply fail to opt-in.

This is why my hard lines are "opt-in, not opt-out", and "if you didn't opt-in, you pass all age verification checks by default". That protects those unfortunate enough to be in the jurisdiction that has dumb laws from being an easy victim (you opt-in, and you comply, which means that you're not a soft target), without putting a burden on those outside those jurisdictions.

After all, when it comes to age attestation, the hard part is not "how old is the user?", but "how can I trust this attestation?". So far, all of these laws boil down to "you can trust the device to not lie" - but that is inherently in conflict with Free software and laws preventing you from being compelled to not lie.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 6:44 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (4 responses)

To some people more than others.

For me, intent, in open source in particular, really doesn't matter.

I don't really care why Linus created Linux, just that he did.

More controversially, I really, really don't care why Bill Gates donates billions to health, education, etc, just that he does. Whereas some people seem eager and ready to dismiss the massive positive impact with any number of ad hominem attacks.

https://duckduckgo.com/?t=fpas&q=deontology+vs+conseq...

To be honest, I find the deontological approach to judging actions pretty irrational, but it's there, I get it, and I use it as a nice short cut oft-times (as it's _really_ hard to do consequentialism fully and correctly, and done poorly, it all too often becomes some kind of perverse justification for being horrible, and this, unfortunate, consequence of consequentialism crops up a lot in the psuedo-tech, actual bro, crowd).

So blah, to sum up, yours is a personal viewpoint based on a particular ethical philosophy that isn't something that can be declared true by fiat. It's an opinion, not a fact.

Now a jury's or judge's (probably wrong) perception of your intent, yes, *that* can matter, and have real consequences. Most legal systems are dumb and irrational, but they serve a valuable role regardless.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:03 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

Intent is important as a way of predicting future behavior. Consider someone who contributes to a poorly maintained FOSS project. If they're doing it because they depend on the project and want it to be better maintained, that's great. If they're doing it because they're hoping to take it over and use it for a supply chain attack, not so much. Their intent 100% matters!

Similarly, if someone is adding a birthday field to protect compatibility with other software, that's very different from doing it because the government says you have to as part of a half-baked plan to protect children from porn. One of those improves the software by making it more compatible, and the other one helps to use the software against the user. Totally different things.

The reason to question judging actions based on intent is because it's so easy to get intent wrong. People can lie about why they're doing things, so you can't blindly trust their stated reasons. Nobody is going to tell you they're just contributing to a FOSS project as the early stage in a supply chain attack. That leaves you judging based on much murkier criteria, which makes is way too easy to let existing biases show through. In this case, I suspect some of the worry about this is coming from people who are already skeptical of the systemd project and its contributors. Anything coming from systemd is going to start with a base level of hostility because of existing mistrust.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:34 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> One of those improves the software by making it more compatible, and the other one helps to use the software against the user. Totally different things.

You left out "the other one protects the software author(s) from being subjected to ruinous legal expenses and/or jail time"

Expecting other folks to willfully violate the laws of the jurisdictions in which they operate is a breathtaking level of privilege.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 14:49 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

> You left out "the other one protects the software author(s) from being subjected to ruinous legal expenses and/or jail time"

LOL.

Why not torture and then a nice hanging in a public square, since we're making unrealistic stuff up…

I have faith in you; you can come up with some more original forms of made up scary punishment for the noble goal of removing privacy and creating churn for unpaid people.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 15:14 UTC (Thu) by pizza (subscriber, #46) [Link]

> Why not torture and then a nice hanging in a public square, since we're making unrealistic stuff up…

What's unrealistic? Look at Phil Zimmerman. Or Rosa Parks.

Sure, they ultimately prevailed in the end (to all our benefit) but they were put through hell along the way.

> I have faith in you; you can come up with some more original forms of made up scary punishment for the noble goal of removing privacy and creating churn for unpaid people.

I live in a jurisdiction that explicitly empowers private individuals to personally sue teachers and librarians (who then have to prove *innocence* rather than the other way around) should they even mention the existence of non-binary genders or give a child the "wrong" book, or doctors mentioning the "wrong" treatments, or one of several other culture-war issues, most of which were all sold under the guise of "protecting children".

I see which way the wind has been blowing, and I see the growing forces just itching to "make an example" of someone out of pure cruelty and spite. So no, I'm being _very_ realistic here. Folks with the most exposure (ie OS creators/vendors) are very wise to protect themselves (to avoid being among the first "easy" targets) while the legal fights over this stuff continue.

(And in full disclosure: I regularly donate to numerous organizations that are actively fighting these things)

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 10:27 UTC (Wed) by mb (subscriber, #50428) [Link] (21 responses)

>systemd is not...

Yeah. But you can say that about every part of a DRM system.
There is no single part which is *the* thing that does the restriction. It's the combination of everything, including the systemd part.

Every part in the DRM system is "just" doing this and that.
Seen in isolation they are probably all fine. The systemd age field included.

It's wrong to contribute small details to the system, if the system is wrong.
This feature was clearly added to enable the age DRM system. And that's why it was wrong.

And the argument that if we don't do it, somebody else will do it, is invalid and a straw man.
If somebody else does it, it's their problem.
Users will object to *both* solutions equally.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 13:08 UTC (Wed) by farnz (subscriber, #17727) [Link] (20 responses)

Just to be clear - you're saying that it's wrong to enable people to use Free Software in a jurisdiction that requires this, and that we should instead tell people that they must use proprietary software because it implements the restrictions required by law?

In other words, you want people to be told that they must use Android, Windows, iOS, macOS, Google Chrome etc instead of Debian, OpenBSD, MirBSD, Firefox etc precisely because it's legally mandated that they have a way in the OS to store the date of birth, and to attest your age to applications?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:00 UTC (Wed) by mb (subscriber, #50428) [Link] (19 responses)

>you're saying that it's wrong to enable people to use Free Software

I'm sorry, but this is just silly. Read what I already wrote, please.
I'll stop here, because I already answered all of these "questions".

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:05 UTC (Wed) by farnz (subscriber, #17727) [Link] (18 responses)

I read what you already wrote.

Given that it is a legal requirement in some jurisdictions for OSes to provide this service, or else the OS is unlawful to sell or install, that is the only way I can read your position - you are saying that Free Software must not comply with the law in that jurisdiction, which implies that people in that jurisdiction must use proprietary software.

That is also the end case for your slippery slope argument - if you cannot legally watch Netflix with Free Software (to choose an actual DRM example), then you are implicitly saying that you expect people who want to watch Netflix legally to use proprietary software.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:09 UTC (Wed) by mb (subscriber, #50428) [Link] (17 responses)

I'll add one thing to make it really clear and then I'll shut up:
With this silly reasoning you are saying that we have to comply with North Korea rules and implement all their restrictions, because otherwise we would not enable these people to use Free Software.

It's pretty clear that: No we do not have to. We can say no. Neither US nor North Korea or any other country can issue laws that we *have* to listen to as a project. Yes, it would make the project less usable or maybe unusable in these countries. But the root cause is jurisdiction placing restrictions, not Free Software projects rejecting these rules.

We need to implement what helps people and not what restricts people (Digital Restrictions Management).

It is the problem of the jurisdiction, if it restricts people. It is not the problem of Free Software. And we cannot fix this by restricting Free Software, obviously.

Fix your country, the software ain't broken.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:13 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

No; I'm saying that if you don't comply with North Korean rules and restrictions, you are implicitly saying that North Koreans should use something else instead; and if you're saying that no Free Software can comply with those restrictions, then you're saying that North Koreans can't use Free Software.

This is a perfectly reasonable position to take - but you have to be clear that when you're saying that no software with an administrator controlled date of birth field (systemd-userdb, FreeIPA, OpenLDAP, 389-ds and more) can qualify as "Free" because of the risk of people using it to implement bad laws, you are inherently saying that people must use proprietary software to fill that niche.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:58 UTC (Wed) by somlo (subscriber, #92421) [Link] (6 responses)

OK, I'll bite :)

What, exactly, is the difference in end-result between (1) losing your actual freedom(s) by needing to use proprietary software, and (2) losing your actual freedoms by having them taken away by the "Free Software" implementations deciding to obsequiously comply with "freedom-challenged" legislation ?

And please don't tell me that "at least, obsequiously compliant free software allows you to patch out the obsequiously compliant bits" -- that is obviously not a scalable answer... :(

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:02 UTC (Wed) by dskoll (subscriber, #1630) [Link] (4 responses)

And please don't tell me that "at least, obsequiously compliant free software allows you to patch out the obsequiously compliant bits" -- that is obviously not a scalable answer... :(

I think it will be a scalable answer. I'm fairly confident that someone will provide patched versions of the software that patches out the obsequiously compliant bits, so it's not as if everyone who wants them gone will need to do it themselves.

I would hope and expect a constitutional challenge against these laws, at least in the United States. But I place no bets on the result, unfortunately.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:13 UTC (Wed) by somlo (subscriber, #92421) [Link]

> I'm fairly confident that someone will provide patched versions of the software that patches out the obsequiously compliant bits

And now we're arguing about the definition of "scalable" :) If the "serious" software maintainers become "obsequious", we get fragmentation and balkanization and "buyer-beware" wild-west environments in which we now have to decide which intermediary provider of patched software is NOT trying to scam us...

> I would hope and expect a constitutional challenge against these laws

And I would (have) hope(d) the Free Software "community at large" would (have) at least waited for that sort of process to run its course before tripping over itself to obsequiously comply, *preemptively* :(

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 4, 2026 12:32 UTC (Sat) by Rudd-O (guest, #61155) [Link] (2 responses)

Patch versions of that software already exist. What good will it do to you if apps and websites in the future refuse to provide you service unless you disclose that information, because you have a patched app that doesn't disclose it.

I will go on record to say again and again and again. The only solution that we have to avoid that dystopia of privacy invasion we are hurtling towards is to refuse to build the technical side of the dystopia. Sadly, key people in the Linux infrastructure space are gleefully collaborating with that dystopia today, and some even playing fools and pretending they don't know what they're doing.

We know what they're doing.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 7, 2026 8:42 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

The fundamental enabling technology for this, and the technical side that you need to stop people building, is user accounts.

Everything else is built on top of that enabling technology. Without it, this "dystopia of privacy invasion" cannot be built, because there isn't anything tied to an individual on a single system.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 7, 2026 10:42 UTC (Tue) by pizza (subscriber, #46) [Link]

> The fundamental enabling technology for this, and the technical side that you need to stop people building, is user accounts.

And refusing to build this on the client side just means that the accounts (and "verification mechanisms") will be implemented on the server side.

Given that those accounts _already_ exist on the server side, and routinely collect far, far more private information than one's age... you're attempting to fighting a battle that was lost literally decades ago.

This is a purely legal fight, not a technical one. It _must_ be fought in the legal [1] realm and cannot be solved/bypassed using technical means, because the agents of the state that will inevitably enforcing it simply do not care about "Free Software" or even "Freedom"... or any principle other than wielding pure, unadulterated power for its own sake.

(FWIW I think California's law was well-intentioned but did not consider any negative consequences, and at best will still end up being enforced unevenly. Whereas variations of those laws under consideration elsewhere, including federally and in my home state, will absolutely be used primarily against political opponents and the current culture war scapegoats. Because the ones pushing for these laws are already doing so with every other law at their disposal)

[1] and/or physical, ala pitchforks and guillotines. Which comes with a whole new set of problems.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:31 UTC (Wed) by farnz (subscriber, #17727) [Link]

Proprietary software may well not respect other freedoms that matter to you, beyond the freedoms that legislation prohibits. You can at least verify that Free Software is doing the minimum to respect your local laws, and not treating your privacy as an optional thing that it doesn't have to care about.

Additionally, because the implementation is fully Free, you can use it as evidence to a politician that the law is a donkey; whereas a proprietary implementation can pretend that their secret sauce is so good you'll never work out how to bypass the intentions behind the law, a Free implementation has no secret sauce, and you can thus show how to use it to bypass the legislative intent.

That's doubly true of this implementation, which is an optional field that can only be set by an admin. But if you install Fedora, Debian, Ubuntu, Arch, Bazzite or other Free OS yourself, you are the admin, and nothing prevents you filling in the field with (say) 14 May 1984, even if you are in fact younger than Mark Zuckerberg.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:56 UTC (Wed) by anselm (subscriber, #2796) [Link] (8 responses)

It is the problem of the jurisdiction, if it restricts people. It is not the problem of Free Software. And we cannot fix this by restricting Free Software, obviously.

That depends. We can still endeavour to give people the best possible experience within the restrictions that do exist.

For example, here in the EU, regulations limit the 5-GHz-band WLAN channels open to the public. While the WLAN modems in our computers can theoretically use all the WLAN channels available anywhere, the Linux kernel supports a mechanism that lets us stick to the ones we're actually legally allowed to access here. In your logic, the authors of the WLAN support in the kernel should simply refuse to implement such a mechanism because it caters to a “problem of the jurisdiction”, and WLAN users in the EU should either accept jeopardy if we're caught using the taboo channels or just not use 5-GHz WLAN with Linux at all until we can get the laws changed. Obviously, both those alternatives are inferior to the one we actually have, namely accepting the restrictions (which frankly aren't that onerous) and enjoying the use of 5-GHz WLAN without having to worry about radio measurement vans outside our houses.

For the time being, nobody knows what an “age-attestation” infrastructure should look like (and the requirements are likely to vary by jurisdiction , anyway). In the end, however, I would much rather have a free Linux system that gives me the best possible experience in the face of any requirement for “age attestation” in my jurisdiction, than no Linux system at all because some guy somewhere on the Internet has decreed that ideological purity makes Free Software incompatible with such a requirement and that therefore developers should desist from addressing the issue at all on pain of receiving death threats and other harassment. Given this, a way of specifying one's date of birth in a standardised and well-understood place like the systemd user database is obviously not the worst idea if the alternative is that every other program must come up with their own version of /etc/birthdays.

It would clearly be even better if the laws were such that Linux would not have to provide an age-attestation infrastructure in the first place, but given that various places in the world may well end up with that requirement, it makes sense to consider how best to help Linux users in such an environment. In addition, even in the continuing absence of age-attestation requirements, having the possibility to store one's date of birth in a standardised and well-understood place on the system might come in useful at times – as the authors of all sorts of non-systemd user database schemes have apparently already figured out for themselves long before the age-attestation issue even came up, so there should clearly be no problem with systemd merely catching up with the rest of the pack.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:31 UTC (Wed) by mb (subscriber, #50428) [Link] (7 responses)

>In your logic, the authors of the WLAN support in the kernel should simply refuse to implement such a mechanism

No. In my logic I set the subsystem to my country and it doesn't restrict me and doesn't needlessly store my private information.
Like how wireless-regdb did from the very beginning.

Storing private information and turning wireless on and off are completely different problems. Also by law, here in the EU. There are extremely strict rules when it comes to processing and storing private information. And we must stick to rules, right? Or does this only count, if these rules come from the US?

Also, I would be completely fine to leave wireless compliance entirely to the user.
I was actually involved in the discussions back when wireless-regdb was built. I did totally agree that we absolutely need that thing.

But that's about 20 years ago and opinions change.
Today I would not do it and just leave it up to the user instead.
Because at the end this whole thing is just a pretty useless compliance dance, that completely breaks down if the user doesn't set the country correctly or not at all.

>For the time being, nobody knows what an “age-attestation” infrastructure should look like

Well, we know what the database looks like apparently.
That's a significant part of it.

We shouldn't be building *any* part of it.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:33 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

Why is it OK to deal with the WiFi regulatory DB by setting the regulatory domain to your country, but not OK to deal with age verification by not setting your date of birth in your optional account metadata?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:38 UTC (Wed) by dskoll (subscriber, #1630) [Link] (4 responses)

Because a WiFi regulatory domain is not personally-identifying information.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:21 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

Nor is a NULL value in a database field.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:45 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

Please read by comment again. I said that I would *not* participate in implementing such a thing again and I would actively argue against it, if I had today's knowledge 20 years ago. The world changed a lot since than.

I can live well with putting the country code into wireless-regdb config, because that is *much* less critical than putting an age into an age verification system, which this systemd database is designed to become part of.
But I do not like it anymore.

Also, if there's an age verification system in place, then putting a NULL value there will lock me out.
This is a fake choice.
Just like "It's free software, just patch it out" or "write your own system from scratch" also are fake choices.
In practice everybody in the world is limited to what some US lawyers say.

We should not participate in any part of establishing such a system.
The problem must be fixed at the political root instead of implementing technical restrictions. To my knowledge, no court has ruled that systemd must implement anything for an age verification system. That would be a minimum requirement for me to get active and even think about implementing such a thing. Before that I would do exactly nothing.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 17:07 UTC (Wed) by farnz (subscriber, #17727) [Link]

But your argument is "if there is an optional field, and someone makes it mandatory, then the optional field is a bad thing to have, and nobody should be allowed to participate in software development if they put in an optional field that could be misused if it's made mandatory".

And I simply don't agree with that - as long as it stays optional, I'm fine with it. The moment that a NULL value in there locks you out, I'm with you - a NULL value should always be taken as "the user is the correct age".

In that respect, a Free implementation that complies with the law as written, and is trivial to bypass, is in many ways better than refusing to implement it at all - it shows very strongly that the law as written does not work, and requires the legislators to engage with technical reality, even when engaging with it is politically unpopular.

After all, if there's an implementation that you can ignore by refusing to give your date of birth, they either have to criminalize refusing to give your correct date of birth, or find some way to make the implementation illegal - thus showing clear hostility to Free software (and, indeed, software as speech).

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 16:59 UTC (Wed) by farnz (subscriber, #17727) [Link]

And, to be clear, if someone was proposing that this field had to be mandatory, I'd be getting upset then.

But that's the line for me - if you're being given the tools to comply with the law, but can just opt out if you don't care about that particular law (e.g. because you're not in that jurisdiction, or because you're willing to commit crimes in the name of personal freedom), that's fine with me.

The hard line is when I can't choose to ignore your jurisdiction.

Taking the North Korea argument at face value, for example, I have no problem with a configuration option that only the system administrator (root in a traditional setup) can set that's "comply with North Korean law". That might even be useful if you're under North Korean jurisdiction - you can set this configuration option, and your users now have to live with the consequences.

I do, however, have a problem with "the North Korea compliance option must be forced on, even if you aren't in North Korean jurisdiction"; while, yes, that solves a problem for North Koreans (who now don't need to demonstrate that they've never set the option to the "wrong" setting), it creates a problem for the rest of us whenever what we want to do is in conflict with what North Korea wants.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 2, 2026 10:07 UTC (Thu) by paulj (subscriber, #341) [Link]

> Because at the end this whole thing is just a pretty useless compliance dance, that completely breaks down if the user doesn't set the country correctly or not at all.

Or... the user sets the correct country, but the driver then just completely ignores it and sets "USA", cause the wifi's EEPROM has a field with '00' burned into it. (Which seems to be common for cheap ath9k hardware, maybe others). Only way to get around this is to apply a trivial patch to ignore this override (e.g. OpenWRT has one) and recompile your kernel, so that the damn wireless regulatory framework can be allowed to work correctly.

Arg!

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 12:57 UTC (Wed) by dskoll (subscriber, #1630) [Link]

If two parties do wrong things, it's Ok to be mad at both of them.

There's a large chasm between being mad at someone and issuing death threats. The former is fine; the latter is never OK.

Existing user databases had this field for ages and nobody bats an eye

Posted Mar 31, 2026 18:14 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (7 responses)

Seems worth noting that most user databases that can run on Linux already had this field, and strangely nobody cared.

I can understand the difference in attitude. This isn't something that was always there for some obscure reason; it's something being added specifically to enable complying with a law the complainers find objectionable. I understand why people are angry, though their anger would be better targeted at the people pushing for objectionable laws rather than those trying to figure out how to comply.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 5:34 UTC (Wed) by chris_se (subscriber, #99706) [Link] (1 responses)

> I can understand the difference in attitude. This isn't something that was always there for some obscure reason; it's something being added specifically to enable complying with a law the complainers find objectionable. I understand why people are angry, though their anger would be better targeted at the people pushing for objectionable laws rather than those trying to figure out how to comply.

But specifically in the context of systemd the reaction has been extreme: it's an optional field that systemd doesn't enforce anything about, _and_ the systemd authors have themselves said that the systemd project is not the right place for anything that actually implements any age verification logic, they just wanted to standardize where a birth date may be stored so that there's no 50 different ways of storing this data once other software starts implementing this.

I myself am hopefully never going to use this specific field myself. But precisely because it's an optional field this is perfectly fine. I also don't fill out my telephone number or my building / room number in GECOS either.

And finally, if my government does force me to use something like that, I'd rather have earnest people working in FOSS implement something that respects my privacy as much as possible - because the alternative will be that some commercial company will develop some kind of online service for this that doesn't respect my privacy at all, and I'll be forced to register there to be able to still use the internet.

The deranged reactions I've seen online regarding this topic are extremely disheartening. But this is not the only thing - the same person who wrote the hit piece against Taylor mentioned in the article also recently published a hit piece against another developer for proposing a change in the feature set grub is deployed with in Ubuntu 26.10. (I'm not linking that here on purpose.) While I think that passionate technical disagreement is fine and even healthy, the things I've seen in the very recent past are so far beyond the pale that I'm extremely disappointed in a significant part of the FOSS community, especially because obvious hit pieces get amplified instead of shut down.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 5:42 UTC (Wed) by mb (subscriber, #50428) [Link]

> I'd rather have earnest people working in FOSS implement something

Torture me gently.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 9:13 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

But the reaction is much like death threats to every Debian Developer and mirror operator back in the days when they added a non-US archive in parallel to the main archive, specifically to enable complying with a law the complainers find objectionable.

Why was non-US OK, but an optional age field in systemd-userdb not OK?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 10:36 UTC (Wed) by mb (subscriber, #50428) [Link] (3 responses)

>Why was non-US OK, but an optional age field in systemd-userdb not OK?

It would be totally Ok, if there was a non-US version of systemd and a non-US version of distributions with this age-DRM being removed.

That would make me stop complaining immediately.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:04 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

You're complaining because there is an optional structured way for a system administrator in a jurisdiction that requires age verification to store your date of birth with your user account on their system? And you're saying that this is not OK because it's optional, and you can opt-out, but it'll still be present in the code?

That's pretty much exactly the same situation as non-US was with Debian - so why do you think opting out of US law was OK in the non-US case, but not in this case?

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:28 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

I am complaining about part of an age-DRM system being established.
You can do that in your country, of course. Therefore and US version that has this is totally fine.

This is not about an age field or any other detail.
It's about more and more and more restrictions being established in software during the last three decades.
This is yet another tiny step, which by itself is totally fine. Just like all the other thousands of steps.
Yet, we ended up with highly restricted systems in some areas. Including Linux. And I don't want desktop Linux to also become one of them.

If the US Gov wants a special restricted version of Linux, they should make the special version for their citizens and force them to use it. But do not make the default version restricted. This is not a Free Software problem to solve. It's an US Gov problem to solve.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 11:38 UTC (Wed) by pizza (subscriber, #46) [Link]

> This is not a Free Software problem to solve. It's an US Gov problem to solve.

Uh, the "US Gov" [1] *is* "solving" this, by passing laws/regulations that require it.

[1] Along with many, many other jurisdictions around the globe

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 14:58 UTC (Wed) by NRArnot (subscriber, #3033) [Link] (1 responses)

Red Hat IDM ipa/ui seems to lack it, as of Fedora 43. There's no date-of-birth in the user account details displayed, even though there is a field for a car registration number.

Existing user databases had this field for ages and nobody bats an eye

Posted Apr 1, 2026 15:51 UTC (Wed) by cortana (subscriber, #24596) [Link]

It doesn't appear to exist in the set of schemas installed by default. 

$ ldapsearch -o ldif-wrap=no -Q -LLL -b cn=schema -s base attributeTypes | grep -i birth | wc -l
0

Let that be somebody else's problem, systemd.

Posted Mar 31, 2026 15:59 UTC (Tue) by mb (subscriber, #50428) [Link] (2 responses)

>California would choose to prosecute Linux vendors or projects for non-compliance.

That's not systemd's problem, though. It's solely the US vendor's problem.

Also, systemd technically is the wrong place to store such information.
It doesn't, can't and should not know who is currently using the computer. It could be anybody, or a dog.
A unix user account is not limited to a single person.

They're trying to solve somebody else's problem here.

Let that be somebody else's problem, systemd.

Posted Apr 1, 2026 0:56 UTC (Wed) by gerdesj (subscriber, #5446) [Link]

"It could be anybody, or a dog."

Dogs have bodies, you insensitive clod!

Let that be somebody else's problem, systemd.

Posted Apr 1, 2026 2:02 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

> A unix user account is not limited to a single person.

No user account, in practice, is limited to a single person. Short of highly intrusive always-on webcams or guards, even biometrics don't stop someone from logging in and letting someone else use the system. When an ordinary operating system is saying that someone is 18 years old, it's saying that the user is identified as being 18 years old.

GECOS Field

Posted Apr 1, 2026 6:29 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (9 responses)

If someone really wants to do this, can't they just make a new GECOS field for birth date?

GECOS Field

Posted Apr 1, 2026 8:53 UTC (Wed) by kleptog (subscriber, #1183) [Link]

Because the GECOS field is unstructured and inflexible. It would be much more complicated since you then have to decide on how it's stored, etc. Who has the authority to decide that? Whereas adding a field to a JSON blob affects nothing that doesn't care.

I wonder if it would have generated the same amount of vitriol.

GECOS Field

Posted Apr 1, 2026 9:00 UTC (Wed) by anselm (subscriber, #2796) [Link] (7 responses)

The “GECOS field” in the /etc/passwd file is basically free-form. Its name comes from the fact that it was originally used to hold login information for the GECOS operating system, back when people would use their Unix machines to log into GECOS on a different host, even though today it is generally used to store people's common names. There is a traditional convention that if the GECOS field contains a bunch of commas, the various bits separated by the commas have meanings like phone extension, office room number, etc. It would of course be possible to add another comma at the end and say that whatever comes after that comma (if anything) is the user's date of birth, but whether anyone would care to interpret the GECOS field in that way, or adapt software that adheres to the traditional convention without dates of birth, would be entirely up in the air.

We now have more elaborate and better-structured methods to represent information about users, such as LDAP or systemd's user database. I personally have no issue whatsoever with the idea that systemd's user database offers a way to store a user's DoB, especially but not only because most of the other methods already do, anyway. After all, it is entirely up to the users in question what to put there, or whether to put anything there at all. There are various reasonably benign uses of that information outside of “age attestation”, especially if providing it in the first place is entirely voluntary as far as systemd is concerned.

GECOS Field

Posted Apr 1, 2026 16:09 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link] (6 responses)

Well new software would be needed to interpret the new SystemD field anyway, so the compatibility is a wash between the two methods, except not every distro uses SystemD, and every distro does use /etc/passwd. So, why not just add a new comma field at the end of the GECOS data? Wouldn't software that doesn't know about it ignore it?

GECOS Field

Posted Apr 1, 2026 22:52 UTC (Wed) by anselm (subscriber, #2796) [Link] (5 responses)

So, why not just add a new comma field at the end of the GECOS data? Wouldn't software that doesn't know about it ignore it?

Software that doesn't know about it will probably get confused if it assumes the GECOS field contains exactly the common four subfields, or it will simply attach the value of the extra date-of-birth subfield to the value of the preceding subfield (the user's home phone number in the traditional interpretation). The basic problem with the GECOS field is that its handling is specified too loosely already to be really useful, and adding extra confusion into the mix by introducing more gratuitous subfields does not help anyone.

If you add the date of birth to the systemd user database instead, at least you won't break an indeterminate number of other programs which have been around for a very long time and which nobody is keen on having to update anymore.

.

GECOS Field

Posted Apr 2, 2026 4:23 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (4 responses)

I don't think that's true. Wikipedia states that standard GECOS treats the fifth field as "Other" and gives an email address as an example of something you could put there:

https://en.wikipedia.org/wiki/Gecos_field

Specify that the fifth field means "date of birth" if and only if it starts with "DB-" or something, and you should be good, right?

GECOS Field

Posted Apr 2, 2026 6:52 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> and you should be good, right?

No, not right. That is a hack, and this hack will fail if some other software uses the GECOS "other" field for any other purposes, or makes wrong assumptions about its content.

The point of systemd as a project is to remove hacks and replace them with clean engineering, not add to them.

GECOS Field

Posted Apr 2, 2026 7:45 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

standard GECOS treats the fifth field as "Other" and gives an email address as an example of something you could put there

So? BSD only documents four fields and doesn't mention “Other”. The Linux manpage for the /etc/passwd doesn't specify the interpretation of the GECOS field at all. Wikipedia, of course, has no normative effect on anything. All of this only serves to point out the confusion that already exists around the GECOS field.

You can of course define your own meaning for the “Other” field (if we assume it even exists), but that will break all existing programs that expect it to be, e.g., an e-mail address, or that expect there to be only four fields altogether. Even adding a prefix like “DB-” won't help because to an existing program which expects the “Other” field to be an e-mail address, something like DB-1900-01-01 will just look like either a funny e-mail address or a syntax error. And what do you do if the “Other” field is already occupied by, say, an e-mail address? Add a sixth field?

On the contrary, adding the date of birth to the systemd user database does not jeopardise existing software, puts the information into a well-defined place, and does not prejudice further extensions. It is a reasonable engineering approach while extending the GECOS field in a potentially-incompatible way would be just a brittle hack.

GECOS Field

Posted Apr 5, 2026 17:51 UTC (Sun) by linuxrocks123 (subscriber, #34648) [Link] (1 responses)

I highly doubt there are enough programs using fields 4 _OR_ 5 of the GECOS field for that to be a problem.

I don't think we want good engineering. I think we want the crappiest possible solution we can get away with. If a non-California-distributed operating system uses Field 5 of GECOS for something else, meaning spyware can't reliably count on the birthday being there -- good.

GECOS Field

Posted Apr 7, 2026 9:07 UTC (Tue) by taladar (subscriber, #68407) [Link]

If you build anything with shitty engineering all that will happen is that your solution is ignored in favor of one built by someone with slightly better engineering. If you refuse to build a good solution you lose any influence your technical skill might have given you over the outcome.

The TBOTE Project

Posted Apr 1, 2026 8:50 UTC (Wed) by _ZN3val (subscriber, #176057) [Link]

In addition to being inflammatory, the TBOTE Project makes heavy use of LLMs without reviewing their output. It generated hundreds of pages of documents in just three days. From https://web.archive.org/web/20260314224623/https://tbotep... :

> Research period: 2026-03-11 to present

where "present" is 2026-03-13 or 2026-03-14

and:

> This investigation was conducted by a human researcher who directed all research decisions, selected sources, evaluated findings, and wrote the public-facing posts. Claude Code (Anthropic's CLI tool, running Claude Opus) was used as a research assistant for:
>
> * Bulk data processing: parsing 4,433 IRS Schedule I grant records, 59,736 DAF recipients, 132MB of Colorado TRACER campaign finance data, and IRS Business Master File extracts covering all US tax-exempt organizations
> * Cross-referencing findings across 24 analysis files and identifying patterns that span multiple research threads
> * Drafting intermediate working documents and structured data summaries
> * Web searches against public databases (OpenSecrets, ProPublica, state lobbying portals, WHOIS/DNS, Wayback Machine)

It also contained nonsense like an "anomaly report" with recommendations from the LLM agent to itself, which covers an analysis of contributors to Linux's BPF, Android's Gerrit, and parser errors in using legislative databases. https://web.archive.org/web/20260314103202/https://tbotep...

Letter of the law

Posted Apr 1, 2026 9:27 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (2 responses)

@ Joe Brockmeier

Did you read the text of the laws before writing the article?

To me it looks like it is impossible to comply. But apparently trying to comply gives them a legal case that it is in fact possible to comply, and that's an important risk that we run by merging these changes.

Letter of the law

Posted Apr 1, 2026 11:34 UTC (Wed) by pizza (subscriber, #46) [Link]

> To me it looks like it is impossible to comply. But apparently trying to comply gives them a legal case that it is in fact possible to comply, and that's an important risk that we run by merging these changes.

Have you not paid any attention to legislatures over the past decade?

"Didn't even try to comply" means you will probably face full punishment allowed under the law, with your lack of effort being exhibit A that you are a horrible person on the side of sex-slave child trafficking cartels. "Made a good faith effort to comply but fell short due to $reasons" is nearly always a valid defence, especially when you can show that $reasons include "full compliance is impossible due to fundamental conflicts with other laws".

It won't be the big players -- (a) they have the resources for a robust defense, and (b) they also have the resources and self-interest to repurpose/augment their existing data collection to comply in a win-win manner. Instead it will be small players (likely attached to some culture war wedge issue) that don't have the resources to fight this, leading to easy precedent-building wins (and/or settlements) for the plantiffs. (Ie the patent troll playbook). Even if the defendants ultimately "win", they still effectively lose due to incurring ruinous legal fees and the personal toll this entails.

The point is, whomever gets hit with this first is going to be quite screwed.

Letter of the law

Posted Apr 1, 2026 20:42 UTC (Wed) by jzb (editor, #7867) [Link]

"Did you read the text of the laws before writing the article?"

The California law, yes. As well as many of the documents that went with it, such as the author intent or whatever it was called that was filed with it, etc. Plus asking EFF and SFC for their opinions. That was all covered in the previous article here: "California's Digital Age Assurance Act and Linux distributions".

"But apparently trying to comply gives them a legal case that it is in fact possible to comply, and that's an important risk that we run by merging these changes."

I'm not going to try to get into the theory that trying to comply with a law is going to impose a greater risk than not complying with the law; I don't think that's how it works, but I'm not a lawyer. I'd suggest each project or vendor consult with a lawyer, if possible, to get advice on what to do... or not to do, as the case may be.

I will say this, though: by the time a project is testing a theory that it's impossible to comply with the law (which is going to be put into question by the fact that Apple seems to be doing it or has done it), it means that they have already been prosecuted and are in court, which is expensive. A half... hearted attempt to appear compliant that can be easily turned off by users may ensure that a project or vendor does not wind up in court and does not have to expend the funds to do so.

Not a new thing

Posted Apr 1, 2026 10:25 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (14 responses)

Luca already mentioned this, but I'd like to emphasize one thing: userdb's JSON records are supposed to expose a conceptual superset of what the traditional user databases Linux is hooked to knows as fields. The primary user database that people care about is certainly the classic /etc/passwd UNIX database, and via GECOS it contains plenty PII in itself (full name, phone number, and location all the way down to a room number). But it isn't really the only one we want to cover with this, similar databases in other open source projects and in other big OSes should be translatable too to some degree without too big an impedance mismatch. And here's the thing, in the LDAP world having a birthdate field in the records is *very* common, and things like Thunderbird expose that even in the UI directly, in their LDAP/LDIF user directory stuff. MacOS' user database has a similar field too. Nextcloud's user database has it too. And so on and so on.

Hence, the birthdate field is a *common* thing, not a thing systemd pioneers here. I do believe systemd should take a design backseat here: it just maintains a user database here, is more of a provider than a consumer, and hence it should just provide the fields in a well-defined format if people want it, if it makes any sense at all, if it's a common enough thing and so on.

Hence, to me the situation has been clear, and still is: it's a relatively well defined concept, it's otherwise already well established in similar database schemes (both in the Open Source world, and beyond), and we already maintain similarly sensitive (or non-sensitive) data in userdb, hence it's absolutely fine to be added. And so we did. This is entirely independent of its potential use in any age verification system, because I can come up with at least as many good, valid usecases for this field than bad ones. For example, parental controls are generally a good thing (I speak as a parent), and yes, I also think showing in calendars birthdays of people so close to you that you share a machine with them makes a ton of sense...

Does this data deserve to be protected? Yes, absolutely. I just believe that the way to isolate apps from this data is via app sandboxing, because on UNIX all the other similarly sensitive data is not protected particularly otherwise. And app sandboxing already delivers that: NSS or userdb access is generally not available from flatpak sandboxed apps for example.

I find it absolutely horrible what happened here, the way shitstorm in particular Dylan was exposed to is so so awful. I really hope that everyone who participated in this shitstorm will be ostracized from the Open Source community wherever possible, as these are despicable people. I can say at least that I have blocklisted and reported more people in the past two weeks on Mastodon and GitHub then probably my whole existence on these web services before. I hope others do the same. And I really hope the people stop associating in particular with the key people who drove this shitstorm (Lunduke, Bent, …) for good.

Lennart

Not a new thing

Posted Apr 1, 2026 14:19 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (13 responses)

Hi Lennart,

I won’t write about the shitstorm because I’ve avoided it, however surely you can see that there is a difference, between providing an exact birthdate to software running under the user control on its own system for its own use, and making this information available to any remote third party that wants to data mine it and then correlate it with $deity knows what for $deity knows what purposes (probably not in the user own interest). At a minimum the information exposed should have had its granularity reduced to I am an adult / I am not (with eventually a youth/dependent adult class added). Though even this is problematic because it allows easy targeting or vulnerable populations. So there should be at least some statement by the project it should never be relayed transparently to the first remote bot that asks.

Adding a very granular and dangerous field without elaborating *any* strategy or policy to protect it from misuse was bound to elevate tempers.

Not a new thing

Posted Apr 1, 2026 14:40 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (12 responses)

Did you read what I wrote? I'd encourage you to.

Maybe you get my point if I reword it: the birth date is the least of your problems: you apps should *not* get direct access to your user database anyway, the birthday potentially stored there is the least of your problems, it has location info potentially, your real name, a number identifying you, your phone number, a hash of your pw and more.

Hence: sandboxing your app is essential, to enforce protection of *all* fields in the user database. And yes, that exists, it is called flatpak! it takes direct user database access away, yay! *including* the birth date and all the other info in it! Wow!

*Please* try to understand what I wrote, I find it such a waste of time, to answer to every person asking me to see it from another angle, without even bothering to check if maybe that very angle was already covered.

Not a new thing

Posted Apr 1, 2026 15:04 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (8 responses)

I did read what you wrote however is is not terribly useful, because sandboxing is a yes/no proposition, so it usually leads to full information disclosure (give me all your info or else). For protection to be effective you need to actually work to define the safe subset that can actually be exposed without too much risk. You can not punt on this policy work and expect the end result to work (or people to be happy).

Not a new thing

Posted Apr 1, 2026 20:03 UTC (Wed) by tchernobog (subscriber, #73595) [Link] (7 responses)

> because sandboxing is a yes/no proposition,

Then a better outlet for your frustration would be to open an issue to have granular claims against the user database or corresponding portal. This can include different claims for date of birth or age brackets.

This I think would improve the privacy of sandboxed applications for everybody, and make it clear with an explicit authorization flow any access attempt, where the user has to approve the first time data is requested.

Not a new thing

Posted Apr 1, 2026 20:07 UTC (Wed) by tchernobog (subscriber, #73595) [Link]

Sorry, forgot the link: basically this interface needs to be redesigned: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org...

Not a new thing

Posted Apr 4, 2026 12:30 UTC (Sat) by Rudd-O (guest, #61155) [Link] (5 responses)

What good is it going to be to have even granular permissions for what kind of information to disclose, when the whole software ecosystem is by law required to disclose that information, and must refuse service to you if you "turn that toggle off"?

The only way to avoid the privacy invasion dystopia that we're hurtling towards is to simply refuse to build the technical side of the dystopia. And regrettably, the system, the people, are all in favor of building the technical part.

Not a new thing

Posted Apr 4, 2026 12:57 UTC (Sat) by pizza (subscriber, #46) [Link] (4 responses)

> The only way to avoid the privacy invasion dystopia that we're hurtling towards is to simply refuse to build the technical side of the dystopia

You are laughably naive if you think this can be fought using technical means when the other side employs a literal army. This is a *legal* (and *cultural*) battle, and the sooner you understand that the better.

Meanwhile, desktop Linux folks running full F/OSS stacks are barely a rounding error on the worldwide userbase that uses devices that run proprietary operating systems and applications that *already* routinely violate user privacy -- by design.

Not a new thing

Posted Apr 4, 2026 13:37 UTC (Sat) by Rudd-O (guest, #61155) [Link] (1 responses)

I was there when the PGP source code was created and how technical measures were used to defeat the legislation that made source code into munitions.

You can call me whatever names you want. The fact remains: technical measures definitely help define the world we live in, and the technical measures can also be used to build a dystopia.

Not a new thing

Posted Apr 4, 2026 15:28 UTC (Sat) by pizza (subscriber, #46) [Link]

> I was there when the PGP source code was created and how technical measures were used to defeat the legislation that made source code into munitions.

s/technical measures/several hundred thousand dollars in legal fees over the course of three years/

The "technical measures" accomplished nothing on their own; it was the ensuing *legal fight* that actually changed things.

To be more blunt: Are *you* volunteering to have your life turned upside-down for a criminal investigation and/or actual indictments+trials, have your name dragged through the mud in the press (because remember, only child groomers/trafficers/etc would ever stand against this), have your family get routinely harassed if not actual/actionable death threats, and have to spend six figures in legal fees even if you *win*?

Because that's what you're volunteering someone else for.

Not a new thing

Posted Apr 4, 2026 13:39 UTC (Sat) by Rudd-O (guest, #61155) [Link] (1 responses)

> Meanwhile, desktop Linux folks running full F/OSS stacks are barely a rounding error on the worldwide userbase that uses devices that run proprietary operating systems and applications that *already* routinely violate user privacy -- by design.

Well, with the changes currently being discussed and implemented, it looks like Linux will cease to be an option for people who want to be private online as well.

I don't worry about Windows or Mac users because they have already decided that their privacy is worth less than nothing. But I worry about Linux users, I have a right to do so, and you are nobody to tell me otherwise or minimize my concerns.

Not a new thing

Posted Apr 4, 2026 15:20 UTC (Sat) by pizza (subscriber, #46) [Link]

> Well, with the changes currently being discussed and implemented, it looks like Linux will cease to be an option for people who want to be private online as well.

You mean "linux will cease to be an option to anyone wishing to interact with the rest of society"

See how well your "but mah privacy!!!" argument goes when you have to interact with your local government.

Not a new thing

Posted Apr 4, 2026 12:28 UTC (Sat) by Rudd-O (guest, #61155) [Link] (2 responses)

Look, man, let me be frank.

You have approved the addition of this field in that database for the simple reason that app stores (and possibly web sites) will demand that piece of information by law. This is not just a severe violation of people's privacy in their own computers, but also in dangerous children and adolescents, because it gives (possibly) websites and (certainly) app stores a list of underage people to target, complete with source IP address.

You did this in the face of enormous, almost all peaceful but firm, public opposition from hundreds of people.

To claim ignorance of where this whole thing is going, or innocence of intention is not going to fool anyone.

You can switch the topic to talking about flatpak and sandboxing until the cows come home. It does not erase the fact that you have collaborated in a clear and massive invasion of privacy for the vast majority of Linux users.

What good is it going to do to have all the sandboxing in the world, if applications will soon have an API to query this PII and snitch it to third parties whom we never may know who they are (worse, if they may be child predators!) Even if there was a toggle to switch it off, what good would that toggle do if the whole computing ecosystem is changed so that apps and websites can request that information, and the law requires them to refuse serving those who switch it off? We can only get to that dystopia, of course, if people like you consent to building the technical part of the dystopia piece by piece — and you were there to approve emplacement of the first building stone.

You specifically should have opposed that implementation from the very start, and waited until case law voided those statutes. We already have case law in several states of the US that have voided statutes similar to that.

Evil is opposed by refusing to comply with it. It is not opposed by claiming "I'm just going to approve this little innocent piece of the evil puzzle" then pretend not to know what that piece of the puzzle was for.

There. I said it.

Not a new thing

Posted Apr 4, 2026 12:45 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> You have approved the addition of this field in that database for the simple reason that app stores (and possibly web sites) will demand that piece of information by law.

"Comply with the law" is a *damn good reason* to do something.

How mighty of you to berate free software authors for not deliberately ignoring the law at their own personal and professional peril.

Your ire and vitriol is should be directed towards the ones passing or pushing for these laws, eg the various law/rule-making bodies that have enacted (or are currently considering) these laws, not the poor saps whose necks are on the line.

Even well-intended laws executed in good faith can produce bad outcomes, but the intent behind these is anything but benign (for many of the reasons you described!) and those itching to enforce them have never been accused of acting in good faith. But until they are overturned or otherwise scrapped (which is far from certain, given the massive coordinated push behind them) everyone affected by these laws is still bound to comply with them.

I suggest you put your money where your principles are and donate to organizations that are fighting these things in the courts, while divesting yourself from (and speaking out against) those [in]directly pushing to get these rules enacted.

> There. I said it.

Do you expect a cookie or something?

Not a new thing

Posted Apr 4, 2026 13:35 UTC (Sat) by Rudd-O (guest, #61155) [Link]

> Comply with the law is a *damn good reason* to do something.

I think you know that wully depends on which law you're attempting to comply with. Don't make me say the obvious.

Also, by the way, there is no law anywhere that requires *Lennart* to change or add anything to systemd, so there is nothing to comply with, so your berating me is baseless.

Lennart is not an operating system distributor or manufacturer. He only makes kits of software that could be used as building blocks for operating systems, but no law anywhere requires him to add spyware to his kit. If anything, the laws we are discussing would imposet an obligation for, say, The Fedora Project or Canonical. Not Lennart.

I can't stress this enough: Lennart had a literal risk-free choice. Do not add help the insertion of spyware into the Linux desktop. Let others who really are at risk do it (or refuse!) perhaps in other components of a Linux distro. He still chose to help add buliding blocks for spyware.

> How mighty of you to berate free software authors for not deliberately ignoring the law at their own personal and professional peril.

Except Lennart faces no legal risk for not adding the birthdate field to systemd-userdbd. So yes, no peril, ergo your display of sympathy is baseless.

We would be having a different conversation if the birth date was added because there's some sort of corporate need to have systemd-userdbd have the birth date for some reason. But we know in which context this is being added. So it's not like they can claim innocence.

Furthermore, I actually looked at the pull request itself, where the author of the pull request specifically commented in the code that this addition was in response to these evil laws we are discussing (true fact). And I think it was Lennart himself (or my memory could betray me) who reviewed that comment and ordered it removed from the source code. Why order the removal of a source code comment explaining a true fact and a motivation for the work?

> Your ire and vitriol is should be directed towards the ones passing or pushing for these laws

It's also directed at them, especially at them. But LWN is not a legislator forum so you don't see me talking to legislators here.

Furthermore unlike free software contributors and developers, I don't expect legislators to have scruples or acumen, because they're legislators. I have higher expectations of software developers.

> whose necks are on the line

Specifically not Lennart! And also not the author of the pull request.

> Even well-intended laws executed in good faith can produce bad outcomes, but the intent behind these is anything but benign (for many of the reasons you described!) and those itching to enforce them have never been accused of acting in good faith. But until they are overturned or otherwise scrapped (which is far from certain, given the massive coordinated push behind them) everyone affected by these laws is still bound to comply with them.

We agree.

> I suggest you put your money where your principles are and donate to organizations that are fighting these things in the courts, while divesting yourself from (and speaking out against) those [in]directly pushing to get these rules enacted.

I am. I have personally set aside $50.000 for organizations dedicated to effectively combat these egregious privacy violations and compelled speech constitutional violations


Copyright © 2026, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds