Whether to use encryption is a per-room setting, not per-server. It’s controlled by the person who creates the room, not the server admin. It’s on by default, and cannot be switched off later.
Rooms can be created without it because that makes sense for large public rooms, like those migrating from IRC, where privacy would defeat the purpose.
Keybase was popular with some Hacker News users for a while, but now that it’s owned by Zoom, anyone concerned about privacy ought to think twice before using it.
XMPP might be worth considering if you’re hosting for yourself and all your contacts. I suggest avoiding it for public use, mainly because features are piecemeal and coordinating them across everyone’s clients and servers is a bit complicated. (Also, I don’t know if there’s a good XEP for encrypted search.)
Back when encrypted search was being developed for the Electron app, I think someone had it working in a standalone browser as well. Perhaps that was with the help of a browser add-on; I don’t remember for sure. I suspect github.com/t3chguy would know, as he seems to be active in discussions of that feature. It might be worth asking him about it.
Does it have feature parity with Element yet?
Not yet. It’s in beta.
https://element.io/labs/element-x
EDIT: Nheko is NOT a mobile client.
If you specifically meant mobile, you could have said so. Your statement was, “every other client has even more drawbacks when it comes to E2EE.” Nheko disproves that statement. It also suggests that some alternative mobile clients might handle E2EE at least as well as it does. You might want to try them.
By the way, text search with end-to-end encryption happens to be tricky to implement, and Matrix projects aren’t funded by corporations with deep pockets. Tempering your expectations regarding development speed is probably worthwhile here.
Correcting some misconceptions…
Element for Android doesn’t support searching in encrypted channels
That’s true of regular Element for Android, but it’s being replaced with Element X (which is built with Rust). I would expect search to be added there if it isn’t already.
and I think you can’t use E2EE in the browser at all(?)
I have done it in Firefox, so that’s false. Perhaps you had trouble with a specific browser?
plus basically every other client has even more drawbacks when it comes to E2EE.
Nheko handles E2EE just fine, so that would seem to be false as well.
Since you’re looking for recommendations, it would help if you said which clients you tried and what problems you had with them.
In case you haven’t seen it, you can set a Features: E2EE filter on this list:
https://matrix.org/ecosystem/clients/
Not really an answer to your question, but just to make you aware of some options:
Have you considered using subkeys for each of your machines, signing things with those, and keeping their master key someplace safe? That would limit your exposure if one of those machines is compromised, since you could revoke only that machine’s key while the others remain useful (and the signatures they have issued remain valid).
Are you setting expiration dates on your keys? That can bring some peace of mind when you lose your key/revocation data.
Depends on the particulars, and on the needs of the individual.
That’s not really how things like security works.
If that were true, threat modeling wouldn’t exist. ;)
I think some people just go crazy for something that’s not big tech, and then quit looking at the particulars.
I expect that’s probably true. It’s safe to assume I’m not one of them, though. Cheers.
So it could still be considered less secure than N.
It could be, or it could not be. Depends on the particulars, and on the needs of the individual.
Mind, I’m not going around presuming to tell other people what’s better for them, as one or two others in this thread are doing. I’m just stating what’s a good fit for me.
I use it because, contrary to what that scare piece you linked would have the reader believe, it’s better for my needs than the alternatives.
(I’m no stranger to software development and security, by the way. I understand the pros and cons.)
You’ll have to trust an additional party when getting your apps, and updates are often a couple days behind.
I know how it works, and in this case, that’s fine with me.
F-Droid has an excellent track record; better than many developers have. And I’m not addicted to having the latest versions of everything on the day they’re released. In fact, not immediately jumping on the latest versions has saved me from nasty bugs more than once.
Part of what I value in F-Droid is the additional layer in the build/release process, because it makes tampering more likely to be detected.
It’s still nice to know a tool like obtanium exists, though. Thanks for the link.
If new versions don’t make it to F-Droid, they might as well not exist for me. There are only a couple of apps that I find important enough that I’ll spend time manually building/pulling/installing, and a Lemmy reader isn’t one of them. Thanks for the tip, though.
I start with whatever is on F-Droid, and narrow it down from there.
Jerboa was the only option there until recently. I see Voyager and Eternity are there now. I’ll have to give them a try.
we have no real way of knowing where the spyware is. It may may be baked into the main OS, the added apps or other.
Or in the hardware, like the baseband processor or even something more obscure. Replacing the OS won’t help with that.
Your current approach of talking raw SMTP is likely to be more hassle than is worthwhile, and since the days of permissive SMTP servers are long gone, might not work at all.
Since you appear to be using an Debian-based Linux distro, I suggest this approach:
apt install dma/usr/sbin/sendmail command (which comes with dma or exim) to send messages from your scripting language of choice.If you prefer to receive messages as SMS, note that most major mobile carriers maintain an email-to-sms gateway for this purpose. Some web searches will probably lead you to the one for your carrier. They usually accept email at an address like 123456789@sms-gateway.example.com
“some people use” ≠ “everybody wants to use”
(And are you sincerely suggesting WhatsApp, which is run by one of the largest and most aggressive privacy invaders the world has ever known, as a privacy friendly application? I would suggest re-thinking that position if you want to be taken seriously.)
but you have no direct connection from this resource to harm you claim it causes?
The connection is very clear, because you can see what domains are on the list.
So you’re lumping this resource into a bucket with other resources that were malicious
You’re saying a dev using this list […] needs to convert their FOSS use-case to yours?
[…] the argument I feel you’re making.
Please stop putting words in my mouth. As you seem to be arguing in bad faith, I’m done with this conversation.
You’re getting into very sketchy territory by saying a dev who is using a public GitHub repo to solve their problems needs to take it down
No, I don’t believe I said any such thing. Since you mention it, though, I think taking this list down and removing the false positives before bringing it back up would be the responsible thing to do.
In the interest of specifics, can you point to where this specific list has done harm?
I know from personal experience and investigation (both as a user and on the admin side) that there are now many cases of privacy-focused email addresses being rejected, or even worse, accepted and then silently black-holed, due to the domains being inappropriately added to lists like this one. I don’t know of a place where people report such cases so they can be documented in aggregate, but if I find one, I’ll be sure to bookmark it in case your question comes up again in the future.
This is misleading. Matrix respects the e2ee setting that you choose when creating a room, and it’s enabled by default.