But Signal isn't just a chat app, it's an app with a very strong focus on security, and you can't have backward compatibility with security. Otherwise you end up with some servers still implementing SSLv3 years after its due date, or GPG with settings that make it insecure by default. You must force everyone in the ecosystem to use the latest version of the API, but even that is not enough: if there's an issue with the client (the issue in the article could happen with a third party) you must find a way to force it to upgrade; if they dont want to it's better to block them, but at this point if you need to choose where to best spend your resources you might as well block everyone else.
Opening the service to other clients widens the potential surface area of attacks. It must be considered with a lot of care.
> You must force everyone in the ecosystem to use the latest version of the API
Couldn't Signal just announce a "flag day"[0] in advance and say that their servers would block connections from clients that don't support a specific version of the API by that date? For non-essential upgrades, the API change should be announced well in advance, but client developers might be given just a few days notice before security patches become mandatory. (Given the circumstances of this bug, though, perhaps several months of leeway would be more fair).
They could, but again it's not just about the API, the client itself must also be secue enough. That means enforcing security in some way to third parties, or just blocking them until they've solved all issues. And in practice if you let people migrate at their own pace they just won't migrate until clients complain.
It's not at all clear that the messaging ecosystem would be better if Signal could say "We won't let you send this message to your friend because we think their client isn't as secure as ours."
I'm sure there are cases where a third party client would be less secure and Signal would be justified in refusing to relay messages to/from that client, but what about situations, like the current one, where it is Signal itself that is insecure? To be consistent, shouldn't Signal have to block their own client until they fixed the issue?
Even if you accept the idea of Signal having a (inconsistently applied) veto over which apps are allowed to use its infrastructure, how far do you take it? Should they deliberately brick official Signal clients running on versions of iOS or Android that are deemed insecure? Should they require that the phone manufacturer is "trustworthy" so that it doesn't risk containing Chinese government spyware?
Taken to extremes, Signal would need to come with its own antivirus scanner or support some sort of remote attestation of all the versions of all the software running on the phone, to prevent messages being leaked through side-channels. And what would that achieve, other than pushing people to use other, less secure apps?
I think it is a dangerous distraction for Signal's threat model to worry about anything other than making their own app secure, and making sure that the protocol supported by their servers is secure.
Opening the service to other clients widens the potential surface area of attacks. It must be considered with a lot of care.