[AmericanChopper]

> Is there something I'm missing that makes this a hard problem?

Yes. Pretty much the entire security model of Signal underpinned by this UX compromise. The way signal works at the moment, you sign up for an account with your phone number, your device generates a secret, and that secret is used to secure all your communication. You can pass that secret around devices (as long as you have a device that has it - or just the original phone, I can’t remember). You are also responsible for making sure the people you talk to are really who they say they are. When you first add a contact, it’s up to you to make sure they’re not an imposter, and if they have to reset their account their secret changes, and you have to verify who they are again. If somebody takes over their phone number on a new device, they have to generate a new secret, and while they may succeed in impersonating the person (depending on how vigilant their contacts are), they at least won’t get access to the message history.

To allow for recovery of message history, you have to escrow the secret somewhere. If you give it to the service provider, then the security model is thrown out the window, and you just invented FB Messenger. If you give it to the user to escrow, then you’ve just kicked the can down the road, because a consumer is just as likely to lose a secret as they are their device, and the ways they may choose to store it will make the whole system less secure for essentially no UX gain.

This is an unavoidable trade off. If you want the service provider to be able to recover your account, then they (or at least somebody in addition to you) has to have access to your secret. If you want your messages to be private, then you can’t allow for a 3rd party to be able to recover your account.

[saurik]

> To allow for recovery of message history, you have to escrow the secret somewhere.

You seem to be missing the point here: this isn't even about storing your data on someone else's computer with some kind of key escrow, this is about local backups not even working. Apple only recently implemented iMessage "sync", but before that (and still now), iMessage data was backed up to your Mac and accessible in your backup, without any concern about it being on some server or key escrow issues. Signal is simply missing the ability to get your own data out of the app on iOS. (And like, to really underscore how this is not a fundamental issue with Signal, their Android app does have a data export feature. They just don't think this is important enough to prioritize for some crazy reason.)

[AmericanChopper]

Yeah that’s true. They should allow encrypted backups to be stored in iCloud backups (they intentionally exclude this for some reason). But even then, this is a feature that will only ever be used by highly motivated individuals. The Android backups are useless if you lose your 30 digit secret. I agree their position on this is shit, but I can’t imagine it’s a barrier to mainstream adoption.

[kristofferR]

It is a massive barrier, people won't switch to secure messaging if it's unusable.

[AmericanChopper]

As a messaging service, it’s certainly not ‘unusable’. You’re claiming that the ability to permanently archive message history is an absolute minimum requirement for consumers (and that a service that does not offer this is ‘unusable’). I’m going to put a big citation needed on that.

[ajvs]

How does Matrix/Riot accomplish this successfully then?

[AmericanChopper]

With passwords lol. When the weakest link in your chain is some terrible password your user picked, then all your fancy crypto is pointless. (It also still allows a user’s message history to be destroyed when they inevitably forget your password)

The best solution I’ve seen for this is the BIP39 mnemonics that crypto wallets use (because they face exactly the same problem - making the user the ultimate custodian of the keys). But it’s still terrible and barely usable.

You can also do the 1Password approach and have other users that you trust store all or part of your key material. But all any of the solutions mentioned in this comment do is spread the problem around a bit, not solve it.