> 2. One of the least popular attributes of Signal (on Hacker News, at least) is its lack of federation and ability to interoperate with third-party clients. This feature is a pretty crystalline example of the kind of protocol change you can make when you control all the mainstream clients, and that would be an absolute nightmare for a protocol where you didn't.
On the other hand, the point of the feature is to partially compensate for a privacy weakness that exists in part because of the lack of federation/decentralization.
If you’re trying to have truly secure communications with someone, having a single party that could theoretically be logging the sender and receiver identity (as easily personally identifiable phone numbers!), timestamp, and sender/receiver IP addresses of every single message is a serious weakness. There‘s a reason people on this forum were up in arms over the NSA’s metadata collection program even though it was limited to the same type of information. As an example – while I’m on the subject of the NSA – if Signal had been around in 2013 and Edward Snowden had used it to provide his leaks to journalists, the metadata of who he was contacting would have been almost as dangerous to him, should the NSA have obtained it, as the actual contents of the messages. For a somewhat less dramatic example, the same would apply to the various Trump administration officials who have been leaking to journalists, apparently using encrypted messaging apps including Signal.
Of course, this is a hard problem in general and decentralization wouldn’t be the whole solution. Indeed, it wouldn’t even be the start of the solution. In the above examples, the most important first step Signal could take to protect the leakers’ privacy would not be any kind of decentralization, but simply allowing users to create accounts without a phone number, allowing them to communicate with an identity not trivially linked to their real-life identity. Ideally they would then access these accounts only through Tor, disable push notifications to avoid leaking identity through push tokens, and avoid accessing them at the same time and through the same pipe as their normal accounts (if applicable), to prevent the server from trivially correlating accounts using traffic analysis; the second step Signal could take would be building those measures into the app itself, since they’re very easy to screw up if done by hand.
However, this scheme, even if implemented well, would still have some weaknesses. For one, the anonymization Tor provides can theoretically be compromised, especially with the funds of the kinds of adversaries that would be in a position to compromise the Signal central servers. More importantly, even if the adversary can’t directly identify the parties communicating, they can still build a web of who’s contacting who, when, and how often, information that can be a source of important insights – including the potential to lead to deanonymization.
And then there’s the case of “everyone else”: people who aren’t going to take drastic measures to hide their identities, who probably don’t need to, but would still like their communications to stay private, including metadata. To stick with the same scenario, consider the internal communications among the journalists at a news organization after something has been leaked to them (or really, in general). From the types of people communicating with each other and the amount of communication, you might be at least able to guess, say, when a major bombshell is about to drop, as well as who exactly is involved. As another example, consider the anonymous op-ed from an official in the Trump administration that the New York Times published last month. The paper has openly acknowledged three top employees as knowing the identity of the author, but learning the names and roles of lower-level employees involved could provide clues as to who the author is. (Of course, the New York Times is largely shielded by legal protections and so probably doesn’t have to take extreme technical measures, but that’s not the point.)
That’s where decentralization comes in. If the New York Times could host its own Signal server, they could attempt to protect that metadata themselves rather than relying on a third party. First consider the case of internal communications. They would still have to worry about an adversary performing traffic analysis at the transport layer, but for internal communications, this is no worse than with a private server than a central one, and sometimes better (if the transport path is trusted); and in general, traffic analysis doesn’t leak as much metadata and is easier to mitigate. Then there’s the risk of their own server being compromised. Admittedly, when it comes to some types of attacks (hacking, as opposed to legal threats), for the Times and most similar organizations, having their own server would probably be a regression rather than an improvement, since their IT staff doesn’t possess the same level of security expertise as Open Whisper Systems. But that isn’t the case for every organization that has secrets worth keeping, and of course hosting your own server would always be an option, not a requirement. On the other hand, they would at least be able to force adversaries to target and actively attack their organization individually, rather than hacking one centralized service and getting everything. In practice I think that would be a significant deterrent, especially for smaller organizations.
What about communications with a leaker? Well, there are a few possibilities, depending on the type of decentralization. In all cases, the news organization could have some sort of mechanism to give leakers accounts on their server (or better, a separate server set up for the purpose). If the system were based on federation, the leaker could alternately communicate to them from an account on a server that they trusted. Obtaining a trusted server wouldn’t be a difficult task for technical users like Snowden, but more so for others. I’d prefer more of a peer-to-peer design where a cell phone or laptop could be its own peer and communicate directly with someone else on their server, without specifically needing to have an account on that server.
In any case, traffic analysis would be much more of a threat for a leaker than with a central server, since knowledge that they were connecting to a news organization’s private server would be much more revealing than merely knowledge they were using Signal. I admit that’s sort of an inherent disadvantage to decentralized designs – but it’s one that can be mitigated using Tor or other types of proxy setups. It’s much harder for a user to mitigate the risks of a central server.
Edit: And for the record, the new sealed sender feature will reduce the risk of metadata collection, but a compromised server probably wouldn't find it hard to correlate a user's anonymous message-sending connections with their main authenticated connection. In many cases, IP address would be enough; in others, you could look at the pattern of messages being sent back and forth in a conversation.