[moxie]

Right now if you re-install Signal on your device, you lose all your messages. That's already a very bad user experience, but imagine how much worse it would be if you lost your entire address book in that moment as well.

Right now that's not a problem because your social graph is in the address book on your phone, and isn't managed by Signal. This is one of the primary reasons that Signal uses phone numbers for addressing: it leverages an existing user-owned and user-managed social graph. However, what we've repeatedly heard from users is that they don't want addressing to be based exclusively on phone numbers for a variety of reasons.

If we're not using that social graph, then where does the Signal-specific social graph live? For every other app in the world, the answer is that it lives in a server-side plaintext database. Snapchat, WhatsApp, Telegram, Matrix, Wire, FB Messenger, Skype, etc etc... they're all just storing your entire social graph in a plaintext database (along with a bunch of other stuff, like your groups, profiles, etc).

Given the way that technology has developed (devices are fundamentally designed for a world of clients and servers), it's probably not possible for us to build something that makes no use of servers. Instead, we've focused on building something that doesn't store or transmit any sever-side plaintext.

For instance, when you set your Signal profile name and avatar, that lives "in the cloud" so that other Signal users can retrieve and display it. But it's encrypted (https://signal.org/blog/signal-profiles-beta/), so only your contacts can see it (not us).

With Signal Private Groups (https://signal.org/blog/signal-private-group-system/), again we have to store data "in the cloud," so that there's a canonical data source for group management, but again all of the contents are encrypted so that only group members can see it (not us).

In this case, we're using Secure Value Recovery to ensure that a future addressing scheme that's not based on phone numbers is available across app reinstalls, phone switches, phone loss, etc. We could have just done what every other consumer messaging app in the world has done (store it in plaintext on the server), but we built this instead. It is the most user-friendly option that we could conceive of while still being privacy preserving, and took a lot of engineering work.

We're going to keep looking at all the feedback we've gotten, though, to try to make it the best experience we can.

[sliken]

Currently signal is asking for a pin periodically to allow migration to a new device every few years when a user gets a new phone.

Instead of typing in a pin few days/weeks for years, why not just have an export feature that users can select. Have users fill out an encryption key, then 1 minute later when they grab their new phone they can type it in again.

Ideally this would work from the desktop client, a tablet client, and phone clients. So if my device dies, is stolen, or sold I can restore my history from any other signal client I run.

Or maybe use the IOS approach which allows users to cloud sync to keep history (if they want), or to turn it off, which is less convenient, but more secure.

Either approach would save 10s or 100s of pin entries, and still provide a good user experience when switching phones.

[godelski]

> Right now if you re-install Signal on your device, you lose all your messages. That's already a very bad user experience, but imagine how much worse it would be if you lost your entire address book in that moment as well.

Why not just allow users to load their data into the cloud with a pin or password? My friends that use Signal because I pressure them into it (remember, that's why a lot of people use Signal) just want a one click upload/download. Generally these are also iPhone users, which currently doesn't allow this. Why not just give a one-click option to sync into drive or iCloud? Make it optional too (for the privacy folk who are generating your userbase). Doesn't this solve the whole problem?

[mnm1]

The point is not to force this idiocy on people. Losing my messages and contacts when setting up a new device is actually a great feature. I regularly delete them and signal even has a feature to do so automatically. And forcing people to create a pin in the ui is just lousy ux. Until I read this article, I had no idea what that meant and just wanted it to go away. Now I want it to go away even more.

Edit: it's especially stupid if you can't use a pw manager with it. I haven't tried it because I don't want to set one. Once I'm forced, I'm going to ditch signal. Fuck that.

[tgsovlerkhgsel]

> Right now if you re-install Signal on your device, you lose all your messages.

Right now, if I re-install Signal on a new device, it will (hopefully) prompt me for a Signal-generated passphrase that I've stored very securely, and then allow me to restore everything, messages and address book, from a backup that I've diligently made and stored under an additional layer of encryption together with the rest of my data.

Will that facility remain available? Will the backup remain encrypted with the strong passphrase, or will any app with access to external storage be able to exfiltrate something that the Signal Foundation would be able to decrypt under the assumption that SGX is broken?

While I've so far been impressed with Signals' choices (prioritizing security but staying usable), I'm extremely disappointed with the new reliance on SGX, and forcing me into this scheme would likely get me to ditch Signal.

In particular, if I get a dialog forcing me to set a PIN, I'm out (at that point, Signal will be broken for me anyways - I'm using it to talk to very non-technical users that react to UX changes with a blank stare; they won't be able to use the app if a mandatory modal popup shows up, and flying over to teach them how to deal with it isn't exactly an option right now.)

I use Signal so I don't have to trust opaque stuff happening at a third party. From my understanding, Secure Value Recovery relies heavily on SGX, and becomes mostly equivalent to plain text (brute-forcing a short PIN) if you don't trust SGX.

[Arathorn]

> For every other app in the world, the answer is that it lives in a server-side plaintext database. Snapchat, WhatsApp, Telegram, Matrix, Wire, FB Messenger, Skype, etc etc... they're all just storing your entire social graph in a plaintext database

This is true for today's Matrix network, but we do have peer-to-peer Matrix working now too (as previewed at https://fosdem.org/2020/schedule/event/dip_p2p_matrix/) which stores the metadata purely on the clients. There are no servers, other than rendezvous points to seed the network. (It's still vulnerable to traffic pattern analysis, but we're working on that - and Signal suffers this even more).

It's also worth noting that because Matrix doesn't tie identity to phone numbers (or anything else), the 'social graph' which is built up is of limited use if it's built up of anonymous personae.

[Multicomp]

I have two comments, one about the signal pin implementation as it exists now, and one possible Avenue forward to obviate the need for signal pins under certain circumstances.

for signal pins today, there should be an option to not be reminded of it because the user has a password manager. The option to not remind could be buried in the settings with a big scary warning that says if you do not get reminded again you will lose everything.

Signal pens can be bypassed entirely in the cases where users have multiple devices such as a linked phone or desktop.

One device sets a strong alphanumeric pin and sends it to the server. Users can share an ID unique to each signal installation on each of their devices. Each individual device has the ID for every other individual device. For each device that does not know the signal pin, it can request it from a device that does have the signal pin and or the device that made it. If a signal installation has the pin and gets a request for the pain from another device ID that it knows about, it provides it.

This device ID exchange behavior is used in syncthing to support e2ee peer-to-peer file sync, and could be used for syncing metadata in the situation where one device has its installation lost or reinstalled and needs to be repulled from the central servers.

An existing device(s) is told the Id of a new device and the new device is told about the existing device(s). None will communicate with the other without already having the user enter the device ID.

Once the two installations have handshaked, the existing device tells the new device what the seignal pin is and it can download it from the signal server.

For users who do not wish for cloud storage could have their device treat another device as the canonical source for the data post handshake and the data could be synced over lan or using stun/turn.

[binarysneaker]

Yeah, I get it. My non-technical wife, brother and friends didn't.

[balladeer]

If Signal PINs came with a feature that made it possible for me to not have my identity tied to a phone number I'd have understood (and accepted?) this release and rollout better.

[apayan]

moxie, I want to thank you and the entire team at Signal for all that you're doing to further e2e crypto and making mass surveillance more difficult for nefarious actors around the world. You're making everyone's communications safer.

[wl]

> Right now if you re-install Signal on your device, you lose all your messages. That's already a very bad user experience, but imagine how much worse it would be if you lost your entire address book in that moment as well.

How about letting people back this up? There's no way to do this on iOS or in the desktop app. You're solving a problem of your own making with a solution your core audience of privacy conscious users does not want.

[fao_]

I'm not sure why you're being downvoted? Backups are an essential feature of chat apps, and it seems pretty sane that a lot of Signal users don't want any information stored in the cloud, full stop.

[polack]

There must be at least 99% of the users that have phone number contacts only, because dealing with usernames is a hassle to begin with. And why not store username-only contacts in the phones normal address book to begin with?

Why force this "feature" on everyone? There is ZERO reason for Signal to do this. I might as well use WhatsApp if you're going to start doing this shit, but I guess that's the point.

[tfehring]

I can see why the ability to store a social graph and other metadata on Signal's servers would be a useful feature for users who don't want to tie their Signal data to their phone number and/or a plaintext social graph, and it would make sense to give users the opportunity to opt into that functionality. But for those of us whose social graph is our phone's contact list, having it forced upon us is a significant step backwards in terms of UX while adding essentially no value.

One of the things that made me optimistic about broad adoption for Signal prior to this change is that it was basically zero-friction for Android users to use Signal over the stock messaging app, aside from the few seconds it takes to download Signal and enter your phone number. But bugging the user for a PIN all the time is a significant reason to stick to the stock messaging app (or any other one, for that matter) and makes it a lot harder for me to recommend Signal in good faith to friends and family who don't care about privacy.

[fidelramos]

I think you are overreacting. Other, more popular messaging apps, also have prompts and yet they are used by hundreds of million of people.

In my opinion as power users we forget what regular users want and need, and are not willing to give up a little of what we like. But think of the benefits (phoneless sign ups and much much better private groups, to begin with) and tell me they don't outweigh the cons (a PIN prompt once every 2 weeks, in the marginal case).

[ryukafalz]

It’s frustrating that we can’t still use a local address book for this. vCard is an extensible format, so a contact vCard could very well contain a Signal-specific identifier. I don’t know if the various mobile contact APIs support this though; I suspect not.