App manifest allowBackup="false" reasoning?

[ryan77627]

Hi all, I was making a (long overdue) backup solution for my phone in case anything were to happen (using LineageOS's SeedVault utility) and noticed Syncthing was in the list of apps that do not allow Application data to be backed up. As per the manifest android:allowBackup="false" is present, so this is definitely the case. Just wondering why this decision was made and was wondering if there was a way to make it so syncthing could be backed up using the default android utilities. I ask this because I am aware you can backup and restore configurations from within the app, however that requires both manual intervention and the exported configuration is unencrypted, unlike SeedVault's. I'm not familiar with android app development so if there was a reason behind this I wouldn't be aware of it, unfortunately.

Thanks for any information!

Version Information

App Version: 1.20.1
Syncthing Version: v1.20.1
Android Version: LineageOS 19.1 (Android 12)

[tomasz1986]

It's because of 95c2f7d.

I've encountered the same problem recently, and frankly, I've been thinking about making a PR to change this setting, simply because backing things up on Android is already a nightmare, so why make it even harder… especially since there're no such restrictions in the normal version of Syncthing. Yeah, sure one could grab the key and impersonate the device this way, but again, this is no different than copying the files from the user's config folder on a desktop PC, and also, once you've got physical access to the device and its file storage (regardless of whether it's the PC or the phone), it's already over.

The ADB backup itself requires to have both debugging enabled and the user is forced to input their password every time when trying to perform the backup too, so it's not like you can just connect somebody else's phone and back up everything you want any time.

The only reason why I didn't proceed with the PR was that I started reading more about allowBackup and found out that there were at least a few different options that needed to be set depending on where you wanted to allow the backup to go to (ADB, Google Drive, etc.) and what exactly should be backed up. It was all a little bit too complicated for me, especially since I couldn't even test the Google Drive backup (as I don't use any Google services on my Android devices).

Just in case someone cares enough and wants to work on this, all the required information seems to be available at https://developer.android.com/guide/topics/data/autobackup.

[ryan77627]

I agree with your sentiment on this @tomasz1986. The fact that the built in backup button will still export your private keys (and the app already acknowledges this) is enough for me to consider having the key removed from the manifest. I'll look into the options to see if I can figure out the proper ones. Again, my biggest gripe is the fact that the Android Auto backups are encrypted (whether through your Google Credentials for Google's implementation or through some key words with SeedVault's), while the app's aren't, they are just placed in a directory, sort of making the whole "Block because private keys will be exposed" point moot. While, this can be useful and I don't think the backup feature in the app should be removed, I don't think it should be the only option either. ]

[WhyNotHugo]

It's because of 95c2f7d.

Data folder contains private key, so one could imitate this node with the
backed up key.

The same thing that is seen as a risk (one could imitate the note with data from the backup) is also a feature (one can restore the node from the backup). Personally, I keep backups so I can recreate my device from those backups, so having the key there is a feature.

There seems to be an API for applications to indicate that they should only be backed up if the backup is encrypted (I've no idea why anyone would do an unencrypted backup, but whatever). There's a pretty thorough explanation here: https://community.signalusers.org/t/support-native-android-backupagent-based-client-side-encrypted-backups-and-device-to-device-transfers/19135

Maybe allowing backups only if the backup is encrypted is a reasonable compromise?

[ryan77627]

I feel like that would definitely be a reasonable compromise. Now, I only have experience with the SeedVault Frontend (never set up the Google One Native Implementation), but you can specifically exclude apps from the backup if you don't want the key to leave your phone at all. I don't personally know if the Google One implementation has this feature integrated as well, but it seems there's an apps button within the interface, presumably for this purpose. Perhaps someone using it could verify?

I've gone ahead and built a new version from the main branch with the allowBackup=true setting in the manifest for testing, however SeedVault reported it saying there was no data for backup, so perhaps I'll need to look further into it when I have a chance.

[wweich]

When restoring a backup, which include the DB, you have to make sure that the synced files are restored exactly as they were when the backup of the DB was made, or you risk data loss.

[Catfriend1]

When restoring a backup, which include the DB, you have to make sure that the synced files are restored exactly as they were when the backup of the DB was made, or you risk data loss.

This is exactly why it feel it could be wrong allowing "normal users" to back up because when they restore a device they won't be made aware by Android's GDrive backup tools the synced data needs to be exactly in place. It would be better for the user to start from scratch, with the disadvantage of gaining a new device ID.

[tomasz1986]

I don't think that's really going to happen, because with nothing in place, there's no .stfolder either, so Syncthing isn't going to delete any data. It should just stop with the "folder marker missing" error.

[imsodin]

Relevant info from @Catfriend1 posted in a duplicate issue (#1826 (comment)):

I'm currently testing to allow the Google Drive Backup if the user opts-in using Android settings. See Catfriend1/syncthing-android@40eb7f5

Android dev docs: https://developer.android.com/guide/topics/data/autobackup
The docs say we can define what's included and excluded from the backup, e.g. the database should be excluded.

[jcz1]

@Catfriend1 some news? Have a test build?
Btw it is possible to disable quota in Seedvault (GrapheneOS), but i think it would be better to backup-restore w/o db because of consistency. Like auto or semi-auto config export-import.

[Catfriend1]

@jcz1 Please keep it quiet on this tracker, the change can be tested on Syncthing-Fork since v1.22.2.2+.