For example, their assertion that "... metadata is abundantly available here" appears to be patently false, given [0].
0: https://www.aclu.org/blog/free-future/new-documents-reveal-g...
Whether or not such metadata is available to adversaries (either through OWS or gathered elsewhere) depends on who your adversaries are and whether or not a corporate entity can be trusted to be completely transparent about what kind of data they retain.
As for [0]; even if no relevant metadata is collected today by whoever owns the servers, nothing stops the party providing the service from doing so tomorrow.
So the less than perfect steps we have been seeing recently (widespread transport encryption in email, end-to-end encryption in WhatsApp and Signal) are a huge improvement.
Conversations.im was (or is, haven't checked in a month) logs encrypted chats on cleartext by default, and history shows why that is a bad idea [0]
Until today I haven't seen a single XMPP that protects metadata, the roster is always on cleartext, to support omemo you are storing yet more info always, etc.
If the answer to Signal issues is XMPP, there is a lot of work to do before to even suggest going this path.
This is a point I see bought up a LOT. I don't believe it to be useful however - proceeding down this rabbithole rapidly leads us to a place of advanced paranoia where we can't get anything useful done. Once you start assuming actual malice on the part of the software developer, even open-source code with the ability to run your own service doesn't protect you - there's multiple ways backdoors can be inserted in sufficiently subtle ways it's extremely unlikely they will be spotted before it's far too late for you.
> using strongly identifying codes (phone numbers) as the required identifier — i.e., it is nearly impossible to create a throw-away accoun
Identifiers are only valuable if there is something to link that identifier to. Account creation time and last active time are very unlikely to be valuable to your adversary (for any definition of "your adversary" you had a chance at defending against in the first place). In other words, as long as the only data they have is your phone number, then that's not helpful. All that is is a record of a) this phone number exists (which is not secret) and b) this phone number uses signal (which isn't a secret either to any even mildly motiviated attacker).
When it comes to security, today's advanced paranoia is next year's common sense. Remember that folks used to think that telnet over the Internet was harmless.
Would OWS refuse to implement a court order directing them to collect and forward metadata? I don't know.
Let's assume OWS is playing nice, and they really don't store any relevant metadata. How can we be sure that a third party is not eavesdropping their communications?
Even with end-to-end encryption, given enough time, an attacker can easily build a user relationship network, something _very_ dangerous in the wrong hands.
If you really care about privacy, you should consider options like BitMessage, Onion.chat, Ricochet, Tox or GNU Ring. Or, as a middle ground between those (which are quite mobile unfriendly, due to its P2P nature) and Signal/WhatsApp/Telegram, a federated service like XMPP (as the article suggest) or Matrix.
Even if it is claimed that the metadata miraculously wasn't collected (provided it really wasn't collected under some other publicly invisible arrangement, which is still technically doable) that doesn't prove it is impossible to do so, especially as the result of another secret request.
I don't see the "FUD" in the article. It seems very popular using labels instead of talking about issues, but please, please don't.
The phone number problems were known since long, and the Signal's explanation "it's easier for the average user this way" doesn't explain why other alternatives aren't even allowed.
It's obvious there are certain goals behind Signal, and those with different goals have to organize themselves. What they surely can't do is claiming to have right to decide what Signal (as a company) does. If those who have clear needs want to introduce their own solution, they surely have to demonstrate what the Signal doesn't solve, and that's surely not FUD.
There's nothing unduly alarmist about the article, but it makes appropriate claims about (among other things) the security limitations that Signal has resigned itself to by remaining unfederated. Read TFA.