Signal Secure Backups

1. It is non-incremental. This means you'll need about as much free space on your phone as your Signal database takes, and it may take many hours to make if your database is large (mine is 18GB). I used to wake up to find my phone had not even fully charged because it had been so busy writing Signal backups.

2. Once you have it on disk, how do you get it away from your phone? Especially after SyncThing disappeared from Play Store (because it was basically a non-Android app behind a thin Android shell that couldn't easily be upgraded to more modern native APIs), there's nothing super-obvious here.

I would have loved a better solution for local backups, but realistically, $2/month for cloud backup is really cheap, and a pragmatic solution.

The new offering is reasonably priced imo.

If you're curious, the reason that Android's current local backups aren't cross platform is because it was made a long time ago, and it's literally a dump of all the sqlite statements that can be used to recreate Android's sqlite database (encrypted with a strong, random, local key). So not the most portable!

But this new thing is all cross-platform, and in the near future we'll even be making our local backups cross-platform.

Because they don't want to make jumping to the competitor too easy.

Choice to store media locally on the phone.

What I miss with most messenger apps: Archiving old stuff and offload it to a remote device.

Right now Signal is 8GB in size and doesn't stop growing.

> For example, being able to see all media across chats, sort by file size, and optionally group by conversation would make it much easier to clean things up.

I have good news for you: this already exists.

On Android:

Settings >> Data and Storage >> Manage Storage >> Review Storage

This allows you to view all of your media, files, and audio across all chats, sorted by the amount of storage used. You can also delete those files individually without affecting the rest of the chat.

You can also do the same thing within a conversation.

> Our future plans include letting you save a secure backup archive to the location of your choosing

I do that and then sync that folder with another computer using SyncThing.

> The technology that underpins this initial version of secure backups will also serve as the foundation for more secure backup options in the near future. Our future plans include letting you save a secure backup archive to the location of your choosing, alongside features that let you transfer your encrypted message history between Android, iOS, and Desktop devices.

The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit.

FTFY. It's originally Apple preventing its users from easily controlling their own data.

Whatsapp chose a different approach (which is reasonable for their user base) but that means that there is an escrow key. Regardless of your choices, messages that you sent may end up "end to end encrypted" but in reality stored in the cloud with a key escrowed to Meta...

The backup feature seems to be opt-in, i.e. the requirement to write the key down won't be too surprising.

Signal opens themselves up to government coercion and ruined reputation otherwise.

And while I’m here, if you’re implying that Signal is Blut trustworthy, you should step out of the HN bubble and have a look around what everyone and their dog shares through less secure means

(No, this does not really help if you're one of the TouchID holdouts on an older SE)

'the point' is spam protection, alas

Everything on Signal (at least the "original" design from a few years ago, this has started to be adjusted with the introduction of usernames and now backups and eventually syncing) is end-to-end encrypted between users, with your original phone acting as the primary communication node doing the encryption. Any other devices like desktops and tablets that get added are replicating from the original node rather than receiving new messages straight from the network.

This offers substantial privacy and security guarantees, at the cost of convenience and portability. It can be contrasted with something like iMessage, before Messages in iCloud was implemented, where every registered device is a full node that receives every new message directly, as long as they're connected at the time that it's sent.

Today's addition brings Signal to where iMessage was originally: each device is backing up their own messages, but those backups aren't syncing with one another. Based on the blog post, the goal is to eventually get Signal to where iMessage is today now that Messages in iCloud is available: all of the devices sync their own message databases with a version in the cloud, which is also end-to-end encrypted with the same guarantees as the messages themselves, but which ensures that every device ends up with the same message history regardless of whether they're connected to receive all of the messages as they come in. Then, eventually, they seem to also intend to take it one step farther and allow for arbitrary sync locations for that "primary replica" outside of their own cloud storage, which is even better and goes even further than Apple's implementation does.

If done well, I actually quite like the vision they're going for here. I'm still frustrated that they wouldn't just port the simple file backup feature from Android to the other platforms, even as just a stopgap until this is finished, but I think that the eventual completion of this feature as described will solve all of my major concerns with Signal's current storage implementation.

Yeah convenient way to hand your data to a Russian oligarch.

PGP has no forward secrecy and OTR in XMPP lacks future secrecy, multi-device support etc.

Signal introducing end-to-end encrypted backups is exactly how Telegram should've done it decade ago.

What issues? The only issue I've seen with Signal and media files, was on iOS, where users aren't able to download them (copy them outside the signal app).

Those backups are stored locally, are platform-specific (Android-only), and there is no feasible way to automate their transfer to any other device, which means that either you have to manually manage them regularly, or you risk losing your entire message history if your phone suddenly dies (or is stolen, or broken beyond repair, etc.).

This is a true automated, off-site backup feature.

Backups: Encrypted on device. Key stays on device. Server has access to ciphertext.

Yapyaps: Is the backup a backdoor?

The exfiltration of which is as easy as exfiltration of database on device. You're not running an IDS scanning 100% of your device LTE traffic in case that happens.

>isn't that a roundabout way of replacing all of signal's protocol and its forward secrecy with a static key that has no forward secrecy?

It's opt in. And again exfiltrating the backup key is as easy as exfiltrating your messages from your device.

>You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it

You can't know if you're talking to an informant or if your contact is running Android that's receiving security updates or if it's a zero-day on wheels, either. Tech doesn't solve human problems.

TBF Signal already supports automated key-protected backup (and has for years), it's just stored on-device, but there's no way to know what the other party is doing with that on-device backup.

(a) is much simpler if there is a fixed identifier of a user, but that identifier doesn’t need to be the entire key or even part of it — it could be some derived material.

(b) isn’t strictly required but I would be very uneasy about allowing anyone who stole a user’s device to download even the ciphertext of that user’s future chats. Also, there’s an obvious issue that even the ciphertext reveals something about the amount of activity from the user.

(c) requires that the restoring user hold something like a private key, that said key can be derived using the restore code, and that the user’s device does not know the private key.

One straightforward-ish solution would be for the user’s device to generate, once, a key pair, a user ID, and a backup API key. (The ID and API key could be generated server-side.). The restore key is (user ID, private key). The device retains (user ID, API key, public key). To upload backups, the device establishes a secure session, sends the user ID, proves knowledge of the API key, uploads a backup, and receives a new API key. The old API key is revoked.

This means:

1. The device does not retain the ability to download future backups.

2. A clone of a device (say id the device leaks its secrets somehow) cannot be used to upload new backups on an ongoing basis without being noticed because of the API key rotation.

People already can export backups of the messages they receive, in plain text, and publish those on the Internet if they way.

Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages".