I would go with (semi)rolling, either openSUSE Tumbleweed/Slowroll or Fedora. I prioritize fast updating distros because they are better for security (many vulnerabilities go unnoticed because the full scope isnt understood and they are deemed normal bugs), and (unlike Windows) updates on Linux are a good thing, bring new features, crash/bug fixes, and optimizations.

Fedora is very popular, has wide software support, and is very stable. openSUSE is also still pretty popular, (even its rolling edition) is quite stable as well, has good software support, and YaST allows you to do graphical administration on your system. Both take security seriously and use SELinux for security policies.

If you care about security, use Brace for automatic system hardening. It has been developed for years by the former DivestOS dev Tavi, supporting many distros.

Zen is basically Firefox with different UI. It is a security/privacy downgrade from Librewolf. You can configure Zen to have the same security/privacy settings by putting about:config in the URL bar change some of the toggles.

Use either the Arkenfox (also available in the interactive live viewer online) or Phoenix user.js as a template. Basically: disable WebGL, set WebRTC to disable nonproxied udp, disable JavaScript JIT, enable privacy.resistFingerprinting (optionally enable privacy.resistFingerprinting.letterboxing for screen fingerprint protection) and some other things.

Phoenix has some configs for Zen iirc which you can just patch. It is less strict than Librewolf when it comes to fingerprint protections (softening some of RFP’s protections).

If you want to test that the fingerprint protections are working, use this test site by Arkenfox called TorZillaPrint.

Windows has plenty of things to complain about. This type of feature is not one of them.

Example: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Also, in this article some explanation of why nothing should be in pid1 other than what is truly necessary, and any example pid1 program written in C under the heading “So how should init be done right?”

Are these “other features” hard dependent on systemd? If yes, how are they modular (or portable)? “My program can be used on any system with a couple of small dependencies: Linux kernel, glibc, and the systemd Kernel” /j

There are some attempts to use systemd tools independent for it, like elogind and eudev, but see what I mean. Hard forks (with major rewrites) are required because these tools heavily depend on systemd, which fine I understand having dependency, but you cant just use part of systemd since it is to tangled together. It would be nice if mire of systemd code was available as separate libraries so you could further reduce attack surface by building a significantly slimmed version of systemd+feature. I am unsure if you meant modular as in “you can choose to enable them” or as in “you can build without them” or both.

Also, I never claimed systemd ran everything under pid1, just plenty more then the should be, like init plus service manager (and more), not every single systemd tool because that would be beyond stupid and systemd isnt made by idiots.

Compromising/crashing pid1 (which becomes increasing likely when the program is massive) takes down the entire system. pid1 should only be the initial init (which should be as small as possible, basically a stub) and start the service manager as a separate pid. This allows the system to gracefully recover by restarting other processes without fully locking-up/crashing. It is a bad practice.

Disclaimer: I use systemd distros. I dont hate systemd, I just like the ability for alternatives to flourish without fighting an uphill battle.

It has major project scope creep (does too many things that arent init or service management), isn’t modular or portable, only just gained support for muslc, it runs most of its init and management things in pid1 (which is a security and stability issue), it is a massive C program (large attack surface), it isnt very fast when compared to any other init (especially s6 or dinit which boot in under 4 seconds), it implements non-standard interfaces which just encourages further dependency, etc.

Systemd is like the Walmart of Linux OS tools. It replaces many other options and does things good enough (not the best, good enough) to make it worth it to use them and their ecosystem, and they make things simple to use. But just like Walmart, they undercut other options, stifle adoption, until they are the only shop in town.

Dinit does everything I need out of service manager, has similar command utilities and syntax to systemd, is much faster, simpler and cleaner code, avoids many of the pitfalls of systemd, supports user services. s6 is pretty good to but kinda terrible UX.

The simplest answer to why I dislike systemd is that with all the major distros using systemd, it will become harder and harder to use most Linux software without systemd and its growing set of utilities. If systemd made an effort to work with the community to implement standard interfaces then alternatives could flourish without requiring large on-going patches to much of the Linux software ecosystem. It will only get worse from here. Systemd is (basically) the init of Linux and I think that is sad.

The other problem with Matrix for me is that Element call (the protocol) is not present in most public instances and isn’t very straightforward to selfhost. The default is jitsi which is not E2EE. Pretty major IMO because if Matrix is supposed to be a Discord alternative and supposedly E2EE but VC isnt encrypted, pretty yikes.

Also they have claimed for years that they have forward secrecy. Has something actually changed recently?

Where did you read that Signal uses MLS? I could not find any claims of using MLS on Signal’s specs page or their GitHub repo. Also MLS doesn’t mean anything on its own, see Soatok’s blog on MLS.

Soatok is currently in the process of writing a blog post about another vulneribilty they found in Matrix’s encryption, and with Matrix’s history of numerous vulnerabilities, I would stay away from that shit. No matter how “good” the algorithm is in theory, it is all about implementation. Matrix also has very brittle encryption, often times many messages will become unrecoverable, which is terrible UX.

You’d be better off just selfhosting XMPP+OMEMO, with the caveat that it is also flawed and leaks plenty of metadata.

The best alternatives to Signal (but not Discord) are SimpleX and Briar. Both are significantly better than XMPP/Matrix for privacy and security.

It is also proprietary.

Maybe the got their shit together since I last checked, but hqving that history and being at the very least 1 month (usually more) behind for years is a very bad look for a ROM that bills itself as private and secure.

According to this well known comparison table they still havent changed: https://eylenburg.github.io/android_comparison.htm

They also leave plenty of proprietary binary blobs in the ROM.

/e/OS does not take security seriously. They are often 1-2+ months behind on Android security patches, leaving you vulnerable to literal dozens of high severity vulnerabilities. You would probably be better off with LineageOS.

Lol

It still isnt great. Better than DeltaChat/Matrix but decently worse than Signal’s security.

OMEMO is better than nothing. Much better than OTR or PGP (looking at you DeltaChat), and the biggest problem seems to be the metadata and old versions used in some clients. The encryption (of message contents) at the very least is decent.

OMEMO is better than Matrix’s encryption, which the later doesnt offer proper forward secrecy and breaks all the time leaving messages inaccessible.

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

From the OMEMO XEP specification under section 2.1 “Threat Model” https://xmpp.org/extensions/xep-0384.html#reqs-threat-model

The OMEMO protocol does not protect against attackers who rely on metadata and traffic analysis.

Off-topic, I would also like to add that the spec says " It has been demonstrated, that OMEMO provides only weak forward secrecy (it protects the session key only once both parties complete the key exchange).", citing https://www.cypherpunks.ca/~iang/pubs/dakez-popets18.pdf

The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content. Look under sections 1.2 and 4.4 to see what I mean about there being no mention encrypting other data (eg. recipients and room names). This means that sender/receiver are (most likely) not encrypted. I don’t think (though I don’t know for sure) that room names are encrypted either.

What happens if you communicate/participate in an encrypted chat/user on another server? Could the server owner now see the other unencrypted data and metadata?

Also, just because you self host it doesn’t make the unencrypted (meta)data any less dangerous. That just makes your server the point of failure. By your logic, why encrypt at all? It all lives on your server, it is only a problem if someone has access to your server. Networking is encrypted with TLS anyways, so why bother. /s

You can use the WebCord app for Spacebar.

OMEMO leaks plenty of metadata; most things other than message contents are left unencrypted. Many of the mature XMPP use different OMEMO versions (which can be hard to tell when the client doesn’t clearly state the XEP versions, like Snikket). I spent 40 min scouring Snikkets website and source repo without any clear way to determine what version of OMEMO they bundle. I said OMEMO+XMPP because no matter how secure your protocol is, the actual implementation by your largest userbases determine real-world security.

And lastly, just because “serious institutions and governments” use it doesn’t make it more secure. Many European governments use Matrix, and that has even worse security, breaks forward secrecy, doesn’t encrypt basically anything other than message content, etc. Many governments have critical systems that run unpatched Win 7 or older. My point is that security is independent of adoption.

Did that fix any of the underlining issues with OMEMO use across XMPP clients, such as odd/opaque choices by the OMEMO maintainer, or the fragmentation of OMEMO versions used by clients (most being very out-of-date)?

Let me be clear: I am NOT anti-XMPP (or even OMEMO). I would love to see it succeed because I much prefer it over Matrix and other alternatives. My problem isn’t with the technology, just the implementation.