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.
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...?
"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.
It certainly is a lot. It's enough for a drone strike.
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.
That's the interesting thing about being E2EE. You don't need to verify the backend. This is a private key and ETH wallet with a separator that is obvious on decryption: YSBwcml2YXRlIGtleSBhbmQgRVRIIHdhbGxldCB3aXRoIGEgc2VwYXJhdG9yIHRoYXQgaXMgb2J2aW91cyBvbiBkZWNyeXB0aW9uCg==
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.
> ...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.
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.
If, as we are saying, the client code is public and one can theoretically analyze the code and prove that messages that go out are indeed only going out encrypted, then that must change something here? At that point at least, you can only be suspicious of the cryptography itself, but I believe that is public too.
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.