Nobody can verify backend code though, that's always an issue.
This is the case for any e2ee solutions. For instance my company develops CryptPad [1], which is a full open source office suite with e2ee. The server admins can't access your content and you don't need to trust the backend, which just passes messages and store encrypted messages. This is the whole point. e2ee has drawbacks: it's very difficult, if not impossible, to provide indexed search for encrypted content on the server, the client needs to do it which might be impractical.
I have used it a few times in a professional setting even when there is no need for end-to-end encryption, and it is a good experience so far.
I encourage others to try it .
That still does not change anything though. The backend is unverifiable, that's a fact. Why talk about E2EE, I wasn't really talking about that.
Signal for a whole year was running a different server code and nobody even could tell that they added some cryptocoin stuff. On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner.
Except to the extent that the client is explicitly designed to minimize what metadata is exposed to the server.
The server can log your IP, origin of request, client details and everything related to an API call. That's what I'm mainly talking about.
It has your IP, but of course it needs that, as well as every piece of network gear along the route. If you want to hide that you'd need Tor or a VPN.
Of course it does. Just like PGP works fine over untrusted channels - like if I posted a gnupg ascii-armored message here.
e2ee makes all the difference - if two trusted and mutually authenticated clients are communicating with proper e2ee - the best an attacker can do is traffic analysis and denial of service...?
That's already a lot. If the evil secret police knows when and with whom you texted, then they don't even need to know the text of the messages, to link you to the opposition. And then just extract you and then the password with force to get the rest.
But almost by definition, if you have a back-end, there will be meta-data.
There's been a few attempts at getting around it, with "one-to-many" (eg opaque PGP posts to Usenet groups), Mixmasters (remailers) or onion routing. None are AFAIK truly practical with a state-level adversary.
e2ee is a good start, that doesn't mean you don't need to analyse the risks.
The server can not only log IPs, but also locations, client details and a lot more. The API calls aren't proxied, they're more or less direct.
Second, some sensitive parts of Signal backend are verifiable, assuming Intel is not compromised, because they use Intel SGX.
E2EE is only useful for content that is encrypted. Not the API calls themselves.
Use whatever backend you want to store that.
For a while I did run a fork of the Signal Server. Beyond the sheer difficulty getting it to run without the server being updated for a year during the mobilecoin launch, it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information.
While it is quite possible that they had some non-default log configuration (and hopefully the metadata leaking in the logs is fixed), if you can't run the server you can't check what data is being leaked.
Take the E2EE claim with a grain of salt if it is difficult to run a server.
The intent of Signal is to provide confidentiality of message content, not any sort of anonymity. This covers like 90+% of user's threat models and it's focusing on one problem makes it very effective at solving that problem. If one also needs anonymity then communication should happen over something like Tor or I2P.