@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.
990
442