Every discussion about encrypted messengers has to begin with the assumption (ideally backed up by actual technical efforts) that the client software is secure.

Every discussion about encrypted messengers has to begin with the assumption (ideally backed up by actual technical efforts) that the client software is secure. If you can’t make that assumption, there’s no need for any security mechanism. You could just as easily say “why use end-to-end encryption, just send data through the servers in plaintext, since a client compromise could functionally eliminate any protection offered.” In practice what designers do is they try to build the most secure system they can, under the assumption that they can prevent a forced compromise/update of the client. To do anything else makes the entire problem foolish, because then nothing works. In practice, there are real (if not perfect) defenses against a forced client compromise. From a technical perspective, Signal uses reproducible builds, at least on Android. They are also legal: we haven’t seen any court case where a US company has been forced to push software updates, although we do see routine attempts by law enforcement to gain data from back-end systems —- eg Yahoo, Lavabit. Nobody says Signal’s client defenses are perfect, and we aren’t yet in a world where client compromise is absolutely ruled out. But the problems of designing a secure back-end and a secure client are largely separable. You can work on both at the same time, and being imperfect in one area does not justify a bad solution in the other.