Codeberg for public repositories, cgit (if that even counts) on my own server for private ones

I personally use Claws Mail.

Absolutely essential is using a firewall and set it as strict as possible. Use MAC like SELinux or Apparmor. This is extremely overkill for a personal server, but you may also compile everything yourself and enable as many hardening flags as possible and compile your own kernel with as many mitigations and hardening flags enabled (also stripped out of features you don’t need)

I’ve never heard of nsjail, so I wouldn’t know. But there’s also bubblewrap which is used by Flatpak for sandboxing. It’s very small, although a bit annoying to use.

This.

That’s very wholesome to hear! :) Thank you for sharing. I’m glad it’s not the case.

You can’t teach old dogs new tricks.

I never said anything about E2EE. Please re-read what I wrote carefully.

No support for Monero despite it being requested on uservoice 6 years ago. A Bitcoin wallet (seriously?) which is easily traceable. Important email metadata is also not zero access encrypted (i.e., subject headers, from/to headers) which leaks a substantial amount of information even if the body is encrypted. Not to mention they had clearnet redirects from their onion service a while back, something a lot of honeypots usually do.

Even if it’s not a honeypot, you’re sure as hell not getting any privacy with Proton. That’s for sure.

Well, I disagree about Signal. Proton however, I agree is extremely shady and should be avoided at all costs.

Something at which even the original Signal fails. It has received criticism multiple times (1, 2) for not being verifiable whether it’s been tampered with by the app’s distributor, and also for having included properietary google services dependencies which dynamically load further code from the phone which is also a security issue. Worthy forks solve both of these.

That’s unfortunate. I do hope that these forks don’t go and start making extensive changes though, because that’s where it becomes a problem.

Again, having third party clients would not definitively mean the client is bad. Obviously, if it’s a simple fork with hopefully small patches that are just UI changes, it’s probably not going to harm the security model.

I should have phrased this better in my original post. When I was thinking about third party clients, Matrix and XMPP immediately came to my mind. Not very simple forks. So I’ll phrase this better: “Having non-trivial third party clients is not good for security.” What non-trivial means is left to interpretation though, I suppose.

When you use a client, you are relying on the client’s crypto implementation to be correct. This is only one part of it and there’s a lot more to it when it comes to hardening the program. Signal focuses on their desktop and mobile clients and they hire actual security professionals and cryptographers (unlike the charlatans in this thread) to implement it correctly.

Having third party clients would not definitively mean the client is bad, but it most likely would break the security model. Just take a look at Matrix’s clients.

What? How is this a red flag? Having third party clients is not good for security.

It’s Proton. What do you expect?

Speaking of which, Debian users, how safe are distribution upgrades?

I know. And that’s reasonable of course. I’m sure most of us would agree that proprietary blobs are bad. I’m optimistic that firmware will become more open in the future though.

That’s true. I didn’t think about that. Thank you. :)

Sidenote: If you just want a nice web frontend for others to view your Git repositories, you can use cgit instead.

I’m not a fan of GrapheneOS, but the point they bring up here is valid. There is already proprietary firmware on your computer. There’s no reason why you shouldn’t be updating it to protect yourself from serious exploits. The FSF takes an ideological stance rather than a practical one, unfortunately.