add a local backup service implementation with encrypted backups

[thestinger]

There's currently only adb backup and the sample LocalTransport backup service used for testing.

There can be friendlier frontends to adb backup but it requires enabling developer options and at least temporarily allowing adb access from a trusted computer which is quite bad even if the user doesn't make it permanent. Instead, there should be a proper non-sample backup service implementation providing at least the ability to generate encrypted backups saved via ACTION_CREATE_DOCUMENT so the user can save them directly to a sync service able to act as a storage provider or to shared storage as a last resort. If possible, it would be nice to offer a fair bit of control over the subset of data to back up similar to how adb works.

[captainhook]

Would this work for apps that have android:allowBackup set to false? I'm assuming not as that would require a workaround to adb backup, and onus of enabling backup is up to each app developer… but some app really do use it unnecessarily. If the backup is local and encrypted then the user should have ability to backup, the data belongs to the user.

[captainhook]

Would this work for apps that have android:allowBackup set to false? I'm assuming not as that would require a workaround to adb backup, and onus of enabling backup is up to each app developer… but some app really do use it unnecessarily. If the backup is local and encrypted then the user should have ability to backup, the data belongs to the user.

[thestinger]

This won't use adb backup, it will use the backup service implementation which presumably shares a lot of the infrastructure but it's not entirely the same thing.

It's going to respect the backup configuration of apps. If they mark files as excluded or disable backups completely, that won't be included. It's an important part of preserving the security model. If an attacker gets access to a backup, adb access or your unlock credentials that isn't supposed to let them get things like 2nd factor authentication credentials or your Signal key.

CopperheadOS doesn't roll back the security model compared to the Android Open Source Project. It's not something we'll consider doing. If AOSP / stock can implement a security feature at the expense of some convenience then we should certainly have it too. Our goal is taking things further and rolling back a useful security feature is completely opposed to that.

[thestinger]

This won't use adb backup, it will use the backup service implementation which presumably shares a lot of the infrastructure but it's not entirely the same thing.

It's going to respect the backup configuration of apps. If they mark files as excluded or disable backups completely, that won't be included. It's an important part of preserving the security model. If an attacker gets access to a backup, adb access or your unlock credentials that isn't supposed to let them get things like 2nd factor authentication credentials or your Signal key.

CopperheadOS doesn't roll back the security model compared to the Android Open Source Project. It's not something we'll consider doing. If AOSP / stock can implement a security feature at the expense of some convenience then we should certainly have it too. Our goal is taking things further and rolling back a useful security feature is completely opposed to that.

[thestinger]

If you don't like that an app disables backups, change it in the manifest and sign it with your own key. Can trivially do that even without having the source code of the app. There's quite possibly a good reason for the app disabling backups or excluding certain files though.

[thestinger]

If you don't like that an app disables backups, change it in the manifest and sign it with your own key. Can trivially do that even without having the source code of the app. There's quite possibly a good reason for the app disabling backups or excluding certain files though.

[captainhook]

Absolutely makes sense. The apps that may do it 'undesirably' are very few so that can be worked around if necessary by resigning as you mentioned. Thank you.

[captainhook]

Absolutely makes sense. The apps that may do it 'undesirably' are very few so that can be worked around if necessary by resigning as you mentioned. Thank you.