Signal Secure Backups
signal.org983 points by keyboardJones 5 days ago
983 points by keyboardJones 5 days ago
> alongside features that let you transfer your encrypted message history between Android, iOS, and Desktop devices.
That's actually the feature I've been looking forward to. As I moved vom Android to iOS, I lost _all_ message histories from all messenger apps that use E2EE (Signal, WhatsApp, Threema, etc). The only one that "just worked" was Telegram due to not being encrypted. WhatsApp had a migration app that has to be done when setting up the iPhone, but it failed due to some bug. Signal had backups, but they didn't seem to be compatible between different OS versions.
I've always been able to transfer history, from Android phone to Android phone, when I switched to iOS, I didn't bother since my wife was just going to start using Messages due to its encrypted nature. I really only used Signal with my wife, she only used it because I was using it and it allowed us to send images back and forth without losing quality.
> without losing quality
Signal does lossy compression on images. You can change image quality from “Standard“ to “High“ in its settings but not disable it.
You already can, if you at least set up desktop, you can transfer also message history, though you won't have your media older than 45 days. Maybe it can work as a stopgap before they roll out encrypeted backups everywhere
That's a weird and crappy arbitrary limitation when I could move an arbitrary amount of data between the two devices otherwise. It's the worst part of Signal.
On top of that you don't have that limitation on Android. It's like enterprise IT, where you put up restrictions everywhere on files and then people can upload files to their personal one drive.
It also does not work on Windows clients but errors out. Android and Linux are fine.
> WhatsApp had a migration app that has to be done when setting up the iPhone, but it failed due to some bug.
It's appalling to see how poor there QA is for a company that big. They also have a migration tool for migrations between android devices without going through a Google drive, but this one didn't work either when I tried it two years ago.
doesn't signal also have a transfer to other device flow now?
They have it between two Android phones next to each other for years, but probably not Android to iOS
iOS to iOS works
Android to Android works
iOS to/from Android does not work
stolen phone to new phone does not work :)
> stolen phone to new phone does not work :)
I'm curious about that, has this been tested by someone who "steals" the phone, and tries to migrate before the actual phone owner even realizes?
haha I was actually thinking of the case where you don't have your phone any more and want your signal history, but that's another way to read it :)
you need to be able to unlock the phone and then you need the Signal PIN code for this.
This looks brilliant. I just hope they make it easy to do test restores. In particular, I want to test restore without perturbing my main device. Let me restore using the secret key on a new device.
When I install Signal on a computer it won't show me message history. Will backups allow me to view _all_ my message history on a computer? A big screen is very helpful for browsing lots of messages.
Hi there, Signal dev here. You can sort of do this! You can restore on your new device, and while you will be unregistered on your old device, all of the data is still there. So if you see that something is amiss on the new device, you could re-register on your old device and you'd be right back where you started. This is actually one of the ways we test the feature with our own personal data.
Hey, i have a related question about this:
I have an old iPhone that has all my old Signal messages still on it that I wasnt able to move with me when I switched to Android. Is there any way that I can use these new tools to move the old conversations on my iPhone over to my android phone without losing all the new messages that are on my android now?
That is, I want to merge the two histories.
Using the new backup feature that we're discussing here (once it is available on iOS), you will probably need to transfer your old iPhone's data to an Android device first (either a secondary one or your current one, provided you have backed up its data to a backup file). Then follow https://news.ycombinator.com/item?id=45174779 .
Unfortunately we don't have immediate plans to support merging of histories. As others have noted, you may be able to use third-party tools to merge them together, but that's very much a "at your own risk" sort of thing :)
Multi-device would be a nice feature.
And question: Will a backup taken today on Androis be able to be restored on iOS once released?
Im still out of luck, I want to reinstall my iPhone (not a transfer to another phone) and cannot find a way to preserve chats.
Signal Desktop app on Mac linked, shows chats, but all pics are missing and "Download Failed" if clicked.
And I'm not sure I can import from Desktop back to my erased iPhone...
As of a few months ago, when setting up Desktop you do actually get an option to copy your message history to it
Thanks for the heads-up! Signal on the Desktop has receded for me in the past year when I moved to an Arch- rather than Debian-based distro (Ubuntu to Manjaro). This might get me to reconsider. (Ugh.)
@Signal devs: any reason that the only two options for backup are now "locally" (flexible, but only solves for some use-cases) or "to Signal's special servers" (not flexible; might be legally impossible for many users to enable)?
Because it seems to me that, for much of Signal's (often paranoid) audience, they'd much rather use one of the backup/sync providers they've already verified trust of, than have to additionally trust some new backup service provider.
And it also seems to me that, now that Signal has the architecture to support this, it'd be pretty easy to add additional backup-sync providers.
E.g. in the codebase for the iOS Signal client, you could implement a provider that does incremental backup sync against iCloud (i.e. CloudKit for messages + iCloud Drive for attachments) — allowing the user to use their (perhaps already paid-tier) iCloud account storage.
Same with Android and Google Drive (though Google Drive doesn't have an equivalent to CloudKit, so this might be fiddly; to get good amortized write costs, you might have to e.g. buffer row-like writes in a local replication journal, and then flush them through bulk local key inserts in a locally-partial-fetch-cached set of LevelDB files, where the updated files in the set then get flushed as single whole-file overwrites to GDrive.)
---
Note that in all cases, Signal could/should still fully encrypt this data before pushing it to the provider; the backup wouldn't be expected to be "legible" to the user.
But where, with backups synced to Signal's servers, users need to trust that Signal's E2E backups encryption works perfectly to be able to believe that Signal themselves can't then have access to your backed-up data; it's much less scary to sync to literally any other provider, who won't specifically know that they've got chat data on their hands / won't have any potential to (perhaps after a bad acquisition by a PE firm) begin thinking of themselves as a "data company" who would love to have "chat data" as an asset.
Perhaps they will?
> Our future plans include letting you save a secure backup archive to the location of your choosing
A backup option has been missing for years. Future plans on this particular topic seem to take forever.
I built a micro-journaling app back in the day and wanted it to be highly secure. Backups seemed to be one of the most vulnerable surfaces for that. I imagine their delay might have been a combination of a technological and ideological worries, as that's what I experienced.
How did you encrypt the data at rest and why was that also not good for the backup?
SQLcipher, and i believe the tech was good but at the time, because it asked for a password every time the app open, i figured most people would put a very short and simple password and an encrypted db with a short password was a lot more hackable, especially on Android, if the file got outside the app sandbox.
I suppose now i could do some combination of PIN plus passkey, and have to figure out how to make the database recoverable if people forget their PIN (or lose their passkey?) without me having to store it for them or it being easy to access.
I'm no expert on this, just think the complexity can be a lot more when taking this all into consideration.
It's been backing up to my SD card for years, I've not set up a script to transfer it off-device though.
That only works on android. The same basic functionally, even backing up to a place on the phone, has been missing.
I'm confused, what's stopping you from using one of the backup services you already have on the file after it's done? Since Signal would backup to a file in your phone? Couldn't you just point your service to it and automatically sync every day for example?
The existing backup feature on Android doesn't do an incremental backup.
I just ran a backup, and it was 850MB. So having my phone upload something of that size every day would be a bit annoying.
Most of the major cloud storage platforms don't offer sync on Android.
It's not really a good fit for how the filesystem is used by Android apps.
I currently only do a Signal backup every few months (when I remember), and manually upload it to OneDrive.
I'm not going to pay for their new service - I already pay for too many storage services.
> I just ran a backup, and it was 850MB. So having my phone upload something of that size every day would be a bit annoying
It may be inconvenient but this can be solved by using the features in the app to review your storage and save those thousands of images/audio/file sequestered inside the app out to the filesystem, then delete them from the app. You're not backing up "chats" you're backing up your image library being stored inside a chat app.
(yes I get the argument that you need to store them "in context" so save those and do the rest. there's no way 100% of that 850MB is "must have saved inside the app in chats" data, I'll bet $10 USD on it)
Reducing the size of the backup would solve one problem, but it's really the lack of automation of the process that's the annoying part.
We're partially there, under Storage is an option allowing you to set how long to keep messages and I've set mine to one year. Possible: forever (default), 1y, 6mo, 30d - and it works, my old chat messages (not the whole chat, just individuals) are properly culled over time.
Edit: in context, Google Messages has none of these features and I have friends still married to Google Voice who send me tons of pics. Culling SMS requires using a third party tool to export and re-import etc. leagues behind Signal. None of it's backed up without the same third party tools as well and no built in image management.
Well, just to be clear, signal for iOS did not support ANY backup before this.
Note that in all cases, Signal could/should still fully encrypt this data before pushing it to the provider; the backup wouldn't be expected to be "legible" to the user.
That seems like an unhelpful limitation for a lot of people. For me - and as far as I know literally everyone I communicate with using Signal - the reason to use it is the E2EE for the messages. Once we have the messages or media on our own devices we're fine with having control over them ourselves. By all means also provide an option to create a secured archive for those who want it. But as long as the data can only be read using a specific app on a specific device then whatever you're creating isn't really a backup for a lot of practical purposes.
Agree with the sentiment, but I can understand why they don't offer this. Rational or not, people will feel less safe if all their messages can just be easily exported to plaintext. A few scenarios where this might matter like the 'evil maid attack' where someone briefly has access to your unlocked phone.
But I just use this project to export my signal messages to plaintext: https://github.com/tbvdm/sigtop
I have it auto run periodically and it's great. Makes for easy full text searching of my message history.
Rational or not, people will feel less safe if all their messages can just be easily exported to plaintext.
IMHO the point is that it's not rational. Signal is as vulnerable to the analogue hole as any other messaging platform that displays the messages on a phone screen. There was never any credible way to prevent someone who has received your message from keeping or passing on the information it contained. The idea is as unrealistic as the "disappearing message/photo" applications when confronted with any cheap phone or camera separate to the one showing that message/photo. Ultimately if you don't trust the recipient of your information to treat it as you would wish then your only choice is not to send them the information in the first place.
People aren't rational/perfect and Signal wants to keep them feeling safe? ¯\_(ツ)_/¯
(and IMHO there are edge case scenario where the additional friction in exporting messages provides some protection. Particularly when your threat model involves imperfect actors)
edit: here's an example. Let's say I use 4 week disappearing message with everyone I chat with. That's imperfect of course, but let's say right now only about 5% of the people I chat with are proactively backing up/screenshotting my disappearing messages and the rest let messages expire. If Signal rolled out an "export all messages to plaintext" feature, then suddenly that 5% might become 50%. And now a lot more of my messages which used to disappear, are being preserved.
If everyone I chat with is a perfect 'threat actor' that always backups up every message they ever receive, then there's no difference at all. But most people aren't, so practically there's a big difference because now exporting to plaintext (and bypassing time restrictions) is trivial for the masses.
> Because it seems to me that, for much of Signal's (often paranoid) audience, they'd much rather use one of the backup/sync providers they've already verified trust of, than have to additionally trust some new backup service provider.
I wonder if those folks are the ones actually asking for backups. Personally I couldn’t give a shit about my messages from more than a week ago and part of that has to do with privacy. People concerned with privacy might also be more likely to have disappearing messages on which is the exact opposite of a backup. I honestly wonder who this is for exactly. From reading other threads, are people using this as their primary media backup basically?
This. The former core user base would prefer the definitive history destruction to a reliable backup. But this audience doesn't grow this fast anymore.
The signal org does some sketchy things. Like for example, why won't they release all of their infra automation backend code. There's no reason this and all the other tiny bits should be kept a secret!
Backing up Signal on Android for free and offline was ~always possible. The app creates a multi GB backup file on the phone memory under the Signal folder that you can just copy out and back on a new phone.
The file is encrypted with the passcode and the database can be extracted.
There are a couple of problems with the existing backup:
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.
> 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.
That's not what happened, it was Google who started rejecting their updates on Play store. I believe the original Android app maintainer quit after that but there's a fork on on F-droid which works perfectly.
fork that will work perfectly until year after next.
Not if you run the GrapheneOS variant of Android.
I would love to but my banking apps only work on Google Android.
Unlucky. All three of mine work on GrapheneOS
https://privsec.dev/posts/android/banking-applications-compa...
Why?
Presumably they're referring to Google's plans to roll out developer signing requirements for all apps[1], which will affect F-Droid-installed apps.
Assuming that the developer of Syncthing-Fork doesn't mind providing ID to Google, they shouldn't have an issue getting a signing key (we will see how this works in practice). They aren't doing anything objectionable to Google.
The bigger issue for third party apps will be things like Newpipe, where applying for a key will put the developers in danger of a lawsuit because it affects Google's business.
(The APK signing requirement is a fiasco, I'm not defending Google. Just pointing out that this app will probably not be as seriously impacted as others).
FWIW, adb install will continue to work: https://www.notebookcheck.net/Android-s-app-sideloading-bloc...
The $1.99/m is not for the up front work of fixing what sucks about current backups though, it's just bundling those fixes in with YACSS (Yet Another Cloud Storage Subscription) is the only way to get people to pay their "reasonable" recurring fee.
People here seem to want to answer the question of how to copy data most directly, but only because that's how the problem was phrased. I'm not convinced "users had no way to sync data on their phone" was/is a real problem worth paying for YACSS for in the first place.
Explicitly, from TFA:
> But secure backups aren’t the end of the road. 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.
Yeah, they're definitely fully aware. If they ever do actually get cross device local backup I'll be particularly pleased, several years back the stance was basically "working as intended".
Not to mention that this is a pretty good way to fund Signal. That's always been a challenge with Open Source projects as not enough people want to donate. On that note, a lot of companies will do donation matching and just saying, that's one way you could go about it if you feel inclined. For an app I use every day, I don't mind throwing them some beer money (and having work pitch in too). I get more utility out of it than my Spotify subscription
> Once you have it on disk, how do you get it away from your phone?
Since we're talking about Android, a great method is to just use Termux and rsync. You can write a pretty quick and dirty shell script to accomplish this. Here, I'll drop mine[0]. It's no the cleanest but it'll get the job done and has some documentation to it. It will check if you're on WiFi and connected to a specific SSID. You can change this around pretty easily to do different things like point at 2 servers, use Tailscale, give a white list of allowed SSIDs, change the rsync to have it delete from the local storage, or whatever. If you don't know how you can reply to this comment or open an issue and I'll respond[1].Unfortunately this doesn't work on iPhone. I have a shortcut that will do something similar that I can share but that is a lot hackier...
[0] https://github.com/stevenwalton/.dotfiles/blob/master/script...
[1] Probably better. I'm normally logged into my alt account
> Once you have it on disk, how do you get it away from your phone?
plug your phone into a computer? Install Termux and use one of the countless command line programs designed to transfer bits over a network?
I think GP was talking about how to transfer the backup 1) daily, 2) in an automated manner, and 3) reliably and in time (before, 48h later, Signal overrides the existing backup on your phone later with a new one).
This is not trivial when each backup archive is in the order of 20 GB.
You can still use https://f-droid.org/en/packages/com.github.catfriend1.syncth...
On Linux KDE connect can mount your phones filesystem as FUSE filesystem and then you can use desktop file explorer like dolphin. It's even integrated and automatically apears as an option. Quite convenient, I would say. Performance is pretty good too.
Any Linux desktop can do that via MTP (Google doesn't allow access as mass storage anymore)
Maybe it's just me but doing a big transfer over cable is a crapshot since it will disconnect midtransfer. KDE connect is a bit better but syncthing is the best solution still.
Doesn't MTP require plugging in a USB cable? KDE Connect works wirelessly as long as your phone and computer are on the same network.
KDE Connect just uses an SFTP file mount. You can do that on any system that you can ssh.
But I wouldn't use that for backups, I'd use rsync.
> There are a couple of problems with the existing backup:
>
> 1. It is non-incremental.
I wonder if that's differently with the newly announced functionality. Their announcement doesn't sound like it:
> Once you’ve enabled secure backups, your device will automatically create a fresh secure backup archive every day, replacing the previous day’s archive.
@greysonp verified they're indeed incremental for media: https://news.ycombinator.com/item?id=45170515#45175402
> Once you have it on disk, how do you get it away from your phone?
adb pull no worky? At least for HN readers.
Any backup that needs manual intervention is no backup.
Even automatic backups run at intervals to cause less server load. The article says you absolutely have to write down your restore key too (They say notebook or PW manager).
It may seem obvious now, but I know most people will forget and be puzzled if their phone suffers physical damage. A lot about this has mandatory manual steps.
I think you misunderstand. Any backup that requires a manual step every time a backup is created is not a backup. A backup that requires some one-time manual setup, like recording a restore key, is fine.
Yes, there are some people who will forget to do that, or just lose the restore key, but that's the security/usability trade off.
Thought people are talking about backups without a "cloud" involved. So you'd need to manually connect your phone to something...
Wireguard + syncthing (from F-Droid) work fine. Triggering it when the phone is on the charger makes it very easy to sync things from a computer to the phone, while next to the computer.
To be clear, Signal + Syncthing also works fine, that's what I have.
It absolutely does not work fine. Keeping 2x the size of my database in free space on my phone to let backups work it's no solution at all, which is why I stopped doing it. (The backup creates two files - current and previous, and Syncthing can't remove complete files to another location, so you need an actually rather difficult to write script to do it).
I never really grokked Syncthing.
I recently vibe-coded a crappy Windows Go GUI to grab files off my phone via rclone & sshd4a and then optionally delete them, but it's a very manual process since sshd4a has to be running on the phone before I initiate the pull.