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.
It leaves sort of a gross taste in my mouth that a paid service is the fix for their unhelpful UX.
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).
All that BEFORE your phone was stolen/damaged.
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).
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.
Another concern should be: can you trust molly? Cryptographers have been auditing Signal... who is auditing molly?
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 only interaction I can ever see having with this key is putting it into and taking it out of my password manager....
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.
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.
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.
If you don't want them to have a history only communicate via disappearing messages.
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).
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".
On the contrary.
https://signal.org/blog/signal-doesnt-recall/?pubDate=202508...
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.
(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.
The exfiltration of which is as easy as exfiltration of database on device. You're not running an IDS scanning 100% of your device LTE traffic in case that happens.
>isn't that a roundabout way of replacing all of signal's protocol and its forward secrecy with a static key that has no forward secrecy?
It's opt in. And again exfiltrating the backup key is as easy as exfiltrating your messages from your device.
>You can’t know whether someone you’re talking to -- who may not understand the implications -- has enabled it
You can't know if you're talking to an informant or if your contact is running Android that's receiving security updates or if it's a zero-day on wheels, either. Tech doesn't solve human problems.
You (and Signal) can't control how the recipient handles your messages if you're not using disappearing. They could be copying and pasting your messages or taking screenshots. I don't see how the backup feature is any different.