N.E.P.T.R

I dont really understand what you mean in your last sentence.

My reason for saying GVisor is safer is because it is an application kernel which provides traps and emulates most Linux syscalls in the guest with a far smaller set of syscalls to the host kernel, helping to prevent container escapes and privilege escalation. GVisor also fully drops privileges early into start up (before running any significant logic), helping to prevent privilege escalation.

Cgroups is not a really a security feature (from what I understand). It is about controlling process priority, hierarchy, and resources limiting (among other things). You can not use GVisor with LXC.

The UI is proprietary.

In order of most to least secure

VM > Docker+GVisor > Docker/LXC

Docker+GVisor is good middle ground because it provides the guest container with an application kernel in a memory safe language and reduced syscall attack surface to avoid kernel container escapes. Docker/LXC share the kernel with the host.

Being 2 months late to a quarterly patch is still very bad. /e/OS should be avoided.

The embargo on security patches isnt what i am talking about. Once security patches are released, /e/OS takes 1-2 months to patch these vulnerabilities. This isnt because of the embargo but in addition to it! They are by far the worst about this out of any of the alt Android ROMs (2nd worst is iode, at around ~1 month). /e/OS has been terrible about security for years even before all this “Google security patch” nonsense.

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

Just so people known (or a reminder), Grayjay is NOT open source. FUTO is very sus and the cofounder techbro guy (not rossmann) is a fascist wierdo.

/e/OS is terrible for security. They are often 1-2+ monthly behind on monthly Android security patches, leaving their users vulnerable to dozens (i am not exaggerating, often more) of critical and high severity vulnerabilities which are widely exploited. Stay away from that shit.

On fdroid, it reports these anti-features for Xtra

• Depends on not-libre proxy TTV.lol
• Tracks/reports your activity by leaking your IP and Twitch ID to their Russian proxy TTV.lol

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.

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.

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.

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/