> 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.
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.
> 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.
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.
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?
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 :)
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.
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.
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.
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?
> 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)
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.
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.
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.
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).
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.
> 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...
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.
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.
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.
> 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.
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.
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.
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 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.
Syncthing is just open source Dropbox, self hosted.
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).
What? My phone has a perfectly working 802.11 chipset, which is able to talk to my very own machines that are not in a cloud, no manual connection needed. This is purely a software/ecosystem issue.
Really? Ever since Android devices ceased to be regular USB storage devices and switched to MTP, this has never worked well for me. MTP is incredibly slow.
MTP is so slow that when I have enough photos and videos on my phone, Windows will crap itself and stall out just trying to list the folder. It's functionally unusable and I don't know how I'd get those files off the phone if I didn't use literally anything else. If it was mass storage I could just rsync it over USB but it isn't so I can't.
I ended up using rclone on Windows with an rsync server running on the phone, I think sshd4a usually.
Pretty much any other: Connecting my phone to my computer as USB storage (when it was still possible), connecting a thumb drive to my phone, syncing files using Syncthing, using adb, …
Why wouldn't it be possible? All it really means is that you need to do the work to make incremental entirely on the local side and not on the remote side.
Personally, I find that having orchestrate and regularly schedule the exporting of that file off my device to somewhere else, and then look after it there to be not "free".
Agreed. I prefer setting it up myself and have had Signal backing up to my home server for a few years now, but for most users an opt-in with a basic free tier and cheap enough paid plan makes a lot of sense.
Glad to see they're finding potential revenue streams that don't compromise their focus on privacy and security.
I bet they'll phase it out and try to force their worse service, wherein your data is stored on their servers, like they tried to do with PINs. It took enormous pushback to get them to stop mandatory PINs, and even then they made it nagware for a year or two.
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.
From your link, I wish they would answer this, and they've been asked numerous times, and to my knowledge have avoided the question (which is very concerning to me):
>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.
If you restore the backup on a new phone, you'll have to resync all desktop machines, and at least on Windows syncing old messages has never worked for me.
They do. They also offer to do it when you link your desktop client, and like I said, it works on Linux but gives an error message on Windows.
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!
Hi there, Signal dev here. The new backup format is indeed cross-platform. I've successfully restored backups on an iPhone, we're just stabilizing things :)
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.
Hi! I don't know if we'll have anything super official, but the code is obviously all open source, and the backup file is just a stream of protobufs[1], so it shouldn't be too bad to make a tool. I know have some rough CLI tools sitting around -- I'll see if there's anything we want to clean up and release publicly when the local backup portion of this launches.
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 :)
Hey, please get signal to release all the infrastructure automation code so someone could audit all of signal's infra and even fork if we ever needed to because of U.S. laws or so on.
There's no reason to keep it secret and no reason why signal won't speak to this point.
Will you guys ever ship an update that allows me to use my Signal iOS install that had a partially-broken migration from an older device? I was able to receive/read messages, but couldn't send. I tried to re-register but now my client is completely broken and crashes when I enter the registration verification code I get via SMS.
Will the new backup format support also conversion of filetypes between Android and iOS? In the past Voice Memos from Android couldn't be opened on iOS if they weren't sent directly between participants.
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.
This is the result of differing storage implementations in the app between platforms and has nothing to do with the platform itself. Painless cross-platform migration is possible but simply wasn’t factored into the original design. IIRC WhatsApp also has this problem.
> 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?
Giving people a 64-character key also feels uncharacteristically crude for Signal. It's not realistic to hand people 64 characters and tell them to “store this securely.” Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
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.
I get your point but is a large set of dictionary words or 5-digit numbers (see the current backup passphrase) so much better? At the end of the day, recording entropy will always be cumbersome and there is no way around it.
> 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?
I think a large set of dictionary words are likely more user friendly. I think most people will have a lot more confidence on their ability to transcribe words to/from paper more accurately than a bunch of numbers - better built in error correction, etc.
Ah yes, the Signal PIN is backed by Intel SGX to ensure it can't be hacked even if the user has not provided enough entropy. However, why not simply rule out the low-entropy case altogether and use that randomly generated 64-character key throughout? That way, we also wouldn't have to trust Intel SGX… (which I think we shouldn't)
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.
Thank you for choosing the "strong random key" rather than "sketchy PIN+SGX" option. This decision recovered my trust in Signal after the previous Signal PIN fiasco.
I'm assuming the backup format uses a container (like Veracrypt volumes), which grows in size forever, and cannot be backed up incrementally. I ran into the same issue when backing up loopback LUKS volumes. An elegant solution in this case was switching to Gocryptfs which encrypts each file individually, but then can mount the entire folder as a whole with fuse. This means only modified files need to be synchronised to the remote.
Most likely they have different keys for absolutely no other reason than the fact that they were bought/made separately. I honestly would prefer to have a single key to my building.
I moved phones before Signal backups were available. My old phone has years of Signal chat and photo history. I can scroll through the conversations, but since I activated Signal on my new phone, my old phone will not let me export a backup any longer. Is there a safe sequence of operations to let me recover the data?
Couldn't you re-register your old phone temporarily, just for the purpose of taking the backup¹, and later re-register your current phone? (In fact, once your old phone is registered, turn on airplane mode, and you should be able to re-register your current phone right away without affecting your old phone and the backup you're making there.)
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.
It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads.
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.
> It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads.
> 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.
The issue I have with this is that it deletes the whole message, not just the media. In WhatsApp, you can delete media from the images/video folders and the messages remain in the conversation, they even still have the blurry preview iirc. In Signal, you end up with gaps in your history instead.
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!
Creating signal backups for iPhone users is _really_ hard. The only way to do it is to get a backup from the Signal Desktop app, which is also non-trivial because in recent versions of the desktop the decrypt key is also encrypted and store in keychain.
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)
It's been a very pro-user development. You can buy an eSIM using an app these days. So when you travel, you can just download an eSIM for the country you are visiting if your home provider doesn't offer competitive international packages.
Identity verification depends on the country. In certain cases there may be limitations. There are many eSIM sellers, like Airalo, Jetpac, Saily, Holafly and more. You can buy the eSIM with an eSIM package (for data, mostly, but some also sell voice/SMS) for a country or region, activate it (or wait for it to activate when the phone connects to a local network at the destination) and use it.
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.
I don’t know how it works but I would guess that the KYC stuff happens with the resellers (who make the apps). So the resellers have some due diligence of identity verification then they make some guarantees to the telcos. Otherwise, it would be a vector for scams and crime.
This is really great. I've managed to convert a few people to talk over Signal and while I am backing up my chats to my home server (I see you will be offering something like this in the future), this wasn't really an option for the people I converted over to Signal, so they were constantly afraid that they might lose the pictures or the chats if something happened to their phone.
I know, you can download media and save it through something else, but most people just opt-in whatever is default. I think my only suggestion would be to make it real clear or even maybe have some sort of counter that says something like "39 images are no longer backed up" or "8374 media items are NOT being backed up, 507 are in backup, 29 will be removed tomorrow". This could be directly on the backup page, I'm not currently running the beta build as I installed the apk, but if it's already on there, scratch the feedback!
Thank you again for all your hard work on this, it really is appreciated (financially too!)
Yes! That has been supported for a long while. At least on Android, go to Settings -> Chats -> Chat Backups. Set up a schedule and a passphrase and a folder, and it will export your chats every day.
I do that and then sync that folder with another computer using SyncThing.
> I do that and then sync that folder with another computer using SyncThing.
AFAIK SyncThing only monitors for changes between files with matching names, and Signal stores each backup with a separate (timestamped) filename. Are you storing every day's backup individually, or do you have some tool for deduplicating?
Encrypted backups can't be deduplicated unless the encryption is flawed. There shouldn't be a way to tell that one Signal backup is somewhat related to another, unless you have the passphrase.
That also means that Syncthing can't do better than sending the full backup. But if you're syncing via wifi (e.g. at home) it's not really a problem anyway.
> Encrypted backups can't be deduplicated unless the encryption is flawed.
Would you mind elaborating on why this would be an issue? 1) Tools like borgbackup provide the exact functionality you're describing and considered secure. 2) Encrypted file systems also don't re-encrypt your entire HDD whenever you change a single file.
> Encrypted backups can't be deduplicated unless the encryption is flawed
This isn't an encryption problem; each device can only have one instance of Signal installed, and the latest backup (assuming it has terminated successfully) is a superset of the previous ones (aside from any messages that have dropped from retention, which you presumably don't want to be preserving, by definition).
"Deduplicate" in this context means ensuring that you only have N backups in your remote storage, rather than cumulatively storing every day.
They do and have done for years now. There’s been a files app since 2017. They’ve had Advanced Data Protection available for iOS backups since 2022. Signal has just been lazy and found maintaining the Android backups to be a pain, so they refused to implement it for iOS.
From the point of view of iOS, yes it can (the person you're replying to is wrong, as explained by the other person who replied to them). But no, the Signal iOS app does not currently have that functionality.
They did support it since they released the Files app, as Signal shows. Nothing changed all these years, yet they're now rolling out backups for iOS too, so the technology is already there.
>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.
Yep. Local backup generation has been around for at least a few years. You can have signal make a backup for you every day. You just need to get it off the device. This looks to be adding a remote option for this existing feature.
I don't get this. The local-only backup option is already encrypted. Why can't they include an option for me to upload it somewhere of my choosing, like Google Drive, or even using Android's built-in backup system, so I can do it for free (my current backup file is well over a GB)? I already donate $5/mo to Signal Foundation; building a paid-only backup solution gives me a bad taste.
I even wrote a small Android app to do GDrive uploads of the encrypted backup file, watching the local backup directory for new files. (It broke with an Android version update and I haven't gotten around to fixing it.)
The existing local-only option is legacy. I guess they haven't built on top of it because of that. The new option is better, and they say in the article that it should offer an option to do exactly what you ask for.
> The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit.
"They refuse to allow me" meaning "they don't add the features I want for free to the app they provide for free, so I complain".
The messages are yours, of course. But don't forget that you use their work for free. If you're not happy, go use the free work of someone else, I guess?
They are somewhat correct though, Signal has written code explicitly to prevent iOS users from including Signal data in Apple’s encrypted local and/or cloud backups.
Allowing encrypted backups was free for Signal, but they spent time and money to prevent it for iOS users.
Part of the code the wrote to prevent backups in question:
Lot's of people have requested justification in related Github issues there, but Signal has not given a clear answer. If there was a security problem with the encryption process I believe a CVE or similar would have been in order because it would affect millions of users.
We are unfortunately rehashing the same arguments from Github, nothing prevents Signal from distrusting Apple by default.
But there is also nothing (except for some secret reason they refuse to elaborate) that prevents them from allowing users to actively chose to trust Apple. Except for their own internal reasons, that is.
It's the user's data after all. The user should be able to control and access it. Sensible defaults makes sense, but the outright refusal to explain why they prevent it is very odd. I have a decent "IT hygiene", I keep my operating system updated with patches, I don't download pirated/cracked software, I have hardware-enabled encryption on my storage devices, I have a good password for my local account, I encrypt my local iPhone backups.
Why should I not be allowed to include my Signal chats in those local backups? Signal has never answered that question, which is very strange.
Same as I said above: you are asking for a new feature. Their default is those 20 lines that "protect" the files. If they want to offer you a way to still enable it, someone has to do it. Someone has to work on the UX of it, maybe there is a need to explain to the users why it is less secure when this feature is enabled, and then there is work to do with the criticisms that will come next time someone shoots themselves in the foot because of this feature (because "Signal shouldn't have allowed that in the first place").
I know, you will say "it's not much". But everybody asks for their "small feature", and projects generally can't do everything that everybody asks them to do (and usually for free).
I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
I think we have vastly different definitions of what is a "new" feature. This is not about adding a new feature, but removing an old bug.
> If they want to offer you a way to still enable it, someone has to do it.
They can just use the iOS system settings to allow users to enable/disable backups. This would be zero code needed. Zero maintainability problems. Zero UX. Zero unexpected data loss for customers. The settings for this is for all sane apps at Manage Storage > Backups > [Device Name] > [App Name].
> I know, you will say "it's not much". But everybody asks for their "small feature"
It's less than anything, it's removing a "feature", which should make things easier to maintain.
Signal _added_ the "feature" to disable the default iOS behaviour that user data can be backed up securely. This caused, in many users life, a bug of unexpected data loss. Signal caused that bug and that data loss by introducing this "feature".
Again, fixing this bug would not require a new feature to be added, but rather an unwanted bug to be removed by removing code needed to maintain it.
> I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
Not a single argument has been given why this would be more secure than the locally encrypted backup you can do yourself in iOS. In fact, it would be sane to suggest that any newly introduced claimed secure system is insecure until tested.
I understand that you are frustrated. And I understand that if you were to write Signal, you would do it differently.
Still, those 20 lines don't look like a bug to me. And Signal does not benefit from pissing you off. I was just trying to say that maybe, just maybe, there is a valid reason behind this.
The bug is not in the detailed implementation of the code logic per se, the bug is that it causes unexpected data loss because iOS users expect all their data to be backed up when they back up all their important data.
As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. But it should never do that to begin with, it should have been designed/architected quite a bit differently.
You are free to carry water for Signal while they repeatedly refuse to even explain why they consider this a valid approach to handle the users data.
"I consider it a bug because I really want this feature" does not change the fact that it is a feature.
> As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs.
This is not a good example. It's almost certainly a security issue. Unless you have a threat model where you absolutely don't give a shit about it, but we're not in 2010 anymore. Let me try to make another one:
As an example, a messenging app sending encrypted but not end-to-end encrypted messages over a server may be considered free of bugs. Adding end-to-end encryption to it would be a new feature, and it may well be out of scope for that particular app (ever heard of Telegram?).
Today I learned that some people consider unexpected data loss a feature, and that removing such a "feature" is in fact the same as adding a new feature.
It's newspeak all in the software world. A first for everything I suppose.
> I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default.
The gap in understanding here is that Signal already trusts iOS by providing an app. It trusts it even more by providing notifications (with sender and content) that go through Apple’s systems. It integrates with CallKit to work with the Phone app. Putting iCloud alone in a separate bucket doesn’t make sense. They could’ve done this same backup with a 64 character recovery key and stored the data in iCloud. Signal made an intentional choice not to allow backups on iOS.
One can only hope that the point about supporting other backup endpoints/storage gets implemented sooner rather than having to wait several more years.
> They could’ve done this same backup with a 64 character recovery key and
Again: they could have, but it would have taken time and resources. The complaint here is not that Signal doesn't want to allow backups: they are just announcing a secure backup feature.
The complaint is that Signal did not do it earlier, and instead decided to prevent what they considered an insufficient solution.
> Putting iCloud alone in a separate bucket doesn’t make sense.
Of course it makes sense. What you say is akin to saying "end to end encryption makes no sense, because if you have to trust iOS anyway, you may as well trust the server".
Because I trust Android and run Signal there does not mean that I want it to auto-upload my messages to Google Drive. I don't see what makes it so hard to understand.
> One can only hope that the point about supporting other backup endpoints/storage gets implemented sooner rather than having to wait several more years.
Yes, I hope that too. On top of hoping, one could donate, to slightly contribute to paying the developers that work on it.
Their first cut at "working on it" is to require that we pay Signal to store our backups for us (45 days of media and 100MiB total is not a useful free tier; I have more than 1 GiB of messages/media spanning years), when that's an entirely unnecessary restriction.
I don't know what you do for a living but it's very common when writing and releasing software to do it in phases. Earlier phases have a restricted feature set and feedback from the field/customers/users experiencing earlier phases informs choices in later phases.
Unless you have direct insights into their dev process, your claim that the restriction be "entitely unnecessary" seems overly strong.
This is so incredibly important! I am very happy to see this, the fact that you could not do a backup on iOS and you would lose everything in case your device dies is the biggest drawback of Signal.
I still do not quite understand why I can't have the option to just back things up to iCloud (I do understand the security implications and I'm fine with it), but ANY backup solution is better than "your data is gone, tough".
Oh, now having reread the article I do understand why I can't have any other backup options. Paid subscription. Of course.
Feels like a really good way to finally get Signal to start working towards sustainability. I see myself paying just to help this incredible product continue serving its mission
> This is so incredibly important! I am very happy to see this, the fact that you could not do a backup on iOS and you would lose everything in case your device dies is the biggest drawback of iOS.
FTFY. It's originally Apple preventing its users from easily controlling their own data.
Apple 100% supports this, and has since day one, backing up securely to your local computer with no cloud in sight--and, in fact, has always been an industry leader on this, as they understand backups directly help their hardware sales--but Signal goes out of their way to block it.
Hiding relevant info behind "..." all over the post is annoying. Instead of reading through it like normal one has to read and click those little dots a dozen times.
I'll save you the trouble:
- Even if you choose not to back up your chats, someone you are talking to can do it, and your messages to them will be saved in their backup.
- 100 MiB of message storage is free.
- Last 45 days of media storage is free.
- Beyond that you have to pay $1.99 per month, and get 100 GB of storage.
I found those bits useful, but also realized that this crude interface could be an accessibility issue. People would’ve been better served with these points directly inline.
The weakness was carefully going through the menus and manually adding a reporter to your group chat. There's not much the Signal team could have done about that.
I have unfortunately lost signal history on various devices. Most recently I lost my iOS history when I restored from a backup without following the right procedure to keep Signal history. I have the full history on my desktop macOS signal though.
Can I use this to restore my macOS signal backup to my iOS phone, so I once again have access to all my old messages on the phone?
> 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.
Are they still refusing to do anything about their painful 30 day device unlinking policy? If they can support full backups, surely they can accomplish this.
Well if somebody has a year of messages backed up on Signal's servers (with this new feature), and one of their linked devices gets turned on after two months of being turned off, they could surely pull the messages from the backup rather than from the normal queue but do it seemlessly so that from a user point of view the device just never got unlinked?
Without backups it makes sense to have a limit, like you said (though I join the person you replied to in wishing there was an option for it yo be more than 30 days), but their point is that once backups contain more than the last 30 days of messages that reason is no longer a blocker.
Hi there, Signal dev here. While we won't do this for you automatically, any time you link a new secondary device, we give the user the option to transfer their message history. It follows the same rules as backups: last 45 days of media for free, or all of it if you're a paid user. And even if you're not a paid user, you can request individual attachments be transferred from your primary device.
One caveat is that we don't offer this if you're re-linking an install that already has data but became unlinked. This is because we don't currently handle merging message histories. But if you cleared the data from the secondary install first, it would work. We're thinking of ways to make this smoother!
Thanks for the reply - I definitely hope you can someday get to the point where, using the backups, you can get rid of the 30 day limit for having a device online, such that the user experience is identical whether turning on a device for the first time in 29 days or the first time in 99 days - the only difference being the backend tech of where the messages are loaded from, which the user wouldn't need to know about. Or, if needed, the user getting a "this device has been offline for X days, please enter your backup password to sync all previous messages" alert.
There should really be a prompt/hint when re-linking to tell you about this caveat, I was looking at the blog post from the beginning of the year and wondering how come a feature isn't available after ~8 months.
I'd much rather be able to simply rsync the data folder for all apps on my phone without having the hardware KeyStore breaking backups installed on another device.
The main way I specialize messages at this point is basically 'Am I going to want this later'? If the answer is yes, I use email. If not I use Signal. It's interesting this was the most requested feature... it wouldn't be for me even though I love Signal.
It's important for Signal groups, because on a new device without a backup the groups you were in don't show up until someone sends a message in the group. Say if you were the only admin in an announcement-only group, no one else can send a message in the group, so that group is now lost to you.
The contact list on a linked desktop client will show all groups you're in, even though your main device doesn't.
On Android, if you know the group's name, you can search in the contact list, and the group will "magically" show up, even though it wasn't in the list.
I like this idea, but I don't think I'd ever be able to convince my wife to run that analysis on any particular message before she decides whether to email or to message me on Signal.
so do you email yourself messages/conversations you want to keep?
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.
If Signal is offering pay-for-media-storage, it would be nice to be able to pay to send full-resolution media. I’m a photographer and every image sent via Signal that isn’t zipped first is TOTALLY DESTROYED by silent recompression.
Also, the donation spam in Signal doesn’t let me donate Mobilecoin from the wallet right inside Signal. What’s the point of having a payments feature if I can’t use it to pay you?
Please allow payments to Signal to be done in Signal’s native payment system.
I would love to subscribe to Signal in a privacy-preserving way.
> Signal doesn’t let me donate Mobilecoin from the wallet right inside Signal. What’s the point of having a payments feature if I can’t use it to pay you?
Meanwhile in Norway, of 520 phone contacts (of which many are things like cabs, restaurants, realtor from way back when) – 83 are on signal. And it's not like I have particularly privacy-conscious friends, that I know of.
Why do people want logs of conversations for years and years?
All of my Signal chats are set to 4 week expiry. Any media I want to keep, I save to the device.
I don’t audio record my conversations with close friends and family; why would I keep chat logs?
I don’t understand why people demand this feature. It wasn’t until the iPhone that people got accustomed to keeping every text for all time.
I don’t think it’s a healthy approach. For most of human history, you didn’t get a permanent record of private conversations you had with people. It feels like a type of hoarding, given how often people actually use/access their old (>4 weeks) chat logs.
Am I still required to add a phone number to use signal? What's the point of that. Every single person in the USA (and probably world) is quickly and trivially de-anonymized with a phone number.
That article is out of date. It says things like "Signal still knows nothing about you", but Signal collects every user's name, phone number, photo, and a list of their contacts and permanently stores that data in the cloud.
That data is only protected by a pin (which can be brute forced) and SGX which has a history of being leaky. Researchers even demonstrated that data could be collected from Signal at one point. There are very likely side channel attacks that would allow Signal, or the government to collect the data stored in the cloud.
> Losing it means losing access to your backup permanently, and Signal cannot help you recover it.
Oof... That's going to be tough to explain to normal users. "Sorry you've been paying for backups all this time, but you should have written down this code that you will only ever use once somewhere safe and remembered where it is. All your data is gone."
Absolutely the right security trade-off for Signal users. Anything else would devalue the entire product.
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.
The implementation feels uncharacteristically crude for Signal. Instead of seamless protections, you just get handed 64 characters you’re told to “store securely.” That’s not realistic: most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
Sure but the key is still in a separate location from the backup. Signal can't decrypt the backup and if Signal is hacked someone would still need to get your screenshot to decrypt the backup. Not perfect but far better than an unencrypted backup.
when you're shown the code, it has 2 buttons: copy to clipboard and save to password manager. if you choose password manager you should be relatively safe...
I have 1Password installed and it prompted to save in 1Password. Worked perfectly. It even let me paste from 1Password on the verification screen. It was the most seamless password manager experience I've ever had.
there are more than a few backup providers that do this security trade off with user acceptance of the risk. if this trade off isn't good for the user, they can use any other number of insecure backups.
If you're using Signal, of all things, that's probably a reasonable security/usability trade off.
Granted, I'm sure there are a lot of people out there who just use Signal because one of their more security-conscious friends/family members told them to install it, and so you're probably right for those people.
But, frankly, I can't see how else they could do it. Offering an unencrypted option, or weakening the encryption (by storing a copy of the key on Signal's servers) would make Signal not Signal.
I know plenty of people who have inadvertently lost their entire messaging history because their phone broke or was lots and they couldn't transfer messages directly from the old phone to the new one. Signal allows you to export backups of messages to a file, but only on Android - the iOS version does not. This is a great feature not only for users who are less technically inclined than the average HN reader, but for any user who doesn't want to go through the tedious process of manually backing up their messages periodically but doesn't want to risk losing their message history if their phone has one unfortunate encounter with gravity.
My only concern reading this is that I hope they don't remove the manual export feature once this is rolled out. I know that that feature has been technically complicated to support, but it's important for users to preserve the option to maintain control over their backups, if they want to manage backups themselves, alongside the option of having a more convenient, automated approach.
Hi there, Signal dev here. We are absolutely keeping the local backup feature. More than that -- we'll be improving it to also be cross-platform and incremental, meaning it'll be much faster to both create the backup as well as sync it if you use a third-party folder-syncing solution (like syncthing or something).
This was my question and wasn't clear to me at all from the announcement -- that there was a roadmap for my own (not Signal cloud) cross-platform, incremental, secure encrypted backups as well.
(That presumably would let me store as much as I wanted without a fee).
I wasn't even aware of the existing "local backup feature" making it more confusing -- but reading the announcement I was like, wait, the only backups avail are in Signal cloud? that doesn't seem right, why can't I get my own backup file to do what I want with?
I feel like I now understand, thanks! Personally would recommend the announcement at least reference this future roadmap too, for clarity.
Please add some way to send it over FTP/FTPS/SFTP/SCP/WebDav/SMB/whatever so I can automatically backup to my own server that isn't on my phone. I need something fully automated or I won't often do it. This is also really important if the free space on my phone is less than the size of the Signal archive, and even more so if the Signal archive is more than 50% of the total space on my phone.
It's a real shame they aren't implementing this on iOS in beta before the new iPhone launch. Android has had backups for a long time, just locally. iOS users have been SOL so if anything goes wrong with the transfer and sync on your new phone, you're screwed.
Signal has done a very poor job of calling out that you can optionally connect your old and new phone via cable; the transfer will be much more stable and quick.
(No, this does not really help if you're one of the TouchID holdouts on an older SE)
Wow! I didn’t know this! So you’re saying that instead of using slower and potentially unreliable WiFi, I could just use the iPhone charging cable to connect two iPhones and start the Signal transfer feature? Is this documented anywhere? Thanks.
I only ever learned about it from an issue about shitty backups on the Signal repo(s). I'm out at a bar so not about to dig up the link but it's probably easy to find on GitHub.
> If securely back up all* of your text messages and the last 45 days’ worth of media for free.
> If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month.
So after so many years of having a serious design flaw this poor substitute of a backup where you can't even save all your text for free is all they've managed to come up with?
> The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive.
Easy fix: let the user choose his own local/cloud storage location? (at least it's planned, maybe in just another decade)
I guess the reason WhatsApp lets you save all your text for free is they are making money off sucking up your data. I think ultimately this model will win, but I sympathise with Signal's approach.
I just had a use case the other day: my mom sent me a photo of a handwritten recipe from my great grandmother a year ago. I only remembered asking about asking, not about the response, so I was happy to still have that pic in my history. Had I downloaded the Pic, it would be lost among all the other crap I store all ocer the place. This way it was preserved with the context and even a voice message from my grandmother (not great grandmother) remarking on it.
Telegram has such a good UX, like really good. Using as many devices as you want is a breeze, having multiple accounts on the same device. Their bots API is so easy to use.
Yes, it's at the expense of security perhaps... But I tried to get my wife to use Signal, as well as many friends and it never stuck bar one or two. She had to use telegram to contact someone and decided she liked it and continued using it.
This has been the advantage, and the drawback, of Signal's security model from the start.
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.
> PGP has no forward secrecy and OTR in XMPP lacks future secrecy, multi-device support etc.
Have you ever considered that perfect-forward-secrecy is not needed by 99% of the people? And PGP (OX) can be enough of encryption that gives you multi-device support.
PGP does multirecipients natively, so any restrictions there would be in the XMPP client.
I have actually tried out PGP over XMPP and is was nice once it was set up. Absolutely no state. If the message somehow gets to you it just works. Sucked when the keys expired though:
PGP support on XMPP isn't really that great. Forward secrecy might be a nice addition, even if it was semi-manual. There are compatibility problems between clients for encrypted media. You don't end up with an always encrypted archive like you do with email, but that could be considered an inherent weakness of instant messaging...
If your keys get compromised then you would need new keys in any case.
I think that the sort of people that use PGP are more interested in not having any messages compromised, ever, while still retaining access to their old messages in a secure way. Contrast that with, say, Signal where a forensic tool like Cellebrite will allow access to retained Signal messages[1]. Sure, most of that is due to the inherent insecurity of encrypted instant messaging over, say, encrypted email, but the users in the end don't care. They just want to be able to communicate privately.
You are aware that majority of the communication happens via email, which has absolutely NO encryption and can go through whichever relay and noone gives a flying duck about it?
Again, for the overwhelming majority simple PGP encryption without pfs is more than enough. Not everyone works for government agencies and have to maintain perfect secrecy. If you do that in your private life then yes - you are paranoidal.
This is overcomplicated to collect money IMHO. All modern OSs can happily backup app files. It is a well-solved problem. If you find this backup method not secure enough (as Signal authors do), fine, encrypt the backup with a special key, exactly as described in TFA, and leave the resulting archive in a location for my chosen phone OS to back it up as it would. All the goals are accomplished, and without charging me money or limiting how many days of media are stored.
Do not get me wrong. Signal is great software and i'd gladly pay for it. Honestly. But not via this underhanded nonsensical way
Hi there, Signal dev here. The Android app does indeed allow you to export encrypted backups to your local device, which you can sync as you wish. That's not going anywhere, and in fact, we have imminent plans to make it better (cross-platform, faster, etc).
I would love if they implemented a feature to prune media files larger than ~10MiB from the existing backup file. This way the file size would not grow to astronomical proportions so quickly.
It's a self inflicted problem. Rather than using some standard message format for backups (like eml / RFC 822), and putting them in a standard encrypted container if so desired, Signal chose to use some proprietary database format. Also they apparently changed encryption formats some time ago, and the current version can no longer decrypt the old messages.
After moving devices I can no longer access/decrypt my oldest image/video messages, they failed to import properly.
What is the reason for saving the end-to-end encrypted backup files on Signal backup servers instead of iCloud or Google backup service, as most of us are already paying for this storage?
The "Signal should exist" part of me is happy to donate $2/mo to help them keep the lights on, but I really did expect that to be an option alongside Drive/Dropbox/et al, not the only option.
Besides the obvious (they want/need the revenue from selling their own solution), many people using Signal do so in an effort to move away from Big Tech and/or on devices with custom ROMs.
This seems to be an unfortunate case where a feature has a misleading name.
You already had secure and encrypted backups on your phone, which you could copy and restore, if you remembered to copy them, and write down a very long password.
The new feature is apparently a way for signal to sell cloud services.
I do think cloud based backups are very useful for less technical people. But it does not really matter if your (properly encrypted) signal backup lives on a google drive/apple cloud, or on a cloud service managed by Signal.
The encrypted backups do work, but Signal is really, really bad at indicating when and how to make them to use them for restoration. Most non-technical people I know are just resigned to wiping out their Signal history every time they get a new iPhone (and I know two people who abandoned Signal and went back to iMessage because of this), and even I've lost it a couple times.
It leaves sort of a gross taste in my mouth that a paid service is the fix for their unhelpful UX.
> You already had secure and encrypted backups on your phone, which you could copy and restore, if you remembered to copy them, and write down a very long password.
Did I? Where? on iOS I don't.
Edit: there is a transfer to a new phone thing, but that only works if the old phone still works. Which makes it not a backup (it's a transfer).
While we are on the topic of Signal, does anyone know if it's possible to have a lock/PIN to open the Signal app itself that's different than your device lock/PIN?
Threema has this feature and it's reassuring to know that people can't open my chats when I hand my phone to someone. Or if I give the device lock/PIN to someone I trust for backup purposes but don't want them to have access to chats themselves.
Last I checked this was not possible with Signal (at least on Android).
For anyone else that's not familiar, this is referring to https://molly.im/ which looks like it's a fork of Signal. And looks like it interops with Signal, so you can talk to your regular Signal contacts as well.
That's very interesting.
My only concern with it would be how sustainable it is in the long term. I am using Threema currently, which has a plan for enterprises, so that seems more reliable but it's lacking in features and usability.
In addition, it looks like third-party apps (there are a few) that interface with the official Signal client maybe against Signal's TOS. They haven't enforced it yet from what I can see but it's a possibility and that's a fairy large risk IMO.
I appreciate Signal and that the Signal developers provide a very useful service to the community for free.
I also know a large number of people who won't use it because it locks your messages up in its own walled garden. People use apps like this precisely because they want to have control over their own communications without any third parties interfering! I have never understood what kind of threat model they think they're protecting against by not letting people take their own backups and store them according to their own preferences. Whatever the reasons it is clearly a deterrent to wider adoption.
This announcement might seem like progress but I doubt it will convince any of the people I know who won't use it because at the end of the day it's still a walled garden. If and when the promise of the comments near the end of the announcement is realised and we can back up our own messages and media freely from our own devices to our own (presumably also secure) backup facilities then it will be much more interesting.
The key is 64 characters? Even if that key is made out of decimal digits that works out to 212 bits. That seems quite excessive for a symmetrical key you are hoping to have a user deal with directly. It appears that the usability of this scheme could be significantly improved by simply using a shorter key.
The article specifically suggests writing the key down in a notebook. A single incorrect digit and the scheme fails much later in a way catastrophic to the user.
Since phones have a lot of storage, then why not constantly backup locally and overwrite it for newer versions (opt in of course)? Signal already has large operating cost, so a cloud backup with the very low subscription cost is concerning. It would help Signal to get rid of sms registration and move to something less costy.
Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key. If a device with this enabled goes through the whole advanced protocol to receive a message (double ratcheting etc), then turns around and uploads it back to Signal’s servers with a static key, 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?
They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
Based on this post, the only way to actually opt out of this is to force disappearing messages to be enabled for a time under 24 hours for every chat, which is pretty frustrating.
Signal already lags other messengers in reliability, speed, and features. The reason people use it is for its uncompromising security. Shipping something that weakens that foundation undermines the reason people use Signal.
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
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.
Sure, but you already have no way of knowing which one the other parties in your chats are doing.
I already sync my Signal backups to the cloud, because that's the most practical and time/cost-effective way to have a 3-2-1 backup system for my chats.
There's a difference between someone in your chats acting adversarially and Signal supporting/encouraging adversarial behavior as part of the way the app works. If Signal published a change to the protocol that removed forward secrecy, we wouldn't consider it a non-event and say "well anyone could screenshot messages anyway," even though that may be true. They're calling this "secure backups," but in truth it appears to reduce security
I don't think it's appropriate to call someone you're talking to with disappearing messages turned off making a backup of the conversation so they have the (non-disappearing) message history if they drop their phone in a lake as "adversarial behavior".
If you don't want them to have a history only communicate via disappearing messages.
This post says disappearing messages are included in the backups. You have to enable disappearing messages with a timer of less than 24 hours to ensure that you can opt out.
Sure but the backup happens each day and then gets overwritten/deleted when the next days backup happens (which then deletes the disappearing messages that are expiring express the next backup). It just ensures you have access to any messages that you’re supposed to have access to according to the timers on said messages.
That's not how forward secrecy works. Ciphertext isn't "deleted" unless the key used to encrypt it is also deleted. That's the point of Signal's cutting edge protocol. This undoes all of that.
I'd also wonder where this shared encryption key for message "backups" is stored. If it's available on all of my devices, I suspect it would be available on other devices as well?
The article says it is generated on your device and they don't have a copy. Sounds like a public-private keypair where you are responsible for managing the private key.
got it. doesn't Signal already have on-device keys with a session ratchet? why not back those keys up so one can decrypt the entire history on any device?
afaik the key material is regenerated for every message. new keys can be derived for every subsequent message you send, but only until you get a reply, then a new key exchange takes place. And the key material for message m1 cannot derive keys for the messages that came before m1. If the old key material gets properly deleted then there is only a very small window of compromise. backing up those keys would defeat the purpose of the ratchet.
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. Your recovery key is the only way to “unlock” your backup when you need to restore access to your messages. Losing it means losing access to your backup permanently, and Signal cannot help you recover it. You can generate a new key if you choose. We recommend storing this key securely (writing it down in a notebook or a secure password manager, for example).
i missed that paragraph, thanks for pointing it out. i wonder what algorithm they're using here, and if we could use third party tooling to decrypt these messages on a local computer? it might be a pathway to some cool experimental third-party Signal apps
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
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".
> Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages".
Well, no, that doesn't contradict what I said at all. That link isn't about treating the recipient of your messages as an adversarial actor. The recipient can still choose to enable it, if they want to provide Microsoft access to the messages they receive.
I think the difference is that this is all happening in the app as a supported flow. If simply enabling a toggle in Signal (likely without understanding the implications) is now considered "adversarial," then I think that's a problem
It seems plausible that the protocol could be designed such that the device doesn’t know the recovery key. The key serves three purposes: (a) identifying the backup when a user tries to restore it, (b) authenticating that user to the restore API, and (c) allowing the user to decrypt the 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.
>Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key
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.
It's not opt in: signal protocol for a group chat is eliminated if one person in the group chat turns this on, whether or not you do. Communicating with someone who acts adversarially is different from Signal itself adding features that are adversarial.
If you're in a group and someone is backing up the messages, it only affects your messages in that group. All of your other chats are still secure as long as you're not using the backup frature.
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.
You can't have forward secrecy for something you want to keep for an indefinite interval. How many Signal users actually achieve forward secrecy anyway? They tend to want to keep their old messages available to them.
I know many people are of the opinion, paid features are a guarantee that you're not the product. I fear a slippery slope for money, it's premium features first, then essential features, then money tops security. Or replaces everything else, like with Firefox.
Shoutout to Signal team for another fantastic achievement!
As a fun evening read I'd like to remind everyone of Pavel Durov's gaslighting on how their approach of everything-leaks-to-server was the right way to implement "cloud backups" for Telegram.
Do backups get pruned over time? Is there an expiration? I don't think folks want old lost-key backups sitting around forever for quantum to catch up, right?
"On the other hand, symmetric algorithms such as AES are believed to be immune to Shor. In most cases, the best-known quantum key recovery attack uses
Grover’s algorithm which provides a generic square-root speed-up over classical
exhaustion in terms of the number of queries to the symmetric algorithm. In other
words, Grover would recover the 256-bit key for AES-256 with around 2^128 quantum
queries to AES compared to around 2^256 classical queries for exhaustion.
"
> I'm confused, I've restored Signal from encrypted backups before. I did it like 4 months ago. What's this feature?
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.
I wish they'd done that for all the other data they collect and permanently store in the cloud (name, photo, phone number, signal contacts, etc.) since you can't even opt-out of that data collection.
I wonder if now signal will finally update their privacy policy which still opens with the outright lie: "Signal is designed to never collect or store any sensitive information."
Just 64 characters but they do integrate with a password manager and have a 1-click button to add it. The integration was pretty seamless and saved it in 1Password.
They need to add some free way to backup to my own server. I have my own raid array with backups sitting in my basement. I'll back up to that. I do not want to pay them for cloud storage.
Right now, theoretically, I can do this by backing up to my phone and then copying the file over. But, this has many issues. Firstly, it is manual, so it will happen way less. Secondly, it is not differential, so the storage requirements will explode. Thirdly, if my signal message archive is bigger than the free space on my phone (especially if it takes more than 50% of total space) then I'm just fucked — there's no way to back it up anywhere else. Fourthly, the backup system is EXTREMELY buggy, to the point that it takes me HOURS babysitting it every time I make a backup.
A good solution would be let me put FTP/FTPS/SFTP/SCP/WebDav/SMB/etc. credentials in the Signal app and have it do periodic differential backups to there. Let me decide if I want it to be encrypted or not based on my threat model. Tell my contacts if this is enabled and let me exclude and/or encrypt specific chats if you want to let other people apply their security model too.
Only supporting any reasonable (meaning automatic and convenient) backup system with their paid cloud and not supporting my own server smells like a money grab to me. This is utterly unacceptable in a supposedly non-profit app. I have no problem with their paid cloud being an option, to be clear.
Another problem with Signal is that they only provide an official Linux package for Debian-based distributions. This forces people using other distributions to either do repeated manual effort to pull it out of their .deb files or build it themself (which is made way harder than it should be), or rely on sketchy third parties for packags. Given how much privatea information goes over Signal, such third party packages are an extremely tempting target for anyone from criminals to national spy agencies. This lapse in security due to not packaging for any Linux except Debian-based Linux (or even providing an ideally auto-updating portable binary!) is a much larger security lapse than letting me backup to my own server conveniently. So, their cries of security concerns relating to backups ring hollow.
Overall, it's quite a shitty app. I only use it because the alternatives are worse.
That's great they are doing a paid feature, but I really just want my desktop to back up my phone.
They clearly think people have bad desktop security, and still don't want this to happen. Patronizing...
Edit on
> 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.
That's good, but they've said that before. I feel a bit burnt on this.
perhaps said too much on a whim, but why should I backup my Signal... or WhatsApp, or any other communications.
live in the moment. let things pass. there is probably no fortune hidden in it anyway...
IIRC, that used to be the opinion of the Signal project as well, but backups are such a requested feature it looks like they've finally decided to offer it.
As an example that I experienced, I wanted a picture that someone took 2 years ago and sent to me on Signal. Since I am a data hoarder, I was able to retrieve it.
FTA: “This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive”
Those costs are for doing backups to their servers. If this supported making encrypted backups to Google drive/OneDrive/iCloud/etc, they wouldn’t have those costs, and, AFAICT, that would not be less secure, given (also FTA):
“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. Your recovery key is the only way to “unlock” your backup when you need to restore access to your messages. Losing it means losing access to your backup permanently, and Signal cannot help you recover it.”
⇒ I think it’s more of “we were looking for a new revenue stream, and picked this as a way to get that”
There’s nothing wrong with that, but presenting it as “to get secure backups, we have to make costs” is disingenuous.
> ⇒ I think it’s more of “we were looking for a new revenue stream, and picked this as a way to get that”
This seems highly implausible given the 2 USD/mo pricing, the existence of a free storage plan, and the non-negligible operating costs that obviously do exist.
I'd be interested if you have data that supports the idea of the economics working out though.
If the economics do not work out, why did they chose to create infrastructure and take on the burden of supporting it instead of implementing backups to the popular cloud providers, and not having that extra operational burden?
Also, iCloud gives individuals 2 terabytes of storage for $11 a month. OneDrive and Google Drive are similar. S3 is less than 3 cents/gigabyte (with extra costs for reads and writes)
I guesstimate backups will take less than 100GB per user. At Apple’s consumer pricing that is slightly over half a dollar.
So, if they buy storage at bulk and get a sufficiently high number of customers, I do not see why they couldn’t make money on $2/month.
Chat messages with some people can hold a lot of value. Nostalgia, recalling past incidents/events, missing someone, etc. Sometimes even the most trivial of messages can be looked at with fondness and longing.
I’m personally very glad that Signal finally implemented this. It’s been such a short sighted strategy to promote itself like a mass market messaging platform while not allowing people to keep, move and restore memories.
Since it’s opt-in, those who don’t want it don’t have to use it. They’re well served by the self-destructing message timers in chats.
Personally, I eat the cost of self hosting a small matrix homeserver. For developing a commercial project, I don't have an alternative, because e.g. being upfront and saying that you will eventually screw over your users eventually, is not an option in this economy.
Okay, I mistakenly thought that Signal was burning on investor money like any run-of-the mill startup, but apparently they manage to run on donations similar to Wikipedia.
I also just learned that you can still backup without a subscription. That's great!
> Also, let me know where me and my friends can sign up on your particular matrix instance. What's your ToS anyway?
I said that was my personal solution and not an alternative to centralized platforms.
Great article not mentioning local backups were already available and what this is about. The state of affairs in iOS vs Android of the past feature and the next one. Details of all the kind are missing. WTF.
I would love to switch over to Signal, but the video call quality pales in comparison to WhatsApp and FaceTime. Add to that issues with even sending pictures or videos on Android, and it's a really hard sell.
Lucky you! I pretty much can never send videos. I'm guessing it's something format / compression / transcoding related. Pictures are hit or miss; I think it's an infrastructure thing.
> Add to that issues with even sending pictures or videos on Android, and it's a really hard sell.
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).
Anecdotally, I've not had any issues on iOS (not that I'm needing to download media files often, but I have saved quite a few photos and the occasional video over the years and don't recall any failures).
Not that my experience invalidates that of people who have had problems, just sharing to say that the problems haven't been universal.
It's actually not more involved on iOS (unless you're unlucky and have problems with it not working - I've no idea if it's a tiny minority of people who have problems, or if I'm in a tiny minority of people for whom it works, or if it's somewhere in between). But for those of us who it does work for, it's just as simple as on Android.
You can hold down on the media, and after about a second it brings up a menu where one of the options is "Save", you tap this and it will be saved to your camera roll (ie open Photos app to see it). If it's a message with multiple photos/videos, you so the same thing and all of them will be downloaded at the same time.
Or instead of holding down to get the context menu, you can tap once to open full screen view of the media which has the iOS "share" button in the bottom left, which you can use if you either want to just save one thing from a message that had multiple photos/videos, or if instead of saving to the default place - it's the standard iOS share function, so you can choose from "save to photos" (ie a the default like above), or "save to files" (accessible from the iOS file manager or from other apps), or share directly to a different app (like an email client, or an FTP client if you have one installed, or to an app like DropBox, or any other app you have that supports the OS-wide share menu).
TLDR: The help page you linked to, the top part of that iOS section (that makes it seem complicated) is just explaining how to find an overview of all previously shared media for a contact/group, and then download from there, but you don't need to do that to download it if you're already looking at what you want to download in the main chat window. The bottom part on that page is my second option from above, which is basically identical to what you say about how to do it on Android - just 3 touches (press image, press 3 dots on Android or share icon on iOS, then press save image). But it's actually the more complicated way, with a 2 touch option available (hold down on image, then press "save" :)
(p.s. to any Signal devs reading this, if you'd like to offer a free backups subscription in return for me continuing to evangelise, or beta testing on my iPhone... feel free to reach out :P
And, although personally I'm more keen on the future feature or backing up either to iCloud or to my own server, may I make a suggestion that, if paying for you to backup media, I'd prefer to be able to pay for a "family" plan - as I've moved several family members onto Signal and would like to be able to gift them free backups rather than tell them all to start paying. I suspect I'm not the only person who would think an option to share storage with 5 or more family/friends would be worth paying a bit more than your current single-account price.)
Are backups really necessary? I have always regarded texts (over Signal or SMS) as ephemeral. No one is or should be sending valuable information over Signal, and if you happen to receive something you want to keep, you can always do so manually.
Why should information on Signal be ephemeral on Signal?
Signal is one of the few "privacy-first" services. But it is not just about privacy, it is also about having as many users as possible, which is actually important for privacy. If only people who really have "something to hide", then just using the app makes you a target. If instead it is used by millions of people for grocery shopping and dinner planning, then whoever really needs the privacy features will not stand out. The third is, of course, making money, because, of course, none of that is free.
That's why features like backups are important. Many people want them, maybe not you, but Signal is not just for you, it also makes money. By the way, that's also the reason why there are some privacy compromises, like contact discovery and the use of phone numbers, because they feel like done right, it is worth it. Note that have partially addressed both of these problems.
For many people the messages are meaningful long term (including myself), and I consider ability to preserve your personal data as a base electronic right.
Why do you think our should not? Sincerely asking.
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
I did not mean to say that there are better options for encrypted communication. My point was that my use case is texts like "I'll be in the gym at 6:00 bro", not things that I really want to keep or backup. If someone sends a picture or a file that I want to keep, I can already do so manually.
> 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.
It does for me, sure why it errors out for you
> 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?
See https://news.ycombinator.com/item?id=45171576.
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!
Did you read the article?
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.
https://github.com/bepaald/signalbackup-tools
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.
[1]: https://news.ycombinator.com/item?id=45017028
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".
Looking at how long it‘s taking them i wouldn‘t hold my breath!
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
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.
https://wiki.archlinux.org/title/SSHFS
> 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
I would use scp under Termux to copy the backup away personally.
> 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.
Syncthing is just open source Dropbox, self hosted.
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).
Yeah, I think I was just trying to get it to do something it wasn't suited for!
I see. I was talking about Syncthing in general, not about the specific way of backing up Signal.
What? My phone has a perfectly working 802.11 chipset, which is able to talk to my very own machines that are not in a cloud, no manual connection needed. This is purely a software/ecosystem issue.
Imagine we could run the backup server backend self-hosted and FLOSS. Like Vaultwarden, the upstream bitwarden client API.
USB transfer is by far the best way to transfer large amounts of data to and from phones.
Really? Ever since Android devices ceased to be regular USB storage devices and switched to MTP, this has never worked well for me. MTP is incredibly slow.
What method do you find to be faster?
MTP is so slow that when I have enough photos and videos on my phone, Windows will crap itself and stall out just trying to list the folder. It's functionally unusable and I don't know how I'd get those files off the phone if I didn't use literally anything else. If it was mass storage I could just rsync it over USB but it isn't so I can't.
I ended up using rclone on Windows with an rsync server running on the phone, I think sshd4a usually.
Pretty much any other: Connecting my phone to my computer as USB storage (when it was still possible), connecting a thumb drive to my phone, syncing files using Syncthing, using adb, …
Copyparty running in termux serving over USB tethering
Foldersync is a great app
>2. Once you have it on disk, how do you get it away from your phone? I've been using Nextcloud for my backups for the past couple years.
#1 does suck very much.
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.
How can an encrypted backup be incremental if it's supposed to be never decrypted on-remote-machines?
Ever thought about that?
Why would you need remote data to create an incremental backup?
I'm sure if borgbackup can pull this off, Signal can, too?
The solution is to split up your data into encrypted chunks, and only upload the new ones.
Why wouldn't it be possible? All it really means is that you need to do the work to make incremental entirely on the local side and not on the remote side.
That seems pretty trivial to implement
I dare you to implement this then, where others have failed.
tar --listed-incremental=foo.snar -cf - . | gpg --encrypt -r <key> > nightly.gpg
You're welcome.
> Once you have it on disk, how do you get it away from your phone?
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.
at least on android: you use a good old usb-c cable.
Personally, I find that having orchestrate and regularly schedule the exporting of that file off my device to somewhere else, and then look after it there to be not "free".
The new offering is reasonably priced imo.
Agreed. I prefer setting it up myself and have had Signal backing up to my home server for a few years now, but for most users an opt-in with a basic free tier and cheap enough paid plan makes a lot of sense.
Glad to see they're finding potential revenue streams that don't compromise their focus on privacy and security.
They even say they’re committed to offering BYO storage as the feature matures
This trick never worked for me, the app just never restores this. People used to say the same about WhatsApp. Now both have direct migration features.
Yeah, didn't see it mentioned, I trust it will still be available?
I bet they'll phase it out and try to force their worse service, wherein your data is stored on their servers, like they tried to do with PINs. It took enormous pushback to get them to stop mandatory PINs, and even then they made it nagware for a year or two.
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.
While I understand (and share) your criticism, it does sound like they'll continue to support local backups:
https://news.ycombinator.com/item?id=45171576
https://news.ycombinator.com/item?id=45172188
From your link, I wish they would answer this, and they've been asked numerous times, and to my knowledge have avoided the question (which is very concerning to me):
>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.
> I'm like that poster
So you're like me :)
Greyson answered my question btw.
If you restore the backup on a new phone, you'll have to resync all desktop machines, and at least on Windows syncing old messages has never worked for me.
Signal never syncs old messages on secondary clients for security reasons.
They do. They also offer to do it when you link your desktop client, and like I said, it works on Linux but gives an error message on Windows.
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.
> They do.
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 don't think that's true anymore. They added message history syncing
Wow, maybe as a side effect users will be able to migrate between Android and iOS without losing their message history.
Seriously, why is the migration protocol completely different on the two platforms?
Hi there, Signal dev here. The new backup format is indeed cross-platform. I've successfully restored backups on an iPhone, we're just stabilizing things :)
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.
Hi Greyson!
> 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
Hi! I don't know if we'll have anything super official, but the code is obviously all open source, and the backup file is just a stream of protobufs[1], so it shouldn't be too bad to make a tool. I know have some rough CLI tools sitting around -- I'll see if there's anything we want to clean up and release publicly when the local backup portion of this launches.
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...
> I'll see if there's anything we want to clean up and release publicly when the local backup portion of this launches.
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!
They are indeed incremental, and smaller than the current monolithic backups that Signal currently creates. [0] Yay!
[0]: https://news.ycombinator.com/item?id=45176074
Hey, please get signal to release all the infrastructure automation code so someone could audit all of signal's infra and even fork if we ever needed to because of U.S. laws or so on.
There's no reason to keep it secret and no reason why signal won't speak to this point.
Thanks!
What a ridiculous request.
Will you guys ever ship an update that allows me to use my Signal iOS install that had a partially-broken migration from an older device? I was able to receive/read messages, but couldn't send. I tried to re-register but now my client is completely broken and crashes when I enter the registration verification code I get via SMS.
Will the new backup format support also conversion of filetypes between Android and iOS? In the past Voice Memos from Android couldn't be opened on iOS if they weren't sent directly between participants.
That's really surprising to me.
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.
The issue is OGG with Opus (for me) which was used by WhatsApp but isn't natively supported under iOS.
https://github.com/signalapp/Signal-iOS/issues/4539
Do you know roughly how long before the iOS version comes out? I want to switch to iOS from android.
Are there any plans to allow backups to a custom server or another folder?
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.
Thanks, totally overlooked that last paragraph.
This is mentioned as a future feature.
> Seriously, why is the migration protocol completely different on the two platforms?
Because they don't want to make jumping to the competitor too easy.
This is the result of differing storage implementations in the app between platforms and has nothing to do with the platform itself. Painless cross-platform migration is possible but simply wasn’t factored into the original design. IIRC WhatsApp also has this problem.
Hi @greysonp
> 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?
Giving people a 64-character key also feels uncharacteristically crude for Signal. It's not realistic to hand people 64 characters and tell them to “store this securely.” Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
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.
I get your point but is a large set of dictionary words or 5-digit numbers (see the current backup passphrase) so much better? At the end of the day, recording entropy will always be cumbersome and there is no way around it.
> 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?
I think a large set of dictionary words are likely more user friendly. I think most people will have a lot more confidence on their ability to transcribe words to/from paper more accurately than a bunch of numbers - better built in error correction, etc.
Sanely formed numbers (like 4 digit groups with a checksum) seems like less writing to me, b/c I hate my hand writing.
> is a large set of dictionary words so much better?
Yes, much easier to type
And much easier to copy elsewhere or memorise (not that I would recommend the latter).
The PIN is a lot easier to guess on a remote machine storing a backup, the space is small. In the context of your device, they can throttle it.
Ah yes, the Signal PIN is backed by Intel SGX to ensure it can't be hacked even if the user has not provided enough entropy. However, why not simply rule out the low-entropy case altogether and use that randomly generated 64-character key throughout? That way, we also wouldn't have to trust Intel SGX… (which I think we shouldn't)
Hi there!
> 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.
Thank you for choosing the "strong random key" rather than "sketchy PIN+SGX" option. This decision recovered my trust in Signal after the previous Signal PIN fiasco.
> Nope! It's very much incremental :)
That's great to hear, thanks so much!
I'm assuming the backup format uses a container (like Veracrypt volumes), which grows in size forever, and cannot be backed up incrementally. I ran into the same issue when backing up loopback LUKS volumes. An elegant solution in this case was switching to Gocryptfs which encrypts each file individually, but then can mount the entire folder as a whole with fuse. This means only modified files need to be synchronised to the remote.
I'm guessing the same reason why my house's front door and back door use different keys.
Most likely they have different keys for absolutely no other reason than the fact that they were bought/made separately. I honestly would prefer to have a single key to my building.
I moved phones before Signal backups were available. My old phone has years of Signal chat and photo history. I can scroll through the conversations, but since I activated Signal on my new phone, my old phone will not let me export a backup any longer. Is there a safe sequence of operations to let me recover the data?
Couldn't you re-register your old phone temporarily, just for the purpose of taking the backup¹, and later re-register your current phone? (In fact, once your old phone is registered, turn on airplane mode, and you should be able to re-register your current phone right away without affecting your old phone and the backup you're making there.)
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.
It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads.
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.
> It would be really useful to have more client-side control over media storage. That way, I could better manage storage growth without wiping entire threads.
> 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.
The issue I have with this is that it deletes the whole message, not just the media. In WhatsApp, you can delete media from the images/video folders and the messages remain in the conversation, they even still have the blurry preview iirc. In Signal, you end up with gaps in your history instead.
Thanks, that’s helpful.
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!
On my Samsung: Settings >> Device Care >> Storage
Does that give you per-attachment insight?
I think you're talking about Android settings, though, not Signal settings?
To your point: What I am missing with Signal:
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.
Creating signal backups for iPhone users is _really_ hard. The only way to do it is to get a backup from the Signal Desktop app, which is also non-trivial because in recent versions of the desktop the decrypt key is also encrypted and store in keychain.
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)
I am happy to see Signal charging for premium features.
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.
> being able to switch between two iOS devices without a 3rd iOS device
I have moved Signal from an iOS device to a new iOS device multiple times. Why do you need a 3rd one?
I have two phone numbers.
On the same iOS device? I didn't know that iPhones supported multiple SIMs!
Yeah! You can have many eSIMs, but the iPhone only has two radios, so only two SIMs can be "active" (connected to towers) at any time.
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...
> This is an awkward edge-case that would be ameliorated by allowing local file backup / restore.
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.
It's eSIM: https://support.apple.com/en-gb/119606
Still, didn't know it was possible to have multiple numbers on the same iPhone :D
It's been a very pro-user development. You can buy an eSIM using an app these days. So when you travel, you can just download an eSIM for the country you are visiting if your home provider doesn't offer competitive international packages.
I must have been living under a rock, I didn't know that.
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?
Identity verification depends on the country. In certain cases there may be limitations. There are many eSIM sellers, like Airalo, Jetpac, Saily, Holafly and more. You can buy the eSIM with an eSIM package (for data, mostly, but some also sell voice/SMS) for a country or region, activate it (or wait for it to activate when the phone connects to a local network at the destination) and use it.
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.
That's really cool! I'll try that next time I travel in a different country instead of buying an expensive data package to my provider!!!
I don’t know how it works but I would guess that the KYC stuff happens with the resellers (who make the apps). So the resellers have some due diligence of identity verification then they make some guarantees to the telcos. Otherwise, it would be a vector for scams and crime.
This is really great. I've managed to convert a few people to talk over Signal and while I am backing up my chats to my home server (I see you will be offering something like this in the future), this wasn't really an option for the people I converted over to Signal, so they were constantly afraid that they might lose the pictures or the chats if something happened to their phone.
I know, you can download media and save it through something else, but most people just opt-in whatever is default. I think my only suggestion would be to make it real clear or even maybe have some sort of counter that says something like "39 images are no longer backed up" or "8374 media items are NOT being backed up, 507 are in backup, 29 will be removed tomorrow". This could be directly on the backup page, I'm not currently running the beta build as I installed the apk, but if it's already on there, scratch the feedback!
Thank you again for all your hard work on this, it really is appreciated (financially too!)
Without paying for remote backups, can I just manage my own backup on my own hard drive, and restore it when I want to?
Yes! That has been supported for a long while. At least on Android, go to Settings -> Chats -> Chat Backups. Set up a schedule and a passphrase and a folder, and it will export your chats every day.
I do that and then sync that folder with another computer using SyncThing.
> I do that and then sync that folder with another computer using SyncThing.
AFAIK SyncThing only monitors for changes between files with matching names, and Signal stores each backup with a separate (timestamped) filename. Are you storing every day's backup individually, or do you have some tool for deduplicating?
Encrypted backups can't be deduplicated unless the encryption is flawed. There shouldn't be a way to tell that one Signal backup is somewhat related to another, unless you have the passphrase.
That also means that Syncthing can't do better than sending the full backup. But if you're syncing via wifi (e.g. at home) it's not really a problem anyway.
> Encrypted backups can't be deduplicated unless the encryption is flawed.
Would you mind elaborating on why this would be an issue? 1) Tools like borgbackup provide the exact functionality you're describing and considered secure. 2) Encrypted file systems also don't re-encrypt your entire HDD whenever you change a single file.
> Encrypted backups can't be deduplicated unless the encryption is flawed
This isn't an encryption problem; each device can only have one instance of Signal installed, and the latest backup (assuming it has terminated successfully) is a superset of the previous ones (aside from any messages that have dropped from retention, which you presumably don't want to be preserving, by definition).
"Deduplicate" in this context means ensuring that you only have N backups in your remote storage, rather than cumulatively storing every day.
Signal has always between one and two backups, it removes the old ones.
Only on Android, not iOS.
It's not Signal's fault that Apple does not let you access the most basic feature of an operating system - the filesystem.
They do and have done for years now. There’s been a files app since 2017. They’ve had Advanced Data Protection available for iOS backups since 2022. Signal has just been lazy and found maintaining the Android backups to be a pain, so they refused to implement it for iOS.
ADP is off by default (this is why iMessage isn’t really e2ee), and importantly, isn’t available in all countries.
I believe in the UK you are legally barred from having access to iCloud ADP.
> I believe in the UK you are legally barred from having access to iCloud ADP.
Apple are still busy fighting the UK government on it in closed-court.
Apple-bashers can continue their hate, but give Apple their due:
Can Signal on iOS not save in the Files app like any other app that uses documents?
From the point of view of iOS, yes it can (the person you're replying to is wrong, as explained by the other person who replied to them). But no, the Signal iOS app does not currently have that functionality.
They did support it since they released the Files app, as Signal shows. Nothing changed all these years, yet they're now rolling out backups for iOS too, so the technology is already there.
I do not see anything like that in Android 14 uLefone Armor 24 is on 14 vendor build. I've had to use a dodgy app to back up messages.
>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.
Yep. Local backup generation has been around for at least a few years. You can have signal make a backup for you every day. You just need to get it off the device. This looks to be adding a remote option for this existing feature.
Only on android, not ios
I don't get this. The local-only backup option is already encrypted. Why can't they include an option for me to upload it somewhere of my choosing, like Google Drive, or even using Android's built-in backup system, so I can do it for free (my current backup file is well over a GB)? I already donate $5/mo to Signal Foundation; building a paid-only backup solution gives me a bad taste.
I even wrote a small Android app to do GDrive uploads of the encrypted backup file, watching the local backup directory for new files. (It broke with an Android version update and I haven't gotten around to fixing it.)
Kind of answered by a Signal dev here: https://news.ycombinator.com/item?id=45171576
The existing local-only option is legacy. I guess they haven't built on top of it because of that. The new option is better, and they say in the article that it should offer an option to do exactly what you ask for.
Monetize first is their strategy given this included statement:
> Our future plans include letting you save a secure backup archive to the location of your choosing
I already pay Apple for storage, please just back up my chats/media to iCloud.
This BS is why I completely stopped donating to the signal foundation.
The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit.
> The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit.
"They refuse to allow me" meaning "they don't add the features I want for free to the app they provide for free, so I complain".
The messages are yours, of course. But don't forget that you use their work for free. If you're not happy, go use the free work of someone else, I guess?
They are somewhat correct though, Signal has written code explicitly to prevent iOS users from including Signal data in Apple’s encrypted local and/or cloud backups.
Allowing encrypted backups was free for Signal, but they spent time and money to prevent it for iOS users.
Part of the code the wrote to prevent backups in question:
https://github.com/signalapp/Signal-iOS/blob/5590f09c3643f12...
It would be interesting to have Signal's justification for that, but I can totally imagine that it is a security feature.
As in: they may not want their users to inadvertently share their Signal messages with Apple.
Lot's of people have requested justification in related Github issues there, but Signal has not given a clear answer. If there was a security problem with the encryption process I believe a CVE or similar would have been in order because it would affect millions of users.
I was not talking about a security flaw.
I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default.
Signal is a nonprofit foundation, it's not like they are trying to squeeze their users with their own secure backup.
We are unfortunately rehashing the same arguments from Github, nothing prevents Signal from distrusting Apple by default.
But there is also nothing (except for some secret reason they refuse to elaborate) that prevents them from allowing users to actively chose to trust Apple. Except for their own internal reasons, that is.
It's the user's data after all. The user should be able to control and access it. Sensible defaults makes sense, but the outright refusal to explain why they prevent it is very odd. I have a decent "IT hygiene", I keep my operating system updated with patches, I don't download pirated/cracked software, I have hardware-enabled encryption on my storage devices, I have a good password for my local account, I encrypt my local iPhone backups.
Why should I not be allowed to include my Signal chats in those local backups? Signal has never answered that question, which is very strange.
> Why should I not be allowed to
Same as I said above: you are asking for a new feature. Their default is those 20 lines that "protect" the files. If they want to offer you a way to still enable it, someone has to do it. Someone has to work on the UX of it, maybe there is a need to explain to the users why it is less secure when this feature is enabled, and then there is work to do with the criticisms that will come next time someone shoots themselves in the foot because of this feature (because "Signal shouldn't have allowed that in the first place").
I know, you will say "it's not much". But everybody asks for their "small feature", and projects generally can't do everything that everybody asks them to do (and usually for free).
I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
> you are asking for a new feature
I think we have vastly different definitions of what is a "new" feature. This is not about adding a new feature, but removing an old bug.
> If they want to offer you a way to still enable it, someone has to do it.
They can just use the iOS system settings to allow users to enable/disable backups. This would be zero code needed. Zero maintainability problems. Zero UX. Zero unexpected data loss for customers. The settings for this is for all sane apps at Manage Storage > Backups > [Device Name] > [App Name].
> I know, you will say "it's not much". But everybody asks for their "small feature"
It's less than anything, it's removing a "feature", which should make things easier to maintain.
Signal _added_ the "feature" to disable the default iOS behaviour that user data can be backed up securely. This caused, in many users life, a bug of unexpected data loss. Signal caused that bug and that data loss by introducing this "feature".
Again, fixing this bug would not require a new feature to be added, but rather an unwanted bug to be removed by removing code needed to maintain it.
> I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
Not a single argument has been given why this would be more secure than the locally encrypted backup you can do yourself in iOS. In fact, it would be sane to suggest that any newly introduced claimed secure system is insecure until tested.
--
Edit: It's also worth noting that their disable-backups feature is a bit hack:y (see https://blog.eidinger.info/prevent-your-apps-files-from-bein...)
I understand that you are frustrated. And I understand that if you were to write Signal, you would do it differently.
Still, those 20 lines don't look like a bug to me. And Signal does not benefit from pissing you off. I was just trying to say that maybe, just maybe, there is a valid reason behind this.
The bug is not in the detailed implementation of the code logic per se, the bug is that it causes unexpected data loss because iOS users expect all their data to be backed up when they back up all their important data.
As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs. But it should never do that to begin with, it should have been designed/architected quite a bit differently.
You are free to carry water for Signal while they repeatedly refuse to even explain why they consider this a valid approach to handle the users data.
"I consider it a bug because I really want this feature" does not change the fact that it is a feature.
> As an example, a piece of code sending authentication credentials in plain text across the internet might in isolation be considered free of bugs.
This is not a good example. It's almost certainly a security issue. Unless you have a threat model where you absolutely don't give a shit about it, but we're not in 2010 anymore. Let me try to make another one:
As an example, a messenging app sending encrypted but not end-to-end encrypted messages over a server may be considered free of bugs. Adding end-to-end encryption to it would be a new feature, and it may well be out of scope for that particular app (ever heard of Telegram?).
Because you really want it doesn't make it a bug.
Today I learned that some people consider unexpected data loss a feature, and that removing such a "feature" is in fact the same as adding a new feature.
It's newspeak all in the software world. A first for everything I suppose.
> Today I learned that some people consider unexpected data loss a feature
I did not say that, and I am not sure if you genuinely do not understand or if you do it on purpose. Let me try one last time with simple constructs:
The lack of backup is not a feature. The lack of backup is a missing feature. The lack of backup is not a bug.
> and that removing such a "feature" is in fact the same as adding a new feature.
I have no clue what you are trying to say here, it's just gibberish.
> I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default.
The gap in understanding here is that Signal already trusts iOS by providing an app. It trusts it even more by providing notifications (with sender and content) that go through Apple’s systems. It integrates with CallKit to work with the Phone app. Putting iCloud alone in a separate bucket doesn’t make sense. They could’ve done this same backup with a 64 character recovery key and stored the data in iCloud. Signal made an intentional choice not to allow backups on iOS.
One can only hope that the point about supporting other backup endpoints/storage gets implemented sooner rather than having to wait several more years.
> They could’ve done this same backup with a 64 character recovery key and
Again: they could have, but it would have taken time and resources. The complaint here is not that Signal doesn't want to allow backups: they are just announcing a secure backup feature.
The complaint is that Signal did not do it earlier, and instead decided to prevent what they considered an insufficient solution.
> Putting iCloud alone in a separate bucket doesn’t make sense.
Of course it makes sense. What you say is akin to saying "end to end encryption makes no sense, because if you have to trust iOS anyway, you may as well trust the server".
Because I trust Android and run Signal there does not mean that I want it to auto-upload my messages to Google Drive. I don't see what makes it so hard to understand.
> One can only hope that the point about supporting other backup endpoints/storage gets implemented sooner rather than having to wait several more years.
Yes, I hope that too. On top of hoping, one could donate, to slightly contribute to paying the developers that work on it.
Have you read the article? They are working on it.
Thank you. I should have read to the end, and I'm glad they're planning to support backups stored on their users' media.
Where does it say that?
> Our future plans include letting you save a secure backup archive to the location of your choosing, [...]
I also missed this on my first skim of the article though.
“Our future plans include letting you save a secure backup archive to the location of your choosing”.
Their first cut at "working on it" is to require that we pay Signal to store our backups for us (45 days of media and 100MiB total is not a useful free tier; I have more than 1 GiB of messages/media spanning years), when that's an entirely unnecessary restriction.
I don't know what you do for a living but it's very common when writing and releasing software to do it in phases. Earlier phases have a restricted feature set and feedback from the field/customers/users experiencing earlier phases informs choices in later phases.
Unless you have direct insights into their dev process, your claim that the restriction be "entitely unnecessary" seems overly strong.
This is so incredibly important! I am very happy to see this, the fact that you could not do a backup on iOS and you would lose everything in case your device dies is the biggest drawback of Signal.
I still do not quite understand why I can't have the option to just back things up to iCloud (I do understand the security implications and I'm fine with it), but ANY backup solution is better than "your data is gone, tough".
Oh, now having reread the article I do understand why I can't have any other backup options. Paid subscription. Of course.
Feels like a really good way to finally get Signal to start working towards sustainability. I see myself paying just to help this incredible product continue serving its mission
> This is so incredibly important! I am very happy to see this, the fact that you could not do a backup on iOS and you would lose everything in case your device dies is the biggest drawback of iOS.
FTFY. It's originally Apple preventing its users from easily controlling their own data.
Apple 100% supports this, and has since day one, backing up securely to your local computer with no cloud in sight--and, in fact, has always been an industry leader on this, as they understand backups directly help their hardware sales--but Signal goes out of their way to block it.
> Apple preventing its users from easily controlling their own data
Could you please elaborate?
iOS has secure encrypted backups, and secure encrypted cloud backups using end-to-end encryption. Signal specifically disables these mechanisms.
Hiding relevant info behind "..." all over the post is annoying. Instead of reading through it like normal one has to read and click those little dots a dozen times.
I'll save you the trouble:
- Even if you choose not to back up your chats, someone you are talking to can do it, and your messages to them will be saved in their backup.
- 100 MiB of message storage is free.
- Last 45 days of media storage is free.
- Beyond that you have to pay $1.99 per month, and get 100 GB of storage.
- Backups happen once a day.
I found those bits useful, but also realized that this crude interface could be an accessibility issue. People would’ve been better served with these points directly inline.
> This has been a challenge for people whose most important conversations happen on Signal. Think family photos, sweet messages, important documents--
--or, of course, Joint Chiefs military coordination. I bet that was a fun surprise for the team.
And in that case it turns out the weakness was the device itself and the rest of the stack
The weakness was carefully going through the menus and manually adding a reporter to your group chat. There's not much the Signal team could have done about that.
AKA deliberate or a compromised device
Full message content seems to be free, with the option to pay £1.59pm for all media included (45 days of media included in the free tier).
Seems pretty reasonable?
I have unfortunately lost signal history on various devices. Most recently I lost my iOS history when I restored from a backup without following the right procedure to keep Signal history. I have the full history on my desktop macOS signal though.
Can I use this to restore my macOS signal backup to my iOS phone, so I once again have access to all my old messages on the phone?
From the tail end of the blog post:
> 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.
Are they still refusing to do anything about their painful 30 day device unlinking policy? If they can support full backups, surely they can accomplish this.
https://community.signalusers.org/t/dont-unlink-devices-afte...
Device queues need to expire at some point. At that point you aren’t “linked” anymore. What do you want them to do instead?
Well if somebody has a year of messages backed up on Signal's servers (with this new feature), and one of their linked devices gets turned on after two months of being turned off, they could surely pull the messages from the backup rather than from the normal queue but do it seemlessly so that from a user point of view the device just never got unlinked?
Without backups it makes sense to have a limit, like you said (though I join the person you replied to in wishing there was an option for it yo be more than 30 days), but their point is that once backups contain more than the last 30 days of messages that reason is no longer a blocker.
Hi there, Signal dev here. While we won't do this for you automatically, any time you link a new secondary device, we give the user the option to transfer their message history. It follows the same rules as backups: last 45 days of media for free, or all of it if you're a paid user. And even if you're not a paid user, you can request individual attachments be transferred from your primary device.
One caveat is that we don't offer this if you're re-linking an install that already has data but became unlinked. This is because we don't currently handle merging message histories. But if you cleared the data from the secondary install first, it would work. We're thinking of ways to make this smoother!
Thanks for the reply - I definitely hope you can someday get to the point where, using the backups, you can get rid of the 30 day limit for having a device online, such that the user experience is identical whether turning on a device for the first time in 29 days or the first time in 99 days - the only difference being the backend tech of where the messages are loaded from, which the user wouldn't need to know about. Or, if needed, the user getting a "this device has been offline for X days, please enter your backup password to sync all previous messages" alert.
There should really be a prompt/hint when re-linking to tell you about this caveat, I was looking at the blog post from the beginning of the year and wondering how come a feature isn't available after ~8 months.
Give users control over expiration and allow longer timeout.
So make signal pay for the storage forever and just ignore that most people won't understand the security risk?
I'd much rather be able to simply rsync the data folder for all apps on my phone without having the hardware KeyStore breaking backups installed on another device.
So close to finally being able to use signal again! I stopped using it when I switched from android to ios and didn't want to lose my message history
The main way I specialize messages at this point is basically 'Am I going to want this later'? If the answer is yes, I use email. If not I use Signal. It's interesting this was the most requested feature... it wouldn't be for me even though I love Signal.
It's important for Signal groups, because on a new device without a backup the groups you were in don't show up until someone sends a message in the group. Say if you were the only admin in an announcement-only group, no one else can send a message in the group, so that group is now lost to you.
The contact list on a linked desktop client will show all groups you're in, even though your main device doesn't.
On Android, if you know the group's name, you can search in the contact list, and the group will "magically" show up, even though it wasn't in the list.
Not the greatest UX.
This is the only backup feature I’m interested in. I use signal for the expiring chats.
I like this idea, but I don't think I'd ever be able to convince my wife to run that analysis on any particular message before she decides whether to email or to message me on Signal.
so do you email yourself messages/conversations you want to keep?
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.
You can imagine even the same person having some conversations they would want to keep and some they wouldn't.
If Signal is offering pay-for-media-storage, it would be nice to be able to pay to send full-resolution media. I’m a photographer and every image sent via Signal that isn’t zipped first is TOTALLY DESTROYED by silent recompression.
https://sneak.berlin/20210425/signal-is-wrecking-your-images...
Also, the donation spam in Signal doesn’t let me donate Mobilecoin from the wallet right inside Signal. What’s the point of having a payments feature if I can’t use it to pay you?
Please allow payments to Signal to be done in Signal’s native payment system.
I would love to subscribe to Signal in a privacy-preserving way.
Have you changed the image quality settings in the app to "High" - I see no mention of that in your blog post.
Yes, though IIRC the setting didn’t exist until after I wrote that blog post.
Even “High” is still total shit. I frequently contemplate hacking the client app and recompiling it to remove image recompression entirely.
> Signal doesn’t let me donate Mobilecoin from the wallet right inside Signal. What’s the point of having a payments feature if I can’t use it to pay you?
"Grift for thee, but not for me"
Finally installed signal. I have 220 phone contacts and 1 had it installed. Uphill battle here. WhatsApp and imessage are so prevalent in the UK
Meanwhile in Norway, of 520 phone contacts (of which many are things like cabs, restaurants, realtor from way back when) – 83 are on signal. And it's not like I have particularly privacy-conscious friends, that I know of.
That is an interesting datapoint. I'm going to keep it installed, hopefully then if somebody I know does install it they will see i'm a user.
Be the change you want to see in this world.
Yup. That's my plan from now.
Why do people want logs of conversations for years and years?
All of my Signal chats are set to 4 week expiry. Any media I want to keep, I save to the device.
I don’t audio record my conversations with close friends and family; why would I keep chat logs?
I don’t understand why people demand this feature. It wasn’t until the iPhone that people got accustomed to keeping every text for all time.
I don’t think it’s a healthy approach. For most of human history, you didn’t get a permanent record of private conversations you had with people. It feels like a type of hoarding, given how often people actually use/access their old (>4 weeks) chat logs.
I think the option to pay for more than 45 days backup is a smart way to get some cash. Kudos Signal for this.
Am I still required to add a phone number to use signal? What's the point of that. Every single person in the USA (and probably world) is quickly and trivially de-anonymized with a phone number.
nobody has access to your phone number from your account, and when subpoenad they are unable to provide it:https://signal.org/bigbrother/
'the point' is spam protection, alas
That article is out of date. It says things like "Signal still knows nothing about you", but Signal collects every user's name, phone number, photo, and a list of their contacts and permanently stores that data in the cloud.
That data is only protected by a pin (which can be brute forced) and SGX which has a history of being leaky. Researchers even demonstrated that data could be collected from Signal at one point. There are very likely side channel attacks that would allow Signal, or the government to collect the data stored in the cloud.
https://web.archive.org/web/20250117232443/https://www.vice....
https://web.archive.org/web/20230519115856/https://community...
This is the number one thing that is missing IMHO. I would gladly take it over back up options
Whenever the US promises you that your data are "secure" with their tech, remind yourself of this story:
https://www.eff.org/deeplinks/2014/01/after-nsa-backdoors-se...
https://en.wikipedia.org/wiki/CLOUD_Act
Ok smarty-pants. Explain exactly how the encrypted cloud backup leaks to NSA when the key to decrypt it sits on your device and safe alone?
> Losing it means losing access to your backup permanently, and Signal cannot help you recover it.
Oof... That's going to be tough to explain to normal users. "Sorry you've been paying for backups all this time, but you should have written down this code that you will only ever use once somewhere safe and remembered where it is. All your data is gone."
Not the right security trade-off for most people.
Absolutely the right security trade-off for Signal users. Anything else would devalue the entire product.
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.
The implementation feels uncharacteristically crude for Signal. Instead of seamless protections, you just get handed 64 characters you’re told to “store securely.” That’s not realistic: most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.
Sure but the key is still in a separate location from the backup. Signal can't decrypt the backup and if Signal is hacked someone would still need to get your screenshot to decrypt the backup. Not perfect but far better than an unencrypted backup.
when you're shown the code, it has 2 buttons: copy to clipboard and save to password manager. if you choose password manager you should be relatively safe...
I have 1Password installed and it prompted to save in 1Password. Worked perfectly. It even let me paste from 1Password on the verification screen. It was the most seamless password manager experience I've ever had.
It's this way, or it's not encrypted. The whole premise of their privacy model requires this.
Signal opens themselves up to government coercion and ruined reputation otherwise.
there are more than a few backup providers that do this security trade off with user acceptance of the risk. if this trade off isn't good for the user, they can use any other number of insecure backups.
If you're using Signal, of all things, that's probably a reasonable security/usability trade off.
Granted, I'm sure there are a lot of people out there who just use Signal because one of their more security-conscious friends/family members told them to install it, and so you're probably right for those people.
But, frankly, I can't see how else they could do it. Offering an unencrypted option, or weakening the encryption (by storing a copy of the key on Signal's servers) would make Signal not Signal.
If they were able to recover backups for you, then it wouldn't be secure. Right trade-off.
I know plenty of people who have inadvertently lost their entire messaging history because their phone broke or was lots and they couldn't transfer messages directly from the old phone to the new one. Signal allows you to export backups of messages to a file, but only on Android - the iOS version does not. This is a great feature not only for users who are less technically inclined than the average HN reader, but for any user who doesn't want to go through the tedious process of manually backing up their messages periodically but doesn't want to risk losing their message history if their phone has one unfortunate encounter with gravity.
My only concern reading this is that I hope they don't remove the manual export feature once this is rolled out. I know that that feature has been technically complicated to support, but it's important for users to preserve the option to maintain control over their backups, if they want to manage backups themselves, alongside the option of having a more convenient, automated approach.
Hi there, Signal dev here. We are absolutely keeping the local backup feature. More than that -- we'll be improving it to also be cross-platform and incremental, meaning it'll be much faster to both create the backup as well as sync it if you use a third-party folder-syncing solution (like syncthing or something).
This was my question and wasn't clear to me at all from the announcement -- that there was a roadmap for my own (not Signal cloud) cross-platform, incremental, secure encrypted backups as well.
(That presumably would let me store as much as I wanted without a fee).
I wasn't even aware of the existing "local backup feature" making it more confusing -- but reading the announcement I was like, wait, the only backups avail are in Signal cloud? that doesn't seem right, why can't I get my own backup file to do what I want with?
I feel like I now understand, thanks! Personally would recommend the announcement at least reference this future roadmap too, for clarity.
Please add some way to send it over FTP/FTPS/SFTP/SCP/WebDav/SMB/whatever so I can automatically backup to my own server that isn't on my phone. I need something fully automated or I won't often do it. This is also really important if the free space on my phone is less than the size of the Signal archive, and even more so if the Signal archive is more than 50% of the total space on my phone.
Will it be possible to backup messages and media to both Signal's cloud storage and local storage at the same time?
Will the secure backups also be incremental? I've gotten to the point where the backup takes quite a while to generate.
Isn't it what they mean with "we'll be improving it to also be [...] incremental"?
It's a real shame they aren't implementing this on iOS in beta before the new iPhone launch. Android has had backups for a long time, just locally. iOS users have been SOL so if anything goes wrong with the transfer and sync on your new phone, you're screwed.
Signal has done a very poor job of calling out that you can optionally connect your old and new phone via cable; the transfer will be much more stable and quick.
(No, this does not really help if you're one of the TouchID holdouts on an older SE)
Wow! I didn’t know this! So you’re saying that instead of using slower and potentially unreliable WiFi, I could just use the iPhone charging cable to connect two iPhones and start the Signal transfer feature? Is this documented anywhere? Thanks.
I only ever learned about it from an issue about shitty backups on the Signal repo(s). I'm out at a bar so not about to dig up the link but it's probably easy to find on GitHub.
> If securely back up all* of your text messages and the last 45 days’ worth of media for free. > If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month.
So after so many years of having a serious design flaw this poor substitute of a backup where you can't even save all your text for free is all they've managed to come up with?
> The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive.
Easy fix: let the user choose his own local/cloud storage location? (at least it's planned, maybe in just another decade)
I guess the reason WhatsApp lets you save all your text for free is they are making money off sucking up your data. I think ultimately this model will win, but I sympathise with Signal's approach.
WhatsApp offloads the storage to Google/Apple.
https://faq.whatsapp.com/481135090640375
Personally I've never understood the need some have for keeping chat histories. So this isn't a feature I'll use, but am sure others will.
And remember, Signal is a nonprofit. If you use it, and if you can, you should be donating.
I just had a use case the other day: my mom sent me a photo of a handwritten recipe from my great grandmother a year ago. I only remembered asking about asking, not about the response, so I was happy to still have that pic in my history. Had I downloaded the Pic, it would be lost among all the other crap I store all ocer the place. This way it was preserved with the context and even a voice message from my grandmother (not great grandmother) remarking on it.
It's my "old shoebox" with cherished memories of friends and relatives, some who have passed away.
Same.
Just save the pictures in the camera roll and important messages in your notes app of choice.
> In the past, if you broke or lost your phone, your Signal message history was gone.
this and completly useless multi-device support is the reason I don't use Signal... Telegram is not fully e2ee but it's way more convenient here.
Even XMPP with PGP would be lightyears ahead.
Telegram has such a good UX, like really good. Using as many devices as you want is a breeze, having multiple accounts on the same device. Their bots API is so easy to use.
Yes, it's at the expense of security perhaps... But I tried to get my wife to use Signal, as well as many friends and it never stuck bar one or two. She had to use telegram to contact someone and decided she liked it and continued using it.
It is what it is.
This has been the advantage, and the drawback, of Signal's security model from the start.
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.
>"Telegram is not fully e2ee but it's way more convenient here."
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.
Everything boils down to the thread model.
Not everyone is paranoid at extremum.
> PGP has no forward secrecy and OTR in XMPP lacks future secrecy, multi-device support etc.
Have you ever considered that perfect-forward-secrecy is not needed by 99% of the people? And PGP (OX) can be enough of encryption that gives you multi-device support.
Btw. OTR is long dead…
Future secrecy?
PGP does multirecipients natively, so any restrictions there would be in the XMPP client.
I have actually tried out PGP over XMPP and is was nice once it was set up. Absolutely no state. If the message somehow gets to you it just works. Sucked when the keys expired though:
* https://articles.59.ca/doku.php?id=pgpfan:expire
PGP support on XMPP isn't really that great. Forward secrecy might be a nice addition, even if it was semi-manual. There are compatibility problems between clients for encrypted media. You don't end up with an always encrypted archive like you do with email, but that could be considered an inherent weakness of instant messaging...
>Future secrecy?
Meaning --if-- when your keys get compromised the system recovers.
PGP lacks even forward secrecy, meaning key compromise alone allows retrospective decryption of every message you've ever sent.
OTR fixed that in... ...2004 https://dl.acm.org/doi/10.1145/1029179.1029200
Using PGP for secure communication in 2025 when you have option to use stateful E2EE over stuff like Signal is just bonkers.
If your keys get compromised then you would need new keys in any case.
I think that the sort of people that use PGP are more interested in not having any messages compromised, ever, while still retaining access to their old messages in a secure way. Contrast that with, say, Signal where a forensic tool like Cellebrite will allow access to retained Signal messages[1]. Sure, most of that is due to the inherent insecurity of encrypted instant messaging over, say, encrypted email, but the users in the end don't care. They just want to be able to communicate privately.
[1] https://web.archive.org/web/20201210150311/https://www.celle...
And if you lose your device your messages are compromised as well.
Forcing your paranoidal perception "is just bonkers".
>paranoidal
So either you're too young or too ignorant to have read the Snowden docs.
And?
You are aware that majority of the communication happens via email, which has absolutely NO encryption and can go through whichever relay and noone gives a flying duck about it?
Again, for the overwhelming majority simple PGP encryption without pfs is more than enough. Not everyone works for government agencies and have to maintain perfect secrecy. If you do that in your private life then yes - you are paranoidal.
I'm glad they're opening up a new revenue stream tied to something that provides real value to customers, like backups.
Hope they also may it easy to pay for family/friends, maybe similar to the "donate for a friend" they have already.
This is overcomplicated to collect money IMHO. All modern OSs can happily backup app files. It is a well-solved problem. If you find this backup method not secure enough (as Signal authors do), fine, encrypt the backup with a special key, exactly as described in TFA, and leave the resulting archive in a location for my chosen phone OS to back it up as it would. All the goals are accomplished, and without charging me money or limiting how many days of media are stored.
Do not get me wrong. Signal is great software and i'd gladly pay for it. Honestly. But not via this underhanded nonsensical way
Hi there, Signal dev here. The Android app does indeed allow you to export encrypted backups to your local device, which you can sync as you wish. That's not going anywhere, and in fact, we have imminent plans to make it better (cross-platform, faster, etc).
If you would gladly pay for it, maybe you could consider donating for Signal.
Do
I would love if they implemented a feature to prune media files larger than ~10MiB from the existing backup file. This way the file size would not grow to astronomical proportions so quickly.
It's a self inflicted problem. Rather than using some standard message format for backups (like eml / RFC 822), and putting them in a standard encrypted container if so desired, Signal chose to use some proprietary database format. Also they apparently changed encryption formats some time ago, and the current version can no longer decrypt the old messages.
After moving devices I can no longer access/decrypt my oldest image/video messages, they failed to import properly.
What is the reason for saving the end-to-end encrypted backup files on Signal backup servers instead of iCloud or Google backup service, as most of us are already paying for this storage?
The "Signal should exist" part of me is happy to donate $2/mo to help them keep the lights on, but I really did expect that to be an option alongside Drive/Dropbox/et al, not the only option.
Besides the obvious (they want/need the revenue from selling their own solution), many people using Signal do so in an effort to move away from Big Tech and/or on devices with custom ROMs.
Yes, but Signal mission is also to popularize E2E secure communication for normal users, whi usually don’t use a custom ROM.
FYI: "Signal backup servers" currently seems to mean either Google Cloud Storage or CloudFlare R2 according to https://github.com/signalapp/storage-manager/blob/e45aaf5bd1...
This seems to be an unfortunate case where a feature has a misleading name.
You already had secure and encrypted backups on your phone, which you could copy and restore, if you remembered to copy them, and write down a very long password.
The new feature is apparently a way for signal to sell cloud services.
I do think cloud based backups are very useful for less technical people. But it does not really matter if your (properly encrypted) signal backup lives on a google drive/apple cloud, or on a cloud service managed by Signal.
The encrypted backups do work, but Signal is really, really bad at indicating when and how to make them to use them for restoration. Most non-technical people I know are just resigned to wiping out their Signal history every time they get a new iPhone (and I know two people who abandoned Signal and went back to iMessage because of this), and even I've lost it a couple times.
It leaves sort of a gross taste in my mouth that a paid service is the fix for their unhelpful UX.
> You already had secure and encrypted backups on your phone, which you could copy and restore, if you remembered to copy them, and write down a very long password.
Did I? Where? on iOS I don't.
Edit: there is a transfer to a new phone thing, but that only works if the old phone still works. Which makes it not a backup (it's a transfer).
> if you remembered to copy them, and write down a very long password
All that BEFORE your phone was stolen/damaged.
Come on, $2/month is nothing, and doubtful would raise much of “revenue “. That’s a coffee a month.
While we are on the topic of Signal, does anyone know if it's possible to have a lock/PIN to open the Signal app itself that's different than your device lock/PIN?
Threema has this feature and it's reassuring to know that people can't open my chats when I hand my phone to someone. Or if I give the device lock/PIN to someone I trust for backup purposes but don't want them to have access to chats themselves.
Last I checked this was not possible with Signal (at least on Android).
https://www.lifewire.com/how-to-set-up-android-guest-mode-47...
https://www.howtogeek.com/806247/how-to-set-up-androids-gues...
Sounds like you want Molly
For anyone else that's not familiar, this is referring to https://molly.im/ which looks like it's a fork of Signal. And looks like it interops with Signal, so you can talk to your regular Signal contacts as well.
That's very interesting.
My only concern with it would be how sustainable it is in the long term. I am using Threema currently, which has a plan for enterprises, so that seems more reliable but it's lacking in features and usability.
> My only concern with it would be how sustainable it is in the long term.
Another concern should be: can you trust molly? Cryptographers have been auditing Signal... who is auditing molly?
In addition, it looks like third-party apps (there are a few) that interface with the official Signal client maybe against Signal's TOS. They haven't enforced it yet from what I can see but it's a possibility and that's a fairy large risk IMO.
So it's stored on their server? I don't get why they can't simply store it safely on the apple or google user cloud like every other messaging app
I appreciate Signal and that the Signal developers provide a very useful service to the community for free.
I also know a large number of people who won't use it because it locks your messages up in its own walled garden. People use apps like this precisely because they want to have control over their own communications without any third parties interfering! I have never understood what kind of threat model they think they're protecting against by not letting people take their own backups and store them according to their own preferences. Whatever the reasons it is clearly a deterrent to wider adoption.
This announcement might seem like progress but I doubt it will convince any of the people I know who won't use it because at the end of the day it's still a walled garden. If and when the promise of the comments near the end of the announcement is realised and we can back up our own messages and media freely from our own devices to our own (presumably also secure) backup facilities then it will be much more interesting.
The key is 64 characters? Even if that key is made out of decimal digits that works out to 212 bits. That seems quite excessive for a symmetrical key you are hoping to have a user deal with directly. It appears that the usability of this scheme could be significantly improved by simply using a shorter key.
What's the specific use case that benefits from a shorter key?
The only interaction I can ever see having with this key is putting it into and taking it out of my password manager....
The article specifically suggests writing the key down in a notebook. A single incorrect digit and the scheme fails much later in a way catastrophic to the user.
Signal asks you to repeat the key immediately before even enabling backups. It cannot fail much later unless you modify the digit after the check.
A longer key makes typing a bunch of characters back into the phone much less usable.
Since phones have a lot of storage, then why not constantly backup locally and overwrite it for newer versions (opt in of course)? Signal already has large operating cost, so a cloud backup with the very low subscription cost is concerning. It would help Signal to get rid of sms registration and move to something less costy.
Or just GPG encrypt your messages and store it on some cheap shitcoin's blockchain for free forever storage.
Is that a real thing?
I can't believe Signal is doing this.
Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key. If a device with this enabled goes through the whole advanced protocol to receive a message (double ratcheting etc), then turns around and uploads it back to Signal’s servers with a static key, 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?
They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
Based on this post, the only way to actually opt out of this is to force disappearing messages to be enabled for a time under 24 hours for every chat, which is pretty frustrating.
Signal already lags other messengers in reliability, speed, and features. The reason people use it is for its uncompromising security. Shipping something that weakens that foundation undermines the reason people use Signal.
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
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.
There's a big difference to me between storing it on device and someone else's servers.
Sure, but you already have no way of knowing which one the other parties in your chats are doing.
I already sync my Signal backups to the cloud, because that's the most practical and time/cost-effective way to have a 3-2-1 backup system for my chats.
There's a difference between someone in your chats acting adversarially and Signal supporting/encouraging adversarial behavior as part of the way the app works. If Signal published a change to the protocol that removed forward secrecy, we wouldn't consider it a non-event and say "well anyone could screenshot messages anyway," even though that may be true. They're calling this "secure backups," but in truth it appears to reduce security
I don't think it's appropriate to call someone you're talking to with disappearing messages turned off making a backup of the conversation so they have the (non-disappearing) message history if they drop their phone in a lake as "adversarial behavior".
If you don't want them to have a history only communicate via disappearing messages.
This post says disappearing messages are included in the backups. You have to enable disappearing messages with a timer of less than 24 hours to ensure that you can opt out.
Sure but the backup happens each day and then gets overwritten/deleted when the next days backup happens (which then deletes the disappearing messages that are expiring express the next backup). It just ensures you have access to any messages that you’re supposed to have access to according to the timers on said messages.
That's not how forward secrecy works. Ciphertext isn't "deleted" unless the key used to encrypt it is also deleted. That's the point of Signal's cutting edge protocol. This undoes all of that.
I'd also wonder where this shared encryption key for message "backups" is stored. If it's available on all of my devices, I suspect it would be available on other devices as well?
The article says it is generated on your device and they don't have a copy. Sounds like a public-private keypair where you are responsible for managing the private key.
got it. doesn't Signal already have on-device keys with a session ratchet? why not back those keys up so one can decrypt the entire history on any device?
afaik the key material is regenerated for every message. new keys can be derived for every subsequent message you send, but only until you get a reply, then a new key exchange takes place. And the key material for message m1 cannot derive keys for the messages that came before m1. If the old key material gets properly deleted then there is only a very small window of compromise. backing up those keys would defeat the purpose of the ratchet.
yes, agreed, and isn't this feature re-encrypting all of the material without a ratchet or asymmetrical boxing?
Yes, it undoes all of the security features of Signal's encryption protocol.
I mean it says so right in the blog post
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. Your recovery key is the only way to “unlock” your backup when you need to restore access to your messages. Losing it means losing access to your backup permanently, and Signal cannot help you recover it. You can generate a new key if you choose. We recommend storing this key securely (writing it down in a notebook or a secure password manager, for example).
i missed that paragraph, thanks for pointing it out. i wonder what algorithm they're using here, and if we could use third party tooling to decrypt these messages on a local computer? it might be a pathway to some cool experimental third-party Signal apps
Why does it matter if everything is encrypted?
Why am I downvoted? It seems actually encrypted, https://news.ycombinator.com/item?id=45171740
> They’re calling it "opt-in," but it doesn't look like that's actually true? You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it. In group chats, it looks like a single person turning it on eliminates signal protocol for everyone in the chat.
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".
> Signal's threat model has never included "you are directly messaging an adversarial party and expect to retain control over redistribution of those messages".
On the contrary.
https://signal.org/blog/signal-doesnt-recall/?pubDate=202508...
> On the contrary
Well, no, that doesn't contradict what I said at all. That link isn't about treating the recipient of your messages as an adversarial actor. The recipient can still choose to enable it, if they want to provide Microsoft access to the messages they receive.
Huh? That is very explicitly about preventing the migration of your signal messages into Windows Recall. Not the threat model you discuss.
I think the difference is that this is all happening in the app as a supported flow. If simply enabling a toggle in Signal (likely without understanding the implications) is now considered "adversarial," then I think that's a problem
It seems plausible that the protocol could be designed such that the device doesn’t know the recovery key. The key serves three purposes: (a) identifying the backup when a user tries to restore it, (b) authenticating that user to the restore API, and (c) allowing the user to decrypt the 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.
>Signal is known for its cutting-edge cryptographic protocol, but this feature has the effect of throwing that out the window and replacing it with a single static key
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.
It's not opt in: signal protocol for a group chat is eliminated if one person in the group chat turns this on, whether or not you do. Communicating with someone who acts adversarially is different from Signal itself adding features that are adversarial.
If you're in a group and someone is backing up the messages, it only affects your messages in that group. All of your other chats are still secure as long as you're not using the backup frature.
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.
You can't have forward secrecy for something you want to keep for an indefinite interval. How many Signal users actually achieve forward secrecy anyway? They tend to want to keep their old messages available to them.
I know many people are of the opinion, paid features are a guarantee that you're not the product. I fear a slippery slope for money, it's premium features first, then essential features, then money tops security. Or replaces everything else, like with Firefox.
Shoutout to Signal team for another fantastic achievement!
As a fun evening read I'd like to remind everyone of Pavel Durov's gaslighting on how their approach of everything-leaks-to-server was the right way to implement "cloud backups" for Telegram.
https://web.archive.org/web/20200226124508/https://tgraph.io...
Nice to finally see someone competent show how it's actually done :)
Do backups get pruned over time? Is there an expiration? I don't think folks want old lost-key backups sitting around forever for quantum to catch up, right?
It’s symmetric keys, so quantum doesn’t matter.
<pedantry>
"On the other hand, symmetric algorithms such as AES are believed to be immune to Shor. In most cases, the best-known quantum key recovery attack uses Grover’s algorithm which provides a generic square-root speed-up over classical exhaustion in terms of the number of queries to the symmetric algorithm. In other words, Grover would recover the 256-bit key for AES-256 with around 2^128 quantum queries to AES compared to around 2^256 classical queries for exhaustion. "
- https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-stand...
</pedantry>
the paper itself concludes "the practical security impact of Grover with existing techniques on plausible near-term quantum hardware is limited."
That Signal data doesn’t just transfer like any other data on iOS when upgrading phones is seriously dumb.
Wrap it in whatever security deemed necessary (or make migration/backup opt-in), but just let the blob copy over like every other app on the planet.
This cumbersome backup nonsense is a senseless no more secure bandaid for a problem that shouldn’t exist in the first place.
I was always thinking it was a feature not a bug
The actual question I have now is: if backup and restore were not working before, why were the keys backed up via Google Play services?
Do I get this for free if I’m a monthly donator?
Doesn't sound like it, but just decrease your donation and buy a subscription. Donations are donations.
Signal is open source, so security claims can be verified unlike anything made by Apple or other Big Tech companies.
What does this have to do with the message that you replied to?
I meant to reply to another comment.
I'm confused, I've restored Signal from encrypted backups before. I did it like 4 months ago. What's this feature?
> I'm confused, I've restored Signal from encrypted backups before. I did it like 4 months ago. What's this feature?
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.
Cloud storage for your backup.
I would like to have the option to have chats without encrypting the media. It will nice to backup the media directly to a NAS.
I'm glad that this is opt-in (at least for now).
I wish they'd done that for all the other data they collect and permanently store in the cloud (name, photo, phone number, signal contacts, etc.) since you can't even opt-out of that data collection.
I wonder if now signal will finally update their privacy policy which still opens with the outright lie: "Signal is designed to never collect or store any sensitive information."
Signal has over $50m in endowments.
But their desktop app is built with electron.
It's extremely clunky (over 200 MB) very slow and probably inherits all electron's security issues.
I have noticed the same issue with desktop apps from Proton Mail.
Why is it that rich corporations with lots of money like shortcuts and don't care about the quality of thier software?
What is the UX for the 64 characters key? Does it at least use a wordlist (e.g. like BIP 39)?
Just 64 characters but they do integrate with a password manager and have a 1-click button to add it. The integration was pretty seamless and saved it in 1Password.
They need to add some free way to backup to my own server. I have my own raid array with backups sitting in my basement. I'll back up to that. I do not want to pay them for cloud storage.
Right now, theoretically, I can do this by backing up to my phone and then copying the file over. But, this has many issues. Firstly, it is manual, so it will happen way less. Secondly, it is not differential, so the storage requirements will explode. Thirdly, if my signal message archive is bigger than the free space on my phone (especially if it takes more than 50% of total space) then I'm just fucked — there's no way to back it up anywhere else. Fourthly, the backup system is EXTREMELY buggy, to the point that it takes me HOURS babysitting it every time I make a backup.
A good solution would be let me put FTP/FTPS/SFTP/SCP/WebDav/SMB/etc. credentials in the Signal app and have it do periodic differential backups to there. Let me decide if I want it to be encrypted or not based on my threat model. Tell my contacts if this is enabled and let me exclude and/or encrypt specific chats if you want to let other people apply their security model too.
Only supporting any reasonable (meaning automatic and convenient) backup system with their paid cloud and not supporting my own server smells like a money grab to me. This is utterly unacceptable in a supposedly non-profit app. I have no problem with their paid cloud being an option, to be clear.
Another problem with Signal is that they only provide an official Linux package for Debian-based distributions. This forces people using other distributions to either do repeated manual effort to pull it out of their .deb files or build it themself (which is made way harder than it should be), or rely on sketchy third parties for packags. Given how much privatea information goes over Signal, such third party packages are an extremely tempting target for anyone from criminals to national spy agencies. This lapse in security due to not packaging for any Linux except Debian-based Linux (or even providing an ideally auto-updating portable binary!) is a much larger security lapse than letting me backup to my own server conveniently. So, their cries of security concerns relating to backups ring hollow.
Overall, it's quite a shitty app. I only use it because the alternatives are worse.
I agree.
> Right now, theoretically, I can do this by backing up to my phone
You don't have this option on iOS right now.
That's great they are doing a paid feature, but I really just want my desktop to back up my phone.
They clearly think people have bad desktop security, and still don't want this to happen. Patronizing...
Edit on
> 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.
That's good, but they've said that before. I feel a bit burnt on this.
perhaps said too much on a whim, but why should I backup my Signal... or WhatsApp, or any other communications. live in the moment. let things pass. there is probably no fortune hidden in it anyway...
IIRC, that used to be the opinion of the Signal project as well, but backups are such a requested feature it looks like they've finally decided to offer it.
If you don't want to back it up, don't back it up.
I'd like to replace all my SMS usage with Signal. I have every text message and photo I've ever sent/received. I want to do the same with Signal.
As an example that I experienced, I wanted a picture that someone took 2 years ago and sent to me on Signal. Since I am a data hoarder, I was able to retrieve it.
perhaps others see it differently
Hi Signal, can you please add a 'send without sound' feature.
FTA: “This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive”
Those costs are for doing backups to their servers. If this supported making encrypted backups to Google drive/OneDrive/iCloud/etc, they wouldn’t have those costs, and, AFAICT, that would not be less secure, given (also FTA):
“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. Your recovery key is the only way to “unlock” your backup when you need to restore access to your messages. Losing it means losing access to your backup permanently, and Signal cannot help you recover it.”
⇒ I think it’s more of “we were looking for a new revenue stream, and picked this as a way to get that”
There’s nothing wrong with that, but presenting it as “to get secure backups, we have to make costs” is disingenuous.
> ⇒ I think it’s more of “we were looking for a new revenue stream, and picked this as a way to get that”
This seems highly implausible given the 2 USD/mo pricing, the existence of a free storage plan, and the non-negligible operating costs that obviously do exist.
I'd be interested if you have data that supports the idea of the economics working out though.
I do not have data, but I do have arguments.
If the economics do not work out, why did they chose to create infrastructure and take on the burden of supporting it instead of implementing backups to the popular cloud providers, and not having that extra operational burden?
Also, iCloud gives individuals 2 terabytes of storage for $11 a month. OneDrive and Google Drive are similar. S3 is less than 3 cents/gigabyte (with extra costs for reads and writes)
I guesstimate backups will take less than 100GB per user. At Apple’s consumer pricing that is slightly over half a dollar.
So, if they buy storage at bulk and get a sufficiently high number of customers, I do not see why they couldn’t make money on $2/month.
Why would you want to backup chat messages? To me they are worthless at least after a few months.
Chat messages with some people can hold a lot of value. Nostalgia, recalling past incidents/events, missing someone, etc. Sometimes even the most trivial of messages can be looked at with fondness and longing.
I’m personally very glad that Signal finally implemented this. It’s been such a short sighted strategy to promote itself like a mass market messaging platform while not allowing people to keep, move and restore memories.
Since it’s opt-in, those who don’t want it don’t have to use it. They’re well served by the self-destructing message timers in chats.
Memories.
at least on android: you use a good old usb-c cable
A subscription. So the money squeeze starts.
What's your alternative?
Keep doing voluntary donations and wait for rich people to throw 50mil at it again?
Personally, I eat the cost of self hosting a small matrix homeserver. For developing a commercial project, I don't have an alternative, because e.g. being upfront and saying that you will eventually screw over your users eventually, is not an option in this economy.
Signal ain't exactly commercial project.
They didn't screw over anyone, for the past 8 years Signal was and remains free for everyone.
That service is not mandatory and didn't even exist before, so who exactly is screwed over?
Also, let me know where me and my friends can sign up on your particular matrix instance. What's your ToS anyway?
Okay, I mistakenly thought that Signal was burning on investor money like any run-of-the mill startup, but apparently they manage to run on donations similar to Wikipedia.
I also just learned that you can still backup without a subscription. That's great!
> Also, let me know where me and my friends can sign up on your particular matrix instance. What's your ToS anyway?
I said that was my personal solution and not an alternative to centralized platforms.
Asking to users to for a non-free service you are receiving isn't "screw over your users".
I want to have local backups and i want to be able to decrypt them myself.
It‘s my fucking data!
(I‘m on iOS)
measuring the temperature of hell… … … nope, still hot
haha, did they make this for the US gov ;)
Messages: Encrypted on device. Keys stay on device. Server has access to ciphertexts.
Backups: Encrypted on device. Key stays on device. Server has access to ciphertext.
Yapyaps: Is the backup a backdoor?
Great article not mentioning local backups were already available and what this is about. The state of affairs in iOS vs Android of the past feature and the next one. Details of all the kind are missing. WTF.
I would love to switch over to Signal, but the video call quality pales in comparison to WhatsApp and FaceTime. Add to that issues with even sending pictures or videos on Android, and it's a really hard sell.
I agree the video call quality needs improvement, but sending photos and videos has always been flawless on Android for me.
Lucky you! I pretty much can never send videos. I'm guessing it's something format / compression / transcoding related. Pictures are hit or miss; I think it's an infrastructure thing.
> Add to that issues with even sending pictures or videos on Android, and it's a really hard sell.
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).
There are a lot of GitHub issues about this (mine being similar to the last one)
https://github.com/signalapp/Signal-Android/issues/10135
https://github.com/signalapp/Signal-Android/issues/13098
https://github.com/signalapp/Signal-Android/issues/11263
https://github.com/signalapp/Signal-Android/issues/14293
Anecdotally, I've not had any issues on iOS (not that I'm needing to download media files often, but I have saved quite a few photos and the occasional video over the years and don't recall any failures).
Not that my experience invalidates that of people who have had problems, just sharing to say that the problems haven't been universal.
Thanks for calling this out. Apparently on iOS it's complicated, for some reason https://support.signal.org/hc/en-us/articles/360007317471-Vi...
On Android I tap on the image in chat, 3 dots and save. Way more involved on iOS. But at least I'll be able to point this out to my iOS peers.
It's actually not more involved on iOS (unless you're unlucky and have problems with it not working - I've no idea if it's a tiny minority of people who have problems, or if I'm in a tiny minority of people for whom it works, or if it's somewhere in between). But for those of us who it does work for, it's just as simple as on Android.
You can hold down on the media, and after about a second it brings up a menu where one of the options is "Save", you tap this and it will be saved to your camera roll (ie open Photos app to see it). If it's a message with multiple photos/videos, you so the same thing and all of them will be downloaded at the same time.
Or instead of holding down to get the context menu, you can tap once to open full screen view of the media which has the iOS "share" button in the bottom left, which you can use if you either want to just save one thing from a message that had multiple photos/videos, or if instead of saving to the default place - it's the standard iOS share function, so you can choose from "save to photos" (ie a the default like above), or "save to files" (accessible from the iOS file manager or from other apps), or share directly to a different app (like an email client, or an FTP client if you have one installed, or to an app like DropBox, or any other app you have that supports the OS-wide share menu).
TLDR: The help page you linked to, the top part of that iOS section (that makes it seem complicated) is just explaining how to find an overview of all previously shared media for a contact/group, and then download from there, but you don't need to do that to download it if you're already looking at what you want to download in the main chat window. The bottom part on that page is my second option from above, which is basically identical to what you say about how to do it on Android - just 3 touches (press image, press 3 dots on Android or share icon on iOS, then press save image). But it's actually the more complicated way, with a 2 touch option available (hold down on image, then press "save" :)
(p.s. to any Signal devs reading this, if you'd like to offer a free backups subscription in return for me continuing to evangelise, or beta testing on my iPhone... feel free to reach out :P
And, although personally I'm more keen on the future feature or backing up either to iCloud or to my own server, may I make a suggestion that, if paying for you to backup media, I'd prefer to be able to pay for a "family" plan - as I've moved several family members onto Signal and would like to be able to gift them free backups rather than tell them all to start paying. I suspect I'm not the only person who would think an option to share storage with 5 or more family/friends would be worth paying a bit more than your current single-account price.)
Are backups really necessary? I have always regarded texts (over Signal or SMS) as ephemeral. No one is or should be sending valuable information over Signal, and if you happen to receive something you want to keep, you can always do so manually.
Why should information on Signal be ephemeral on Signal?
Signal is one of the few "privacy-first" services. But it is not just about privacy, it is also about having as many users as possible, which is actually important for privacy. If only people who really have "something to hide", then just using the app makes you a target. If instead it is used by millions of people for grocery shopping and dinner planning, then whoever really needs the privacy features will not stand out. The third is, of course, making money, because, of course, none of that is free.
That's why features like backups are important. Many people want them, maybe not you, but Signal is not just for you, it also makes money. By the way, that's also the reason why there are some privacy compromises, like contact discovery and the use of phone numbers, because they feel like done right, it is worth it. Note that have partially addressed both of these problems.
My friends and family chats are on Signal because they're seamlessly cross platform. Not feeding Facebook is just a bonus.
For many people the messages are meaningful long term (including myself), and I consider ability to preserve your personal data as a base electronic right.
How should users send valuable information then, if they require E2E encryption?
I sometimes SCP things directly between me and someone else's home.
Why do you think our should not? Sincerely asking.
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
I did not mean to say that there are better options for encrypted communication. My point was that my use case is texts like "I'll be in the gym at 6:00 bro", not things that I really want to keep or backup. If someone sends a picture or a file that I want to keep, I can already do so manually.
My use case is everything from yours, up to deep personal conversations, and photos and videos that I'd like not to lose.
I don't feel like backing these up manually; it's a computer, and its job is to do tedious, repetitive, easy-to-forget tasks so I don't have to.