Ask HN: Good resources for DIY-ish animatronic kits for Halloween?
4 points by xrd 1d ago 0 comments
Why the Technological Singularity May Be a "Big Nothing"
7 points by starchild3001 1d ago 8 comments
Signal Secure Backups
182 keyboardJones 90 9/8/2025, 4:43:39 PM signal.org ↗
The file is encrypted with the passcode and the database can be extracted.
https://github.com/bepaald/signalbackup-tools
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.
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.
plug your phone into a computer? Install Termux and use one of the countless command line programs designed to transfer bits over a network?
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.
adb pull no worky? At least for HN readers.
It may seem obvious now, but I know most people will forget and be puzzled if their phone suffers physical damage. A lot about this has mandatory manual steps.
The new offering is reasonably priced imo.
Glad to see they're finding potential revenue streams that don't compromise their focus on privacy and security.
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.
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.
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.
Seriously, why is the migration protocol completely different on the two platforms?
If you're curious, the reason that Android's current local backups aren't cross platform is because it was made a long time ago, and it's literally a dump of all the sqlite statements that can be used to recreate Android's sqlite database (encrypted with a strong, random, local key). So not the most portable!
But this new thing is all cross-platform, and in the near future we'll even be making our local backups cross-platform.
Because they don't want to make jumping to the competitor too easy.
For example, being able to see all media across chats, sort by file size, and optionally group by conversation would make it much easier to clean things up.
> For example, being able to see all media across chats, sort by file size, and optionally group by conversation would make it much easier to clean things up.
I have good news for you: this already exists.
On Android:
Settings >> Data and Storage >> Manage Storage >> Review Storage
This allows you to view all of your media, files, and audio across all chats, sorted by the amount of storage used. You can also delete those files individually without affecting the rest of the chat.
You can also do the same thing within a conversation.
I’m also hoping similar media management options are available on iOS and desktop, since I use Signal across devices.
By the way, does Signal treat synced devices (like desktop or a second phone) as “replicas” vs a “primary”? If so, does this affect how storage or message history is handled between them?
Would appreciate any insight from folks familiar with the technical side of this!
From a product perspective, being able to switch between two iOS devices without a 3rd iOS device shouldn’t be a premium feature.
Please consider enabling local backup and restore for a single Signal instance on iOS.
I 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."
The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit.
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?
https://community.signalusers.org/t/dont-unlink-devices-afte...
Seems pretty reasonable?
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.
FTFY. It's originally Apple preventing its users from easily controlling their own data.
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.
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.
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.
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).
(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.
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...