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 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.
Also do give citations for your bombastic claim that most people don’t want anonymity.
This is entirely dependent on the situation. Privacy is not a black or white thing where you’re completely private or not private at all. Everyone lives some part of their life publicly. I don’t have data on this unfortunately, but typically where I live, people share phone numbers to people they personally know.
The graph of who communicates with whom is precisely the problem. The government can easily correlate that data with all the other data they have on people, and then if somebody is identified as a person of interest it becomes easy to find other people who associate with them. So, here you just proved my point by showing that you yourself don’t understand the implications of metadata harvesting.
This is not within the vast majority of most peoples threat model.
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.
Seriously, what are you talking about? The vast majority of people don’t want anonymity. Obviously Signal isn’t cut out for that! The fact is, most people don’t care about anonymity.
And what metadata can you harvest exactly from a UNIX timestamp and phone number? Signal can tell who is communicating to who, but they cannot read your messages.
What? How is this a red flag? Having third party clients is not good for security.
It’s Proton. What do you expect?
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.
What do you mean by “without proprietary bs”?
Jokes aside, what practical purpose does this actually serve…?
Codeberg for public repositories, cgit (if that even counts) on my own server for private ones