Implement Backup/Restore

[crass]

It is a known issue that Chrome-based browsers on Android do not implement backup through the android backup mechanism. Apparently the official Google Chrome will only backup via a separate syncing mechanism to their servers with an account. I don't believe Vanadium has such a feature (correct me if I'm wrong), and so there is no way to backup Vanadium.

Since a webbrowser is one of the primary uses for computing devices and so usually has a lot of user data associated with it. In so far as its locked inside GrapheneOS at the moment, this give users less control over their data and is a kind of (unintentional) vendor lockin. Implementing backup/restore for Vanadium would allow users to feel more at ease switching to GrapheneOS knowing that it would be possible to switch back at a later date while keeping their data.

I see a variety of ways this could be implemented.

1. Update apk manifest to turn on backup
   • Could this be as simple as this?
2. Add needed code to Vanadium to implement backup
   • This may be more involved, but it seems fairly simple from a high level. I would imagine it being something like: Gracefully kill Vanadium -> backup profile. And the same when restoring the profile.
3. Re-purpose Google Chrome Sync
   • The naive way would be to add sync support to a server supporting this protocol of the users choosing. The downside is that the backup is not part of the OS backup service
   • An alternative way would be to have an OS component that triggers a sync to a local server on the phone
4. Add a session import/export to Vanadium via chrome extension.
   • This is probably a lot more invasive, but maybe there's a plugin already developed that can be repurposed (can Vanadium use extensions?)

Option 1 would be the least work, if that can be done. Otherwise I'm thinking option 2 would be the next least work, add code specifically for copying the Vanadium profile to/from the backup transport.

[csagan5]

The onBackup/onRestore logic is in https://github.com/chromium/chromium/blob/89.0.4389.78/chrome/android/java/src/org/chromium/chrome/browser/ChromeBackupAgentImpl.java

It would need to be enabled with:

diff --git a/chrome/android/java/AndroidManifest.xml b/chrome/android/java/AndroidManifest.xml
index e4845fe382a0..73396f3372b5 100644
--- a/chrome/android/java/AndroidManifest.xml
+++ b/chrome/android/java/AndroidManifest.xml
@@ -152,14 +152,13 @@ by a child template that "extends" this file.
         android:manageSpaceActivity="@string/manage_space_activity"
         android:supportsRtl="true"
         android:zygotePreloadName="org.chromium.content.app.ZygotePreload"
-        {% if backup_key is defined %}
+
         android:allowBackup="true"
         android:backupAgent="org.chromium.chrome.browser.ChromeBackupAgent"
-        android:fullBackupOnly="false"
+        android:fullBackupContent="@xml/chromebackupscheme"
+        android:fullBackupOnly="true"
         android:restoreAnyVersion="true"
-        {% else %}
-        android:allowBackup="false"
-        {% endif %}
+
         android:networkSecurityConfig="@xml/network_security_config"
         android:allowAudioPlaybackCapture="false"
         {% if enable_isolated_splits %}
@@ -1107,12 +1106,6 @@ by a child template that "extends" this file.
       <meta-data android:name="com.samsung.android.sdk.multiwindow.penwindow.enable"
           android:value="true"/>
 
-      {% if backup_key is defined %}
-      <!-- Backup keys are channel dependent -->
-      <meta-data android:name="com.google.android.backup.api_key"
-          android:value="{{ backup_key }}" />
-      {% endif %}
-
       {% if channel in ['dev', 'canary', 'default'] %}
       <meta-data android:name="com.sec.android.support.multiwindow" android:value="true" />
       {% endif %}

(I have no idea how this backup_key would otherwise be defined)

The current backup/restore logic only handles the bare minimum because of the reliance on Sync.

[dm17]

Perhaps if this happens, then little to no work will be required: https://github.com/Eloston/ungoogled-chromium/discussions/1395

Because a backup/restore effort like this will likely happen: https://github.com/Eloston/ungoogled-chromium/issues/667

[dm17]

Perhaps we can just have some less polished version of this? The centralized backup mechanism seems reasonable. Since seedvault is getting replaced, then the replacement should be able to backup the vanadium profile, right?