https://www.reddit.com/r/linux/comments/1rr3f3n/followup_to_my_bill_text_comparison_i_traced_who/
Systemd didn’t revert. It’s a rejected pull request.
2 Likes
Did you read Poettering’s comment?
3 Likes
I hope you’re right and even if you are, I hope that everyone will still take this as a warning, and create a censorship resistant infrastructure. Because this shows how vulnerable Qubes OS is currently. It was scary seeing one state after another in unison making these sudden laws. I’m surprised that EU didn’t join in because they love this kind of digital control. But they maybe are planning to.
Actually I meant pseudonymous. It’s good you made a point about that.
And yes, like Quben said earlier in this topic, a pseudonymous dev can be trusted based on their history.
That is common in blockchain development, where some developers are pseudonymous but still get hired to work on blockchains because they have previously done a lot of valuable work under their pseudonymous identity.
And with PGP we can know that their username isn’t simply taken by someone else.
And also like Quben said, I would trust a pseudonymous dev more because they are less likely to have been co-opted by state actors.
Because when they are pseudonymous, they can resist.
Most devs who lose their anonymity, can’t stand up against the corrupt oppressive pressure which state actors can put on them.
1 Like
What are the targets of this law specifically?
1 Like
A somewhat similar thing happened to torrents already. Yes you can technically torrent in every country. But in some places you will be fined. Same thing happened with vpns
1 Like
This just confirms. SystemD is malware now
1 Like
Of course. Shocking. Nothing but rejection and censorship.
 systemd locked as too heated and limited conversation to collaborators Mar 19, 2026
poettering commented Mar 19, 2026 •
It’s an optional field in the userdb JSON object. It’s not a policy engine, not an API for apps. We just define the field, so that it’s standardized iff people want to store the date there, but it’s entirely optional.
Hence, please move your discussion elsewhere, you are misunderstanding what systemd does here. It enforces zero policy, it leaves that up for other parts of the system.
And sorry, I am really not interested in these discussions here. it’s not the right place for this, and please don’t bring it here. Thank you.
 poettering closed this Mar 19, 2026
 github-actions bot removed the please-review label Mar 19, 2026
 systemd deleted a comment from ta13579 Mar 19, 2026
1 Like
Well, systemd didn’t suffer from feature creep in this case, though. I would have expected them to implement the whole thing. Regarding the data fields… The GECOS field for fingerd exists as well. There is no need to fill it in.
2 Likes
Actually I meant pseudonymous. It’s good you made a point about that.
And yes, like Quben said earlier in this topic, a pseudonymous dev can be trusted based on their history.
This is wishful. You cannot trust a pseudonym that claims “I am your mother” or just because 100 other unknown pseudonyms confirm “Yes, that is your mother”.
You need a chain of trust, e.g. non-anonymous trusted verifiable persons who trust the pseudonymous one. And even then, no trust is eternal or absolute.
That is common in blockchain development, where some developers are pseudonymous but still get hired to work on blockchains because they have previously done a lot of valuable work under their pseudonymous identity.
And with PGP we can know that their username isn’t simply taken by someone else.
That is a proof of authenticity, not a proof of trustfulness.
And also like Quben said, I would trust a pseudonymous dev more because they are less likely to have been co-opted by state actors.
Do you think state actors use real names, and show up saying “Bond. James Bond”?
2 Likes
Yes, I agree with you. This shitty law not applying to Qubes does not negate the merits of creating censorship resistant infrastructure. There are some technical hurdles but nothing Qubes devs couldn’t solve. There are two issues however: 1:Trust; 2:will
1:I find it very hard to trust something as critical as an OS to a pseudonymous identity only, example is secureblue, project seems great, very interesting, yet I can’t help but feel uneasy at the prospect of installing it, even as a VM, when the main guy responsible for the project has a relatively new (few years) pseudonymous identity. Doesn’t mean it is malicious at all, but it does reduce trust. This applies to every single project. There are other ways to make the project resistant to censorship/oppressive BS that do not rely on pseudonymous identities but these need to be explored within the community at some depth to see if they are viable.
2:Will the Qubes project really want to do this? They receive donations, from big players, not just individuals, that are less likely to be given if the project is fully pseudonymous. Shifting to pseudonymous identities will create friction in several areas.
Other avenues: Perhaps moving the project, not necessarily devs, as those have their lives wherever they are, to a friendlier jurisdiction, will help with defense in depth. Iceland might be the most privacy friendly country there is. There are bound to be other options though.
Reality check though: All these american states/brasil creating these tech illiterate age verification laws aimed at operating systems will face serious jurisdictional issues like I have detailed in several of my posts so far. Reading them and the related jurisprudence might put you more at easy regarding Qubes. There are other distros that are somewhat exposed however… Still not a lot, only slightly and I can see easy mitigations for some of them.
I am tired of saying this, but again, I am not a lawyer and this is not legal advice.
1 Like
A third-party Know Your Customer (KYC) service provider may be required for age verification in applicable cases.
Quote Attorney General, New York government (
ag.ny.gov) Notice of Proposed Rulemaking
Accredited Third-Party
The proposed rule defines “accredited third-party” to mean a person qualified to certify an age assurance method, as determined by the American National Standards Institute or an equivalent accreditation body,
Likely coming soon.
Quote (ag.ny.gov) Protecting Children Online, Notice of Proposed Rulemaking
Comment review and final rule drafting
There are many existing third-party KYC providers. Online banks and financial services often use them instead of handling KYC in-house.
I am not saying operating systems / third-party KYC providers are supposed to perform “full” KYC identity verification. At least not yet. However, these third-party KYC providers are well positioned to do something relatively simpler, which is a subset of their business services: age verification.
Anonymous banking is, in practice, no longer available worldwide. [1]
Banks and financial services are in practice forced to verify customers’ identities because they are legally required to prevent unauthorized U.S. persons from using the service. [2]
Otherwise, access by U.S. customers can create U.S. enforcement risk.
This is illustrated in the Legal Jurisdiction Comparison Table, and shown by the case of 1Broker.
I hope the same is not underway for operating system providers.
If any anonymous or pseudonymous developers are interested and following this discussion, they would be the ones to build that infrastructure. The infrastructure would have to be built by pseudonymous sysadmins or developers. Otherwise, it would not help mitigate this issue.
This goes both ways. A pseudonymous developer will always be unsure whether their identity has been compromised by any adversary. It requires only a single mistake in a decade. If they are arrested or worse, their identity could be taken over without anyone noticing or being able to raise the alarm.
Unless they told a trusted circle that can raise the alarm, but as soon as anyone in real life knows, some risks are reduced and new risks are introduced. There is no perfect solution.
More than 200 jurisdictions are part of the FATF global network, whose standards prohibit anonymous accounts and require customer identification and verification. In practice, there is no meaningful lawful way to offer anonymous banking today. ↩︎
Even where a U.S. license or registration is available, customer identification and verification remain required. ↩︎
2 Likes
[… 3 lines elided]
Would you trust software created by completely anonymous people with
unknown past and relations? How would you know it is not a state actor
behind an anonymous identity?
[… 13 lines elided]
There have been examples of this: completely anonymous people coming
together to work on a software project that ends up being used widely.
Bitcoin had its satoshi nakamoto, Monero had its Nicholas Van
Saberhaagen. In both cases, the originators of these projects knew that
at the end of the day they were going against very big powers, and they
donned the anonymity cloak.
Regardless of the devs being anons, the software project itself being
open source and free software gives the user some degree of trust. The
user can try to audit the software itself, or hire other developers who
audit the software and decide whether it is malware or whether it works
as intended or not.
Developer anonymity in software projects have happened in the past, it
is not some new “eureka moment” waiting to be discovered.
Also how will they work together if they are anonymous? And I mean
anonymous (disposable identifiers), not pseudonymous (persistent
identifiers).
IRC, XMPP, PGP, SSH keys… All the infra for trusting anons on the
internet without requiring government issued ID has been available for
decades now. Come on.
2 Likes
[… 18 lines elided]
Actually I meant pseudonymous. It’s good you made a point about that.
And yes, like Quben said earlier in this topic, a pseudonymous dev can
be trusted based on their history.
[… 18 lines elided]
Even FULLY ANONYMOUS devs can be trusted, IF their code contribution
are made out in the open. You can read the suggested code change DIFFS
of the ANON DEVS. You can discuss the proposed changes to the code
bi-weekly, or monthly.
The work speaks for itself. No need for appealing to a given name, or a
PSEUDONYM.
This has been the modus-operandi of Monero project development for 12
years now.
1 Like
[… 5 lines elided]
Actually I meant pseudonymous. It’s good you made a point about that.
And yes, like Quben said earlier in this topic, a pseudonymous dev
can be trusted based on their history.This is wishful. You cannot trust a pseudonym that claims “I am your
mother” or just because 100 other unknown pseudonyms confirm “Yes,
that is your mother”.
What are you even talking about with this “I am your mother,” nonsense?
You can trust the GPG signatures of messages and see if any particular
message, email, or code contribution has come from a previous dev with a
pseudonymous identity, or a completely new dev with an anonymous
identity. In both cases, you take a look at the code, with your
community of developers and users, and discuss whether to merge the
contribution or not. Are you really not familiar with the software
development culture around reputable crypto currency projects?
You need a chain of trust, e.g. non-anonymous trusted verifiable
persons who trust the pseudonymous one. And even then, no trust is
eternal or absolute.
This is irrelevant. See my above paragraph.
That is common in blockchain development, where some developers are
pseudonymous but still get hired to work on blockchains because they
have previously done a lot of valuable work under their pseudonymous
identity. And with PGP we can know that their username isn’t simply
taken by someone else.That is a proof of authenticity, not a proof of trustfulness.
What are you doing with these dictionary work of defining phrases for
your point? Forget about splitting hair around “proof of authenticity,”
or “proof of trustfulness” (nobody asked you about the meaning of these
terms, anyways). The point is this: a specific cryptographic identity
has signed a git commit that is being proposed for merging. What do we
do? What do we do is this: check the cryptographic identity signatures.
Then review the proposed code for the merging. Discuss it with the
developer community whether the proposed changes align with the software
goals and the vision.
2 Likes
Anonymous banking is essentially unavailable (not completely) not simply because of US laws and associated risk, but because the majority of the world’s population lives in countries which have their own mandatory KYC for banking.
It is not, far from it, as I have detailed in my previous responses to you, with some relevant jurisprudence to attest to that (particularly relevant as the court in question covers California).
Having ongoing business relations with american citizens (or Californians in this case) and selling them goods and/or services constitutes purposeful availment and fulfils the “something more” and “forum directed activity” criteria that the Ninth circuit court considers necessary for jurisdiction purposes.
Based on publicly available information, the aforementioned does not seem to apply to Qubes in any way. Nor to most community driven distros.
Jurisdiction matters, particularly in a global world.
I am not a lawyer nor is this legal advice.
1 Like
[… 33 lines elided]
A random country, much less
a state within one, can’t simply rule or decide how projects all over
the world operate lol.
Anonymous banking is, in practice, no longer available worldwide. [1]
Banks and financial services are in practice forced to verify
customers’ identities because they are legally required to prevent
unauthorized U.S. persons from using the service. [2]
Anonymous devs can try to move their financial dealings to the parallel
economy side. Work for, get paid, or get donations in Monero and then
use peer to peer, decentralized exchanges like retoswap[1] to exchange
anonymous crypto currency to their local fiat currency. They can even
try swapping the XMR payments they get to a coin like Litecoin, which
has more off-ramps on centralized crypto exchanges, and use LTC’s
mimblewimble privacy feature to break the money trail from XMR to LTC.
There are ways available for funding one’s own operations on the
parallel economy with untraceable digital cash like XMR.
[… 13 lines elided]
[quote=“plankretriever, post:204, topic:39788”] And also like Quben
said, I would trust a pseudonymous dev more because they are less
likely to have been co-opted by state actors. Because when they are
pseudonymous, they can resist. [/quote]
This goes both ways. A pseudonymous developer will always be unsure
whether their identity has been compromised by any adversary. It
requires only a single mistake in a decade. If they are arrested or
worse, their identity could be taken over without anyone noticing or
being able to raise the alarm.Unless they told a trusted circle that can raise the alarm, but as
soon as anyone in real life knows, some risks are reduced and new
risks are introduced. There is no perfect solution.
[… 23 lines elided]
This is all part of the skillset and prowess of the anonymous developer
himself. You are making safe-guarding of the cryptographical secrets
sound too difficult if not impossible. There are lots of examples to
the contrary. Bitcoin’s Satoshi Nakamoto or Monero’s Nicolas Van
Saberhaagen have securely safeguarded their cryptographic identities and
keys so far. There are deadman’s switches as well as splitting the
secrets into multi-sig setups which make compromising the dev himself
ineffective for giving up the secrets themselves.
If a dev is willing to operate anonymously, part of his/her skills &
responsibilities is safely managing and safeguarding his/her
cryptographic secrets, as well as writing good code that works. IF they
cannot do so, they shouldn’t try to be an anon dev anyways.
Footnotes:
2 Likes
Whatever happened to adw? Qubes’ community manager, would be good to see him get involved in the discussion.
1 Like
2 Likes
When you post reply after reply without waiting for an answer, this is overwhelming and breaks the line of discussion.
What are you even talking about with this I am your mother, nonsense?
If you don’t understand what I am saying, that doesn’t mean it is nonsense. And if you argue with that which you don’t understand, that is hardly “sense”.
You can trust the GPG signatures of messages and see if any particular
message, email, or code contribution has come from a previous dev with a
pseudonymous identity, or a completely new dev with an anonymous
identity. In both cases, you take a look at the code, with your
community of developers and users, and discuss whether to merge the
contribution or not. Are you really not familiar with the software
development culture around reputable crypto currency projects?
I think you are confusing things and only extending the off-topic. I was making a point that completely anonymous development was impossible. Pseudonymous is possible but greatly reduces trust. @adrelanos explained it perfectly:
This goes both ways. A pseudonymous developer will always be unsure
whether their identity has been compromised by any adversary. It
requires only a single mistake in a decade. If they are arrested or
worse, their identity could be taken over without anyone noticing or
being able to raise the alarm.
You are arguing against that with border-line argumentum ad populum about wide adoption of cryptocurrency whose developers are unknown, you pretend to know what their intentions were, and you are considering all this in a very narrow context and historical time frame. I will not reply further to that because it is very remotely related to the current topic and completely non Qubes-specific. I will only say:
Trusted != verifiable
You verify when you don’t trust, and vice versa.
This is irrelevant. See my above paragraph.
Your “above paragraph” starts with abuse and ends with mentioning of “culture”. Now you are saying that chain of trust is irrelevant when trust is being discussed. I wonder what you expect.
What are you doing with these dictionary work of defining phrases for
your point?
Clarifying that you are confusing things. The public key is an indication of origin, not an ultimate proof of it. The key is not the person. See what @adrelanos explained.
Forget about splitting hair around proof of authenticity,
or proof of trustfulness (nobody asked you about the meaning of these
terms, anyways). The point is this: a specific cryptographic identity
has signed a git commit that is being proposed for merging. What do we
do? What do we do is this: check the cryptographic identity signatures.
Then review the proposed code for the merging. Discuss it with the
developer community whether the proposed changes align with the software
goals and the vision.
Please don’t tell me to forget about the point I am making in order to simply accept yours. That is not reasoning. I understand your point but I am explaining why it is limited.
Trust is not just looking at a key and saying “that’s my mother”. Trust is a matter of social interaction. When you are a kid and make friends with other kids, you don’t ask for their PGP keys. You don’t even need a name, except for verbal communication. You have many other social and biological clues on which you base your trust. In cyberspace you don’t have any of those, so you use artificial clues (e-identity) that are forgable, stealable or vulnerable. That’s why it is important to have a link between cyber space and real society to establish trust. Without a chain between the two, you are trusting your imagination.
I believe this is getting way off-topic to AB-1043, so either have a split, or please get back on track.
Since so many disclaimers have been posted:
I am not a lawyer. This is not a legal advice.
I am not a doctor. This is not a medical advice.
…
I am your mother!
1 Like
[… 5 lines elided]
When you post reply after reply without waiting for an answer, this is
overwhelming and breaks the line of discussion.
Feel free to take your time with the messages, and use “quoting” when
you reply. Discourse allows me to post 3 consecutive messages in a
thread, and I am happy to use that. Considering this, you can take a
look whether Discourse software has a knob for reducing the consecutive
reply per thread, and if so, you can campaign to the forum admins for
reducing that option.
What are you even talking about with this I am your mother, nonsense?
If you don’t understand what I am saying, that doesn’t mean it is
nonsense. And if you argue with that which you don’t understand, that
is hardly “sense”.
Well, your case doesn’t help me with making any sense of your arguments,
so that “putting the blame on the other” goes both ways.
You can trust the GPG signatures of messages and see if any particular
message, email, or code contribution has come from a previous dev with a
pseudonymous identity, or a completely new dev with an anonymous
identity. In both cases, you take a look at the code, with your
community of developers and users, and discuss whether to merge the
contribution or not. Are you really not familiar with the software
development culture around reputable crypto currency projects?I think you are confusing things and only extending the off-topic. I
was making a point that completely anonymous development was
impossible. Pseudonymous is possible but greatly reduces
trust. @adrelanos explained it perfectly:
I don’t think I am confusing things and I don’t think I am extending the
off-topic. The topic is “how much do we gotta worry about this age
verification BS” and one way you can examine this is considering the
case where the QubesOS devs were completely anonymous, which would (to
some extent) prevent law enforcement going after them (see the case of
anonymous crypto currency developers, or various i2p and tor developers
in the past & present, etc). I am arguing against the implicit
point in this thread that is being put forth by you which alleges
“Completely Anonymous Software Development Is Impossible”, or
“pseudonymous development is possible but greatly reduces trust.” I
disagree with both cases, and told you that as long as the software code
is open source and its binaries are reproducible from the source code,
the developer pseudonymity/anonymity doesn’t have to “greatly reduce
trust.”
This goes both ways. A pseudonymous developer will always be unsure
whether their identity has been compromised by any adversary. It
requires only a single mistake in a decade. If they are arrested or
worse, their identity could be taken over without anyone noticing or
being able to raise the alarm.You are arguing against that with border-line argumentum ad populum
about wide adoption of cryptocurrency whose developers are unknown,
No I am not. I am saying that various crypto currency developers (along
with various i2p and tor contributors) have been successfully made code
contributions to their respective software projects while staying
anonymous. I am not making an “argumentum ad populum” argument. I am
showing you examples.
[… 6 lines elided]
Trusted != verifiable
You verify when you don’t trust, and vice versa.
I (and many other people in OPSEC communty) go by: don’t trust, verify.
This is irrelevant. See my above paragraph.
Your “above paragraph” starts with abuse
I don’t think so. If so, I can also make the case that, your whole
attitude here goes with “tone policing”, and we can spend hours arguing
about manners, rather than arguing about the points we bring up.
and ends with mentioning of “culture”. Now you are saying that chain
of trust is irrelevant when trust is being discussed. I wonder what
you expect.
I am saying, and I repeat:
The point is this: a specific cryptographic identity has signed a git
commit that is being proposed for merging. What do we do? We check the
cryptographic identity signatures. Then review the proposed code for
the merging. Discuss it with the developer community whether the
proposed changes align with the software goals and the vision.
A certain signature is not the single data-point we collect about a
software code change before we merge the proposed changes to the
main/master branch of the software project. Signature certainly adds up
to the case of trustworthiness, but it is not the only requirement that
needs to be obeyed.
What are you doing with these dictionary work of defining phrases for
your point?Clarifying that you are confusing things.
I joined the thread after you split the hair with definitions.
The public key is an indication of origin, not an ultimate proof of
it. The key is not the person.
Yeah. I would agree with that. And I wasn’t arguing that a public key
signature itself is enough to merge-in the proposed code changes to the
software.
[… 14 lines elided]
Trust is not just looking at a key and saying “that’s my
mother”. Trust is a matter of social interaction.
Trust is not the ultimate thing to be sought here. It is rather, and I
repeat: you can trust the GPG signatures of messages and see if any
particular message, email, or code contribution has come from a previous
dev with a pseudonymous identity, or a completely new dev with an
anonymous identity. In both cases, you take a look at the code, with
your community of developers and users, and discuss whether to merge the
contribution or not.
Signature itself is not the God’s commandment for merging the
software code changes.
When you are a kid and make friends with other kids, you don’t ask for
their PGP keys.
We are talking about software development on the internet behind the
cloak of anonymity.
[… 3 lines elided]
In cyberspace you don’t have any of those, so you use artificial clues
(e-identity) that are forgable, stealable or vulnerable. That’s why
it is important to have a link between cyber space and real society to
establish trust. Without a chain between the two, you are trusting
your imagination.
Yes? What’s your point? You take precautions and don’t let your
secrets escape. You think QubesOS Master Singing Key is stealable so
that it’s actually not to be taken seriously or something? That we /had
to/ have the QubesOS devs non-anonymous just because the signing keys
are stealable? I would argue completely to the contrary: we could have
had (some portion of) WhonixOS and QubesOS devs completely anonymous,
and that would be a form of answer to this thread’s topic: “How much do
we gotta worry about this Linux “age verification” BS?”
I believe this is getting way off-topic to AB-1043, so either have a
split, or please get back on track.
Yeah, I also believe to the contrary. I also believe you are needlessly
tone policing, so please argue about my points, rather than brow beating
me to accommodate your whatever-may-be personal tastes about
non-personal interaction on the cyberspace. I really don’t care.
2 Likes