It's not the backdoored version
Discussion
Spicy!
In all seriousness, surely someone has gone through the official APK at come point and compared it to a self-compiled version to make sure they basically match, right?
Possibly, but that's a thought I've had before with FOSS. How long would it take for a threat actor or vuln to be found? How many other people think "surely someone else is auditing the code, right?" And doesn't check for themselves. Trust, but verify.
Oh I have looked at the source code myself. It seems legit at protecting the content of messages and I have no reason to believe that has changed since I reviewed it. But I didn't check the source vs the APK.
When I reviewed it the app also uploaded a hash of every phone number in your address book to their server and they'd look to see if they had a public key for that phone number.
Experimental testing after they rolled out username support indicates they aren't doing this anymore (or at least, I haven't been able to trigger it) because I do NOT see the phone number of the person I'm chatting with, even though they are in my address book. This also goes against how Signal claimed the username feature would work. They said the phone number would only appear if it was already in your pgone book. That is a lie.
I'm glad that's a lie, but I'm a bit nervous because it could be something else that is causing my app to not behave as expected. I also saw that the code to rip through all contacts is still in there, so I worry that I might just not have figured out how to trigger it.
I'm not particularly motivated to keep spending my free time on that though. I've moved on to decentralized e2ee apps for everyone except the "I am ONLY on Signal" people, and there's no way Signal is getting permission to my contacts on my main phone. So I don't super care if it's lax on privacy.
I'd rather use my time building the hardware password manager that I maintain, running servers and helping other people do the same, and helping people kick Facebook, Twitter, Google and all the rest of the megacorps to the curb.
Moved to Matrix or SimpleX? If Matrix, and self-hosted, you can use a Bridge to Signal
Matrix, self-hosted, and the Bridge to Signal is unreliable and puts the keys to the kingdom on the bridgge server, which I didn't like.
Unfortunately the protocols are just sightly different (Signal protocol reuses a 25519 key whereas Matrix splits it out into two separate keys) so messages can't just go through and be decrypted at the client end. So it's e2ee from the sender to the bridge, and then e2ee again from the bridge to the recipient.
I ran it for a while, but ended up tearing it down after it stopped working a few times. The only way I've seen that actually keeps e2ee really e2e is using a client like Pidgin which can speak all the protocols and connect to all the servers.
The Signal bridge reliability issues could probably be resolved with some development time and enough people running bridges and submitting feedback.
The security architecture is fine IF (and only if) everyone runs their own personal Signal bridge. This is a critical point because if the bridge is run by someone else, they can see all your Signal messages. As a server admin, I don't want that! It goes against my philosophy and puts my users at risk if the server were ever to be compromised.
It might be possible to give a Matrix bridge your Signal API key so it can fetch encrypted messages from Signal's centralized server, wrap that ciphertext in a Matrix message, have each of the clients decrypt the Matrix message to get the Signal ciphertext, and then decrypt the Signal ciphertext. This would require major changes to the bridge, and to the clients, and optionally changes to the protocol to inform the clients that this message is a wrapped Signal message so it can make it appear from the correct sender (who doesn't have a Matrix account).
So it's similar to the Lightning Network in many ways. As long as everyone maintains their own server, it's great. If you're not running your own server... it gets a lot more tricky and requires a lot more development.
I'm just not interested in putting in that amount of effort. It'd be hard to even pay me enough to do that (I'd say you couldn't pay me enough, but if someone threw a stupid amount on money in my face, I'd probably agree to it). If a team wants to give it a go, I'd be happy to consult for them. For free.
I do think it'd be a huge step forward to have an open protocol that could tie together all these e2ee messengers (Briar, Signal, SimpleX, Session, Tox, Secure Scuttlebutt, Wire, Matrix, etc.). It'd be a giant leap forward even if it's just bridging Matrix to each of these other systems (and not allowing crazy stuff like a single message going from Signal -> Matrix -> Briar to allow Signal users to talk to people on Briar).
Bridging E2EE services will always rely on "handing the keys" as you say to an intermediate you have to trust.
You could possibly fix the issue by running an encapsulated E2EE scheme where the clients use their own network as a connection layer and then handshake with *actual* E2EE between themselves.
e2ee over e2ee. Sounds like both a dream and a nightmare all rolled into one. 🤣