It was because of over-represented complaints about phone number requirements that Signal implemented the mistake that is SGX and server-side contact lists. Now the social graph of millions of Signal users is instead centrally protected by Intel's attestation obfuscation and a weak 4-digit PIN. All to eventually support usernames, which normies won't use.
Basically there are many options, none of them perfect:
1. Support phone number contact discovery, with persistence provided by the contacts provider. This is seamless and causes the least amount of complaints.
2. Support username discovery, with persistence provided by passphrase-encrypted online storage. This is painful and risks backlash from people losing access to data. Also, now the threat model must account for or ignore weak derived keys (which is probably most of them).
- 2a. Enforce strong passphrase requirements. Many users will abandon the product.
- 2b. Sync usernames between linked devices (using a generated key). Requires multiple devices, risks people losing data, more complaints.
- 2c. Sync usernames using custom contacts provider fields (e.g. email). Nobody is accustomed to doing this, but it might work. Automatic discovery rates would be low. Possibly requires an odd workflow for people adding Signal contacts by their email/username.
Signal (or, more accurately, one of its predecessors) used to use client-side private set intersection for contact discovery, but this scales poorly [1].
Now they use a solution based on Intel SGX and server-side trusted computing [2].
Because right now, Signal can use your contact list on the device to get your signal contacts. If you replace a phone number with a username, there will be no way to match signal's user to your contact without:
- Having a server to hold your contacts
- Or having signal app to maintain contact list and sync it across devices
Most people will choose weak passwords given the option. And so I think it's the responsibility of the developer to enforce strong requirements (edit: when dealing with data encryption susceptible to brute-force attacks): entropy estimations, 128(+)-bit static keys, etc. If any user has chosen a weak passphrase, and still believes it to be secure, the developer has likely failed.
> when dealing with data encryption susceptible to brute-force attacks
The "brute-force attacks" imagined here are a bad guy somehow controls Signal's systems, or else the US government seizes them and then decides to try to brute force them, right ?
But these are attacks where for various rival systems it was already game over. So your assumption is that Signal's casual users, people who maybe were also considering Whatsapp or iMessage or something, should be required to have a cryptographically strong passphrase so as to defeat this unlikely circumstance, as a minimum?
Moxie's whole deal is that this stuff only works when it's for everybody. If there are a five people in your country who use Signal, guess what, the Secret Police can round them up as suspected terrorists and execute them. Were they planning to bomb the President For Life? Or just organising a pizza party? Don't care, it's just good policy. But if there are five million people who use Signal that's a different matter.
Even if all five million are terrorists, that's numbers where you're going to have to tear up your "no negotiating with terrorists" policy, 'cos there are just too many of them.
I do think considering the average use case is paramount. That's why I think remote encrypted contacts storage should have never been implemented: most people won't choose strong passwords. Giving them the false notion that their sensitive stored data is cryptographically indecipherable is wrong.
As it stands now, people who create a Signal PIN aren't even warned about the security implications of using weak numeric PINs, which is among the worst of all possible worlds.
If this feature is critical, it should have been gated behind prominent passphrase entropy warnings, along with the data being put at risk [1], or it should have enforced actual strength requirements.
Signal is still better than most other messengers. I am mostly comparing it to its former self. And its former self worked flawlessly without needing to upload persisted contacts information.
I think developers have a moral responsibility to make their products as secure as possible, within reason and while still being usable. It doesn't matter if the users care about the benefits. To your second question: no, not yet.
I fully agree with you, and my first question was asked somewhat sarcastically. For the second, my implication is that developers also have a moral responsibility to make their products as private as possible, and SMS verification aint it.
