N.E.P.T.R

That is why I said sending them. You can’t send reactions that people can also see without RCS. QUIK SMS converts received reactions into the proper format but still can’t send them.

Sending them requires the proprietary RCS protocol. Only google messages and a couple others can do it. Infrastructure for RCS is owned by Google, Apple, and some carriers IIRC

QKSMS has been dead for years. QUIK SMS is a revival QKSMS: https://f-droid.org/packages/dev.octoshrimpy.quik.fdroid

Funnily enough OpenRC is probably the slowest of the inits offered by Artix. The current best in both features and stability are Dinit and s6. Dinit is far more user friendly. Both boot ~20% faster than the others, and much faster than systemd. Generally though, simplicity without expense to features is what Dinit and s6+66 excel at.

Gentoo wiki page comparing inits: https://wiki.gentoo.org/wiki/Comparison_of_init_systems

From the Dinit developer: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

Honestly, I saw it in a video recently that i cant remember. It showed some screenshots of the engineer’s Twitter taking about it.

Artix (Arch w/out systemd) supports many inits. I’d recommend dinit (which is very easy to use) or s6 (which seems more stable on Artix, but less user friendly helper tools). Both are very fast, faster than the other inits.

• There is also Chimera Linux which uses dinit and is very clean imho. A very modern take on making a traditional Linux distro which does things well and uses clean and simple OS software stack.
• Void Linux uses runit
• Devuan (Debian w/out systemd) you can use sysV, OpenRC, or runit
• And obviously there is Gentoo, which supports using OpenRC, with unofficial community guides for some other inits.

I very much doubt it. The only reason Asahi is even installable is because M series Mac were designed to allow installing other OSes. I know that sounds crazy, especially with all the reverse engineering needed to get Asahi to work. But without intentional design on the part an Apple engineer working on the initial M series chip, installing alternative OSes would be impossible.

I think it is worth noting that while what Russia is doing is evil, they are not the only evil players in the game. So many countries are complicit and actively support Israel (monetarily), and most countries do business with USA (mega)companies (like Google, Microsoft, Meta) even with the current regime.

And support for extensions like uBlock Origin.

I still dont understand /e/OS. Just use LineageOS. It supports all the same devices and doesnt lag as far behind. You can choose to run an insecure OS if you like (see: all Windows 10 users) but definitely don’t recommend it to others.

You cannot have privacy without at least basic security. Targeted attacks are not the most common kind of attack by long shot. Threat actors scan for vulnerable devices and use automated scripts to execute attacks. Android is one of the most exploited targets. With an outdated OS your browser could be exploited and used to get a sandbox escape, possibly chaining it into root escalation. It all depends on the vulnerabilities found and the longer you wait the more likely for the “stars to align” for the perfect attack. Look at CVE-2025-48593 for an example, zero-click RCE. In recent memory there was also a zero-click RCE utilizing specially crafted MMS, meaning an threat actor could send messages to all phone numbers and try the attack in mass.

/e/OS is by far the most behind on updating security patch levels of the AOSP ROMs (at ~2 months), iode is ~1 and everything else is better than those two.

Privacy without security is not real privacy, it is a mirage.

Security without privacy is like a fortress with cameras inside, a known threat (eg. Gapps Android).

Privacy with security is like a fortess with no known threats at all (eg. AOSP with timely security patches).

Privacy without security is like a fortress where some of the locks have rusted through and if someone tries they can open the doors. It is like replacing the walls with cardboard. “No one can spy on me now” you say in your cardboard castle.

There is no privacy without security. Android is one of the most widely exploited OSes and every month a dozen or more critical severity vulnerabilities are patched. Being 1-2 months behind on security patches is inexcusable for a privacy project.

They have the best ARM CPUs in any consumer product and very good software/hardware security. I hate Apple because their shit is overpriced and locked-down but that doesnt mean its garbage.

They disregard the risk from the vendor because you are already using their hardware. The hardware has firmware already included which is proprietary, the hardware itself is proprietary, and hardware effectively runs as root anyways. You should already trust your hardware or you shouldn’t be using it. Linux-libre is a purity test, that is it. It is security theater which actually, definitely, really makes you vulnerable without doing anything meaningful. The only time it makes any sense is if you only use open source hardware.

There was drama last year because the (or one?) moderator of fosstodon is a fascist.

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.

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

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.

What has changed?

Here is a blog post by a widely respected cryptographer on why XMPP+OMEMO is not secure: https://soatok.blog/2024/08/04/against-xmppomemo/