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.
Signal does lossy compression on images. You can change image quality from “Standard“ to “High“ in its settings but not disable it.
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.
Android to Android works
iOS to/from Android 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?
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.
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.
And question: Will a backup taken today on Androis be able to be restored on iOS once released?
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...
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.
> Our future plans include letting you save a secure backup archive to the location of your choosing
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.
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.
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)
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.
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.
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.
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.
(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.
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?
The file is encrypted with the passcode and the database can be extracted.
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.
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.
https://privsec.dev/posts/android/banking-applications-compa...
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).
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.
> 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.
> Once you have it on disk, how do you get it away from your phone?
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
plug your phone into a computer? Install Termux and use one of the countless command line programs designed to transfer bits over a network?
This is not trivial when each backup archive is in the order of 20 GB.
But I wouldn't use that for backups, I'd use rsync.
>
> 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.
adb pull no worky? At least for HN readers.
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.
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.
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.
It's entire purpose is "make two folders identical".
It's very good at that: so good that I frequently wish it did other things - i.e. if it had some notion of minimum seeding levels so it would destage files off a device provided they were replicated elsewhere (e.g. automatically clearing old photos off your phone would be a good use of it).
I ended up using rclone on Windows with an rsync server running on the phone, I think sshd4a usually.
My solution for #2 is an sshd I start up in Termux when I need to backup. I just rsync the file onto my computer.
Ever thought about that?
The solution is to split up your data into encrypted chunks, and only upload the new ones.
You're welcome.
On Android? Easy, Termux app and then rsync to my Desktop/Laptop. Or via Solid Explorer. Or E-Mail via Blitzmail.
Non incremental is a suboptimal design decision, backups should be incremental, e.g. monthly if automated or with from-to dates.
The new offering is reasonably priced imo.
Glad to see they're finding potential revenue streams that don't compromise their focus on privacy and security.
Also, considering that linking requires access to your existing device I don't see an issue with that. Moxie himself considered usability to be more important than tinfoil hat-level crypto because large-scale adoption is what enables security.
The limitation is that only message history from the past 45 days would be synced. If this has changed recently to allow syncing all message history, I’d be thrilled!
I didn't trust their rationale about PINs and remote attestation somehow meaning your data is secured by a small passphrase, just like I won't trust them to not remove a useful and existing feature I already rely on for backups.
Also not mentioned, they designed their existing backup solution to require reverse-engineered community solutions to actually access your data; I have to use a Github project to unencrypt the backup and export my chats, which is something I've never had to do with any other messenger.
>This is excellent news! Will there also be official documentation on the backup format, potentially even official tooling like signalbackup-tools[0] to access/parse backups offline? I'm asking because, having used Signal/TextSecure for 10 years now, my backups are worth a lot to me (obviously) and there have been times when I would have liked to mine & process my backed-up data. (Extract media from conversations in an automated manner, build a more elaborate search, …)
I'm like that poster and backup all my chats obsessively, since way back in the day, and experienced a period with Signal where it was impossible for me to access my own data because of their position.
So you're like me :)
Greyson answered my question btw.
Seriously, why is the migration protocol completely different on the two platforms?
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.
> But this new thing is all cross-platform, and in the near future we'll even be making our local backups cross-platform.
This is excellent news! Will there also be official documentation on the backup format, potentially even official tooling like signalbackup-tools[0] to access/parse backups offline? I'm asking because, having used Signal/TextSecure for 10 years now, my backups are worth a lot to me (obviously) and there have been times when I would have liked to mine & process my backed-up data. (Extract media from conversations in an automated manner, build a more elaborate search, …)
My backups have also reached the point where they are so big (15-20 GB) that it's starting to become difficult to conduct a backup each day and sync it successfully before it gets overridden 48h later. So unless I start using the new "cloud backup" feature[1] (which I'm not sure I want to), at some point I will have to archive my existing Signal conversations somewhere and start from scratch (i.e. reset the app). In that case, it would be nice if there was an officially documented way to merge & read new and old backups offline (on my desktop), similar to what [0] provides right now.
[0]: https://github.com/bepaald/signalbackup-tools
[1]: EDIT: Actually, it seems like the new cloud backup feature doesn't support incremental backups, either? https://news.ycombinator.com/item?id=45175387
Also, as someone else noted, the format is indeed incremental. So while we'll still do the thing where we keep the last two backups on disk, because those two backups will share almost all the same media files, the size on disk will be much much smaller. As someone with a 50 GB backup file, this was very much a goal for me :)
[1] https://github.com/signalapp/Signal-Android/blob/main/app/sr...
That would be fantastic! Thanks so much!
> As someone with a 50 GB backup file, this was very much a goal for me :)
Haha, I'm glad I'm not the only one!
There's no reason to keep it secret and no reason why signal won't speak to this point.
Thanks!
iOS has had pretty decent audio format support for a few years now: even though you can't directly import FLAC files to iTunes/Music, they are supported in the OS itself since 2017 and play fine both in Files and in Safari. The other big mainstream formats (WAV, AIFF, MP3, AAC, and ALAC) have been supported for years, and even Opus finally got picked up in 2021.
About the only non-niche audio format that isn't supported natively on Apple platforms at this point is Vorbis, which was fully superseded by Opus well over a decade ago. Even then, I believe it's possible to get Vorbis support in iOS apps using various media libraries, although I'm sure Apple frowns upon it.
I'd really love to know what's causing that incompatibility.
> 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.
Because they don't want to make jumping to the competitor too easy.
> Once you’ve enabled secure backups, your device will automatically create a fresh secure backup archive every day, replacing the previous day’s archive.
So IIUC backups will not be incremental and I will have to re-upload my 15 GB backup archive every day? Why is that? What's the security risk here? (Obviously I'm not suggesting encrypting & uploading each message & media file individually but splitting things up into same-sized chunks, like e.g. borgbackup does.)
> At the core of secure backups is a 64-character recovery key that is generated on your device. This key is yours and yours alone; it is never shared with Signal’s servers. This key is different from your Signal PIN, which serves different purposes.
Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?
That's less of a problem when the backups are local, because access to the local backups implies access to the device, but if the backups are in the cloud with no forward secrecy, this seems like a huge security backslide for Signal.
> Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
At least on Android apps can disable screenshots, though, which might be a simple way to deter people from doing that?
Yes, much easier to type
> So IIUC backups will not be incremental
Nope! It's very much incremental :) At least the media is. There's one blob of containing all of your messages+metadata which does have to be re-uploaded every night, but for most people that's gonna be somewhere in the low-tens of MB. Your attachments are uploaded incrementally one at a time, typically as they're sent/received, so you usually don't even have to wait to upload them at backup-time.
> Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?
This was a hard decision and something we went back and forth on. But at the end of the day, we felt the safest thing we could do for now is to use a completely separate strong, random key. We're very aware of all the trade-offs involved, but this is where we landed.
That's great to hear, thanks so much!
Alternatively, would it be an option to get a throwaway number you could register your old phone under?
Finally, once you have the backup, use something like https://github.com/bepaald/signalbackup-tools to merge your old phone's backup with your current phone's backup, and then reinstall Signal on your current phone from that merged backup. (Disclaimer: I have never actually done this before but signalbackup-tools has been around for a long time and the developer seems to be very responsive.)
¹) I'm talking about the traditional way of backing up Signal conversation data to an encrypted archive here, not the feature discussed in the OP.
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.
> 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.
I’m also hoping similar media management options are available on iOS and desktop, since I use Signal across devices.
By the way, does Signal treat synced devices (like desktop or a second phone) as “replicas” vs a “primary”? If so, does this affect how storage or message history is handled between them?
Would appreciate any insight from folks familiar with the technical side of this!
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.
I had to install sqlcipher, find my encrypted key stored locally, find the decrypt key in apple's keychain, decrypt it using Signal's format, etc. This took a lot of trial and error, and reading a lot of existing source (special thanks to https://github.com/bepaald/get_signal_desktop_key_mac but unfortunately it did not work OOTB for me)
From a product perspective, being able to switch between two iOS devices without a 3rd iOS device shouldn’t be a premium feature.
Please consider enabling local backup and restore for a single Signal instance on iOS.
I have moved Signal from an iOS device to a new iOS device multiple times. Why do you need a 3rd one?
Signal doesn't support multiple phone numbers on the same device. I have two phones:
1. Old iPhone: +55-555-5555
2. New iPhone: +1-867-5309
I would prefer to have the numbers swapped on the devices. There isn't a way to do this without "transferring"[1] the messages to a 3rd iOS device.
This is an awkward edge-case that would be ameliorated by allowing local file backup / restore.
https://support.signal.org/hc/en-us/articles/360007059752-Ba...
Feels like it would be better to support multiple phone numbers on the same device. But yeah... that's work and probably not a super common use-case.
So you're saying that I can buy a cheap eSIM for just a couple weeks in a country? Don't they require to verify my identity and all that?
It’s so simple and convenient. Once you’ve returned back, you don’t necessarily have to delete the eSIM from the device. The iPhone models that have had eSIM support allow you to have a total of eight eSIMs on the device. You can activate (i.e., turn on) only two lines at any point in time.
So even if you have two numbers where you live, you can turn one off, use that slot and turn on your travel eSIM and then later switch back.
All the eSIM sellers provide clear and detailed instructions on how to install and activate the eSIM.