Signal Secure Backups

Also unless everyone use gpg, email isn't very secure nor confidential.

I tend to use notes on my smartphone for information I want to keep that are encrypted and synchronized on my desktop when reaching home. Having said that I often forget to copy a message to a note because it is a manual process and it is sometimes not trivial to anticipate that an info will be important enough in the future that you need it again.

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

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".

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.

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.

You (and Signal) can't control how the recipient handles your messages if you're not using disappearing. They could be copying and pasting your messages or taking screenshots. I don't see how the backup feature is any different.

(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.

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

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.

> 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.

Choice to always 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.

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.

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

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

The new offering is reasonably priced imo.

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.