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!)
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?
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.
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.
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.
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:
1. they are going in all guns blazing fighting the UK government instead of rolling over
2. if they succeed, I think they well-deserve the credit.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.
> Our future plans include letting you save a secure backup archive to the location of your choosing
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?
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...
As in: they may not want their users to inadvertently share their Signal messages with Apple.
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.
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.
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.
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.
--
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...)
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.
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.
> 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.
It's newspeak all in the software world. A first for everything I suppose.
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 also missed this on my first skim of the article though.
Unless you have direct insights into their dev process, your claim that the restriction be "entitely unnecessary" seems overly strong.
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.
Could you please elaborate?
iOS has secure encrypted backups, and secure encrypted cloud backups using end-to-end encryption. Signal specifically disables these mechanisms.
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.
--or, of course, Joint Chiefs military coordination. I bet that was a fun surprise for the team.
Seems pretty reasonable?
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.
https://community.signalusers.org/t/dont-unlink-devices-afte...
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.
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!