Technology preview: Sealed sender for Signal

Personally I would be fine if they were in control of the only implementation but provided libraries that could be used to create bindings and gateways for other clients and protocols. My main problem with Signal is that their desktop app manages to be slower and clunkier than the average electron app which is quite a feat on its own.

If they provided a basic shared library or maybe even a stand alone "headless" binary client you could interface through some socket protocol for instance it would let me write a gateway to use irssi or whatever not-completely-trash and actually configurable client instead of that glorified webview that manages to be worse than an actual webpage (still haven't figured out how to change the spellchecker settings in the edit box since right clicking doesn't have the option to change the dictionary like in a real web browser). Also I've just started it and it already uses 158M of resident memory but that's business as usual for this garbage fire that's electron.

As far as I can tell that wouldn't make it harder for them to develop and improve the protocol since they would still completely control that bit of the code.

This feature is an example of what happens when you don't solve the meta data properly in the first place. It doesn't really work that well but unless Signal starts routing through something like Tor (a system they don't and can't control) they are stuck with half measures.

I wish you'd name things and explained what exactly they are doing.

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.

If the feature is well-documented, and you announce it well-ahead of final release, why? Anyone who is actively maintaining their client can add the feature. Those who aren't will either be forked or die. Nobody said it was on the core product to update third party clients. See: AIM/ICQ and trillian.

The answer is always the same:

Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging. The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for themselves.

The simple answer for a lot of questions about Signal is that they aren't trying to solve every problem, or even many of HN's problems.

If phone numbers are super-problematic for you, use Wire. Consider carefully the privacy tradeoff you'll be making, though.

Let'a say a journalist is targeted by a sophisticated attacker. The attackers want everything on the phone,why just calls and messaging? They won't even attack the protocol,they'll first try putting a RAT in place which will have access to everything. Signal does not promise to protect your communication after your phone is compromised(which only makes sense) but now the attackers don't just have access to your messages but also to your contacts. They now know the journalists sources and contacts by the phone number they used.

This approach enables "easy" mode for casual users who prefer phone number registration, while supporting additional privacy for others.

But I want to use signal forfor cross platform messaging. Can't use Facebook without a testable phone number either now.

Phone authentication is better than nothing and lowers barriers to adoption.

Perhaps when manually verifying an identity via the QR code add an option to generate a new id not tied to the phone number.

If later they get a request from the NSA to look at their database, the undelivered messages can no longer be traced back to the sender.

(This is my imagination and it might be completely wrong so please feel free to correct me)

they mentioned spam problem which leads me to believe that if enabled, the sending client will encrypt the whole message using the recipient's public key and put all metadata other than recipient's identifier inside this bigger encrypted envelope. The receiver opens this envelope with its key and opens the smaller box inside which contains the sender's metadata.

What we lose now with this is the server does not have much insight into who is sending messages (by design). This means if you allow sealed sender from everyone, someone could send you a lot of messages which you may not like.

Yes, their servers can see your IP but if they discard it immediately you're safer if the NSA or another government agency reaches out to them.

There is one privacy issue people put pressure on Signal about, and that's the use of phone numbers. Apart from that, Signal has always led the field on privacy issues.

About having to click on images to download them: it should automatically download pictures unless you don't have the sender in your contacts. Auto downloading on cellualr networks might be disabled by default though.

To say Signal is "unreliable" is bull shi*. It's a fantastic product and service that I would gladly pay for but am glad it's free. In the meantime I'll continue to donate as Signal has been very reliable in my years of use.

It won't prevent correlation attacks, but it does make metadata attacks in general harder and less confident. An improvement is an improvement even if it doesn't completely solve a problem.

Signal could probably force TOR connectivity (forcing websockets for those connections), which would conceal the sender even more, but would not stop correlation attacks.

This also wasn't made to stop correlation attacks. This is a measure to reduce metadata being stored on the server. Messages stored on the server won't have a "from" label that can be read by the server.

As James Mickens teaches us: "YOU"RE STILL GONNA GET MOSSAD'ED UPON"

> To prevent abuse, clients derive a 96-bit delivery token from their profile key and register it with the service. The service requires clients to prove knowledge of the delivery token for a user in order to transmit “sealed sender” messages to that user.