I think this is unlikely with Signal since Brian Acton's $50M donation is contingent on them keeping inline with the mission (iirc) and also Moxie being involved is a good sign. Plus, realistically if the company gets ruined you're probably better of jumping ship anyway (as long as there's somewhere else to go - matrix? urbit?).
1) Much (most?) of the time, participants don't get to verify their safety numbers, and in those cases you are at least trusting the server to deliver your messages to the right client. There's a potential vector for man-in-the-middle attack (witting or unwitting) on the server side which shouldn't be dismissed here just because users are "supposed to" verify safety numbers.
2) Their behavior regarding server software might be predictive of their behavior regarding client software in the future. Given network effects, it might not be so easy to leave the Signal ecosystem in the future if your social network is on it, so it's worth knowing right now that it's possible that in the future the client software will also be closed-source.
This is where I feel a little unsure about Signal. It wants access to my contacts, and so it is possible to poison my contacts to get a rogue recipient into Signal. I would like a Signal in which I have the option to manually add contacts. Ideally a hash or key exchange or something, maybe a la PGP...
The UK actually made it work in conjunction with identity federation through the Government Gateway, but then the Government Digital Service got hold of it and destroyed any chances of moving it forward.
Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.
If you believe that this webpage was delivered securely to your computer, then PKI might be practical. Of course, there are a few implementation details with that PKI.
And above you're saying it's about meta data problems in messaging systems. What is PGP's bad meta data story you were referring to?
Essentially, for most PGP workflows, PGP encrypts the body of the message but the entirety of the metadata (things like sender, recipient, subject line, basically anything you’d think of as “metadata”) are fully unencrypted.
You should because any successful centralized messenger is one update away from becoming entirely closed source.
If Signal will reach say a billion users it will be able to do that without significant userbase loss, due to network effect.
> safety characteristics, which as stated are apparently ensured by the client regardless of what the server does
In reality, the contact social graph and the frequency and pattern of messages between users is leaked.
Any global observer can do a correlation attack thanks to the centralized servers (and absence of onion routing).
The client only guarantees security in term of the message content. Who talks to who, when, where, how long, and the historical patterns are secured by the policy of the server provider. Trust in the server is critical.
And, of course, the source code does nothing to do address this concern; they control their servers and can run any secret fork they want. It's a purity test and nothing more.
Wrong. Publishing the server sources allow people to create a parallel and independent service.
That means hard-forking the old server and client and maintain them as an independent project forever.
That's what's stopping me and many other people from creating a community and federated version.
Trust is a personal relationship. I am not making a claim that such trust should be abandoned because they delayed an update and did not transparently and openly communicated with the community about what they are doing on the server side or why. A personal relationship is personal, and what is or isn't a problem in building and maintaining that trust is up to each person.
I do however claim that the placed trust in signals servers is critical for the security, and that the server side security matter. Who runs the server matters and what the server code does also matters.
What operations does your client do? How would you know?
If the client is open source and the build is reproducible and you can built it yourself to compare the binary with the official binary on the app store, then.. yes, you can trust that the client is guaranteeing your end-to-end encryption.
If there is a snapshot of open source code which doesn't match the official binary, you have no way to know what the client you run is actually doing. That's why you should care.
This has nothing to do with trusting Signal, good people. If your threat model is such that you care about secure messaging, you can't just trust a binary that's handed to you.
So the client is open source and guarantees end-to-end encryption regardless of what the server does. Ok, then I honestly don't care. Why should I?
I use Signal for its safety characteristics, which as stated are apparently ensured by the client regardless of what the server does, not because of the server, and I continue to agree with Moxie that federation is a white whale that doesn't solve any regular person problems.