Improving first impressions on Signal

The PIN is a security option that prevents a SIM-swapping attacker from registering a new device under your phone number unless they know the PIN. You can opt out of it (and it might be opt-in to begin with). You can also easily opt out of PIN reminders. Both of these options are in Settings -> Account.

As for server state - my understanding is that Signal attempts to be zero-knowledge overall, but they definitely store some state on the server. I believe it's encrypted using your private key that's not backed up to the server. Setting the PIN does not change that.

Server state comment aside, it seems your main complaint is about a pop-up PIN entry UI that can be opted out of? I get that it might seem annoying, but it feels like a fairly weak criticism of a messaging platform, certainly not one that should warrant an impression that Signal is "on the way out"?

I am not talking about the PIN you would have to enter when starting Signal, to get into Signal.

I Googled a bit and found an approachable blog post from the time this all happened, here;

https://blog.cryptographyengineering.com/2020/07/10/a-few-th...

This has refreshed my memory of events.

In short, Signal wanted to store what had been purely client-side information (contact lists, for example) on their server, but - in principle at least - in a form Signal could not access.

The PIN in question is used to provide access to that information.

> Server state comment aside, it seems your main complaint is about a pop-up PIN entry UI that can be opted out of?

The dialog to force the user to set the server-side PIN disabled the app. You either had to do it, or stop using Signal. There was no opt-out.

I had a look at the app now. I found the settings you mentioned. It's not clear to me from what I see there is this if an app-locking PIN, a SIM protection PIN, or a server-side state PIN, or all three rolled into one.

In any event, at the time it happened, the presented dialog was full-screen and could not be dimissed; even if there had been options to disable this (and there were not prior to the full-screen dialog - I looked, in an effort to dismiss the permanent partial-screen dialog) you could not get to them, because it was a full-screen dialog which you could not dismiss; you could not get to the app, and so could not get to settings.

The only option was to stop using Signal or provide a PIN so your client-side state could be stored server-side.

Forcing me to recite my PIN every few weeks is one of the most irritating UX I’ve seen.

I’m sure there’s some smart engineer explanation in terms of cryptography and being unable to recover it if lost. But just let me disable it if I’m okay losing my entire account if I forget it.

Also last time I checked the binding of a phone number to Signal was really bad. I had a friend abandon Signal and I could never sms them ever again.

Yes, they do upload your contact list, but I believe there's a prompt at setup time that allows you to opt out? It might even be an OS-level prompt to the tune of "Signal would like to access your Contacts". Not 100% sure on that one as I haven't set up a brand new Signal installation in years.

It's done to help their user acquisition. It uploads your contacts to match against other contact lists and let you know who's on Signal. I recall seeing a blog post explaining how they are doing it in a fully encrypted way, possibly using Secure Enclave (? though I think the 2021 version of that would probably involve ZK proofs/homomorphic encryption of some kind, and I hope they put some time into that).

I don't recall ever having to set a PIN specifically for that. And besides, a 4-6 digit PIN would be a terribly insecure way to "encrypt" anything server-side :) But yes, that would be a shame if it were the case.

However, there are plenty of opportunities to catch spammers when they make stupid mistakes. I've worked with web bot spam. I could catch a very popular bot brand by observing that it sent Accept header with content that was implausible for the User-Agent it sent. If the code was public, spammers could see `if (browser == safari && accept != safari-like) { spam }` and fix their header in minutes.

There's also a middle ground where the algorithm is public, but it's powered by secret data: blacklists, databases for classifiers, ML models. From accountability point of view data being secret is as problematic as secret code.