Public Signal Backups Testing

原始链接: https://community.signalusers.org/t/public-signal-backups-testing/69984

Signal is launching a new end-to-end encrypted backup system and is seeking Android users to test it on their staging servers. This system offers features like Signal-hosted backups, dynamic media offloading, a cross-platform backup format (Android to iOS), and optional free/paid tiers. The free tier backs up text content and recent media, while the paid tier offers 100GB of media storage. Backups are encrypted, disabled by default, and designed to prevent user association. Testers can use a self-updating APK, register a new account in the staging environment, and access the backup settings. The "ALPHA ONLY" section allows forcing free or paid tiers for testing. Optimize on-device storage dynamically offloads media. Feedback on bugs, confusing UI, missing features, and performance issues is encouraged. The rewrite of local backups is almost complete and will be launched shortly after. Key considerations: Disappearing messages set for expiry in less than 24 hours will not be backed up, but view-once messages are excluded. There is no current timeline for the beta/prod launch, but it will be at least several weeks. iOS testing is possible through linking an iPad.

This Hacker News thread discusses Signal's new feature: public backups testing. A user, godelski, raises concerns about Signal's communication with its community, particularly for an open-source project. They advocate for more blog posts explaining features and vision to build trust, especially as a security-focused app. They criticize the reliance on private communities for bug reports, finding it alienating. The lack of transparency, they argue, fuels conspiracy theories and infighting, pushing users to less secure platforms. Godelski also points out Signal's inefficient media storage, where forwarding images creates duplicates, wasting space. They suggest using soft links or a copy-on-write system to address this. They express frustration at the difficulty of getting technical answers from Signal's community, particularly regarding the potential security implications of storage optimization. They believe Signal's limited metadata necessitates better communication channels with its technically inclined user base to understand their concerns.

TL;DR You can test the new Signal Backups feature on Android on our staging servers. Grab the self-updating apk here!

Hello, everyone!

Many of you are aware that we’ve been working on a new end-to-end encrypted backup system for quite a while. Well, today, we’re finally ready to start testing it with external users

The new backup system fulfills so many of the things people have wanted for so long:

Hosted by Signal, so your data is safe even if you made a local backup but dropped your phone in a lake.
The ability to dynamically offload media so that Signal takes up less space on your phone, while still letting you download that media on the fly if you scroll back.
An independent backup format that is readable by all clients, so that you can do things like backup on Android and restore on iOS.
A generous optional free tier that will ensure that all of the text content of your messages is backed up, as well as the most recent 45 days of media.
A fairly-priced paid tier that allows us to offer 100GB of media storage in a way that is sustainable for us as an organization.

And of course these things are handled with the utmost care in traditional Signal fashion:

Backups are end-to-end encrypted with a strong key that only you have access to.
Backups are disabled by default.
Backups are structured so that the Signal service cannot associate a backup with a given user.
Payments are structured so that the Signal service cannot associate a payment with a given user.

Needless to say, this is a very large feature. It touches a lot of different pieces of the app, adds a lot of new screens, drastically changes the registration flow, and introduces scores of new edge cases and error flows. So, just like the username testing we did before launch, we’re putting a callout to forum users to test a staging build.

What is a “staging build”, you ask? To answer that, I’ll quote from the aforementioned username testing post:

Once you’re registered on staging, you can go to Settings > Backups. There, you’ll see the new UI for configuring backups.

Notably, at the top of that screen, there is a fun “ALPHA ONLY” section that lets you forcibly set your backup tier to be “Unset”, “Free”, or “Paid”. “Unset” is the default, and it means that this override switch does nothing. Choosing “Free” or “Paid” will forcibly put you in one of those tiers, allowing you to test paid backups without having to actually spend money. Important to note, though: changing this toggle before you go through onboarding will cause you to skip onboarding, and you’ll need to go grab your backup key from the backup settings yourself. I recommend going through onboarding first for the Free tier, and then changing this to paid afterwards.

To use the “optimize storage” feature I alluded to earlier, where we’ll dynamically offload media to save space on-device, go to Settings > Data and storage > Manage storage > Optimize on-device storage.

Otherwise, we encourage you to explore the UI like you would any other app. In particular, this is the type of feedback we’d love to hear:

Is there anything that isn’t working correctly (i.e. are there bugs)?
Are any of the screens or in-app explanations confusing? Do you feel like things could be described better or more clearly?
Is something missing? Is there a feature or capability that you’d expect to be present that isn’t there?
Is anything weirdly slow or otherwise performing poorly?

While you’re testing, try to test different edge cases. Send media before a backup, during a backup, and after a backup. Try out different password managers. Reset the app and restore the backup before the old one finishes. This is a staging build, where you don’t have any data anyway, so we hope this encourages you to test the restore process. It is possible you may hit rate limits if you re-register a lot – if that happens, just wait 12-24 hours and try again

Right now, testing is only available on Android. Just like username testing, you can download a self-updating APK here. New builds will go out as we fix stuff!

Backups cost money? How can I backup my data for free?
Local backups still exist, and they’re going to get much better! We have a rewrite of local backups that uses the new cross-platform backup format that’s almost complete. In addition to using the new cross-platform format, it’s also much smarter about only writing diffs for changed media. This means that creating new backups will be much quicker (seconds instead of minutes), and any external syncing tools you may have set up will be much faster. We’re planning to launch this shortly after the initial backup launch.

When is this coming to other platforms?
Soon™! The other teams are hard at work implementing these changes, but alpha testing like this is much more difficult on iOS due to platform restrictions. If you’d like to test something on iOS, you can always link an iPad – the code that imports your message history is largely the same code that restores a backup

What about disappearing messages? Do those get backed up?
We made the decision to exclude disappearing messages that have been read and are due to expire within 24 hours, or if the message timer is less than 24 hours, regardless of whether it was read or not. We chose not to exclude all disappearing messages because many people set 4 week timers on their chats for the purpose of tidiness, and we think it would be unpleasant to restore a backup just to discover that all of those messages are gone. We think this strikes a good middle ground, but we are interested in hearing your feedback during this testing period.

View-once messages are excluded from backups in all cases.

When is this going to beta/prod?
That depends a lot on what we discover during this initial testing phase! But it’ll be at least several weeks, and possibly longer if we discover any bugs that are particularly difficult to troubleshoot or fix.