signalapp / Signal-iOS

A private messenger for iOS.
https://signal.org
GNU Affero General Public License v3.0
10.83k stars 3.04k forks source link

Cannot back up messages on iOS #4300

Closed hdevalence closed 5 years ago

hdevalence commented 5 years ago

Bug #967 from four years ago is related.

This functionality works on Android and is broken on iOS.


Bug description

Signal messages on iOS cannot be exported.

Steps to reproduce

Actual result:

The backup does not contain any message data.

Expected result:

The backup should contain message data, as on Android.

Device: iPhone X

iOS version: 13.1.3

Signal version: 2.45.1.1

michaelkirk-signal commented 5 years ago

Hi Henry, We're aware that this feature does not exist for Signal on iOS. I promise you, the reason for that is not a lack of a properly phrased Github issue. =)

As much as I would like for easy, efficient, and secure backups to have existed yesterday (or 4 years ago for that matter), posting duplicate issues like this does not help speed up the development process.

I'm closing this as a dupe of #967. Also, as noted in CONTRIBUTING.md and the issue template, we don't use Github to discuss feature requests - the community forums is where that can happen.

gojomo commented 5 years ago

@michaelkirk-signal Is there any discussion from Signal about this feature request? The last mention I can find is that it was "on the roadmap" about 4 years ago: https://github.com/signalapp/Signal-iOS/issues/905#issuecomment-143160772

hdevalence commented 5 years ago

With respect, I don't agree that this is a feature request and not a bug, because iOS would back up Signal's data correctly if Signal did not explicitly prevent it from doing so.

If filing this issue does not help speed up the development process, what would? It is clearly not an issue of lack of resources on Signal's part, and to the best of my knowledge there has been no communication from Signal on this bug for four years.

gojomo commented 5 years ago

To the bug/feature distinction, it's unclear if Signal is considering both "that iOS device backups don't work" and "there's no explicit export/import that would work across iOS or iOS<->Android" to be the same issue. They're different enough they might deserve separate analyses/prioritization (and thus different issues).

Regarding discussion, so many users have hit & reported this limitation across multiple forums, including some who've posted $1,000 in "bounties" for the export/import feature. So if the block is technical or related to resources, just saying you'd welcome an open-source contribution providing the functionality, with some idea of what the acceptance criteria for such a contribution would be, could cause it to arrive.

But the lack-of-comment plus lack-of-progress makes it seem that Signal's deprioritization of this functionality might instead be ideological or idiosyncratic, rather than tehcnical/budgetary. For example, perhaps Signal doesn't believe it's possible to match the Android functionality securely, given other tradeoffs of the iOS platform, or has some "grand plan" for "doing it right" at some arbitrarily far-off future when some hoped-for iOS changes arrive.

If either of those are the case, sharing some of your reasoning, as has been done for Signal's other frustrating decisions (like "must use phone numbers via native contact list as master IDs", or "no federation or unofficial clients attaching to our serves"), would be a kind thing to do for your iOS users, who are perplexed & suffering historical-data loss due to this mysterious functionality gap.

nabeelr commented 3 years ago

This is quickly becoming a deal breaker of a bug for me as well.

Security conceptually is about trust, and being able to manage and manage access to data in clear and predicable ways. Setting up a system that can easily cause unexpected data-loss with no backup method is not secure. Just because you're controlling unintended gain of information by a 3rd party, doesn't mean you can ignore the unintended loss of the information for the 1st party.

No one would ever argue that a virus that simply destroys data on a device with no way to export data is secure. Arbitrary code execution aside, security is about trust, and if I can't trust that Signal will not lose my data, or will allow me to back up my data, it is inherently insecure. In the real world, the "virus" is an unexpected destructive drop of your phone, a hardware failure, or theft.

People need to be informed of the consequences of their decisions and be permitted to make their own decisions regarding their data. If they want to replicate and export it, they should be allowed to after being informed of the risks.

The fact that Signal doesn't back up in iTunes encrypted backups, or to iCloud is a huge bug, because as a user you're not informed that this is how Signal handles your data come replacement time.

To see tickets like this closed, and others sitting dormant for years without so much as an explanation for why this direction is being chosen is disheartening to say the least, and breaks trust with your users. Again, security is about trust.

gojomo commented 3 years ago

Notably, in recent versions, Signal finally added a feature where, in the case of an orderly device transfer, you can transfer message history to another device, locally. See: https://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages#ios_restore (& media coverage of the feature at: https://www.theverge.com/2020/6/9/21280664/signal-chat-transfer-account-data-ios-iphone-ipad-encrypted-messaging).

But, this provides no 'backup' ability (to protect against theft/loss of devices), and automatically deletes everything from the 'source' device. Given Signal's patronizing approach to not-trusting-users in this, I kind of wish iOS would offer some way override them, allowing a knowledgeable user to reproduce a 'source' device's app storage (& other entangled device identifiers) exactly into a backup (and then to a replacement device). For a device and sotware to be loyal to a user, the user's preferences should ultimately rule over any software they install, moreso than any SaaS provider like Signal Inc.

nabeelr commented 3 years ago

Well, more to the point, it's a "destructive" data transfer, because all the data on the source device gets destroyed immediately after. If there was a problem with the new device, you're fucked. And that's about as polite as I can put that.

It's really not acceptable. Honestly, had I known this going into it, I would have never started using signal in the first place. Unfortunately, I was able to persuade a large circle of friends and family onto it, and we're stuck now.

nabeelr commented 3 years ago

Ironically, I'm sure if your device was jailbroken, you could back it up.

estiens commented 1 year ago

Should not have been closed, glaring bug. Even export database only would be a huge improvement

nabeelr commented 1 year ago

As more time has gone by, I'm convinced the Signal team resents their users and has no interest in solving issues that the vast majority of their users want fixed.

They've put lots of wasted dev time & work into creating Signal Stories, a feature no one asked for, wants, uses or cares about, instead of addressing real concerns and issues we all have, in a misguided attempt to compete with apps like Snapchat.

There's a reason apps like Facebook Messenger, WhatsApp, Snapchat, Instagram Messenger, and iMessage are far more popular, & there's a reason why it's next to impossible to convince non-technical friends to use Signal: Because it's just too atrocious an experience for a normal person to put up with, and the Signal team, in a bout of arrogance, refuses to acknowledge or address these issues.

The barrier for adoption is just too damn high, when buying a new phone, or switching platforms loses all your messages.

No sane person puts up with that. But Signal seems to be happy to toil in obscurity indefinitely.

The Signal team needs to learn to have user-centric design goals if they ever want Signal to have more than a Single digit percentage market share.