Export & restore all settings

[uazo]

this patch is a work in progress, I need to talk to you about what to do.

1. not a problem in itself, but the ChromeBackupAgent code seems unused to me, that is, I couldn't find anything that could enable it in the chromium base code.
   in fact it is based on the presence of "backup_key" which however does not exist in any gn (ref)
2. the current code uses androidbackup in key-value pairs mode, the advantage is that I manage it as I want but it seems to have the limit of 5MB per backup. however this limit does not seem to me to be imposed by android (I have not found anything about it in its base code).
3. currently I backup profile preferences (native), local state (native) and SharedPreferences (java), ie everything that is managed by the settings. everything that is managed through sqllite is not covered.
4. sqllite dbs are not managed because they are open (therefore inaccessible) and above all because in general it is not enough to replace the file when restoring, because I would risk losing the current information present, since there is no management of when it is done the backup but above all the restore. theoretically I should study the structure of each db and make the inserts / updates necessary for correct management and keep them at each modification of the structure, unthinkable.
5. the most absurd thing in android is that the application has no management of when androidbackup does the backup or restore!
   and this is the main problem because to restore we have to relaunch the application, since some settings require it (always incognito or javascript jit and all about://flags).
6. and finally, the backup is not currently encrypted and goes straight to google's servers (for those who have it active), although this seems to be editable with backup_rules.xml as also written in Enable encrypted Backups #1431.
   seedvault seems to be a good alternative, but from what I understand it needs to be integrated into the android build so it is not possible to install it stand alone (I'm waiting for someone to prove me wrong)

however, point 5 is the most critical.
a possible alternative is to run bmgr ref as it does for logcat, so you can manage when the user wants to backup and restore, you tell me.
other alternative is to throw everything and start over, emulating BackupDataOutput to save the file when and where I want.
instead point 4 I would see it together with #244

let me know

[csagan5]

1. not a problem in itself, but the ChromeBackupAgent code seems unused to me, that is, I couldn't find anything that could enable it in the chromium base code.
   in fact it is based on the presence of "backup_key" which however does not exist in any gn (ref)

Is backup_key a remnant or something that somehow is activated only during the official Chrome builds?

Also: have you read this? https://bugs.chromium.org/p/chromium/issues/detail?id=661188 The backup logic was disabled at some point

2. the current code uses androidbackup in key-value pairs mode, the advantage is that I manage it as I want but it seems to have the limit of 5MB per backup. however this limit does not seem to me to be imposed by android (I have not found anything about it in its base code).

See the previous issue, perhaps it was a limitation on older Android versions.

• currently I backup profile preferences (native), local state (native) and SharedPreferences (java), ie everything that is managed by the settings. everything that is managed through sqllite is not covered.
• sqllite dbs are not managed because they are open (therefore inaccessible) and above all because in general it is not enough to replace the file when restoring, because I would risk losing the current information present, since there is no management of when it is done the backup but above all the restore. theoretically I should study the structure of each db and make the inserts / updates necessary for correct management and keep them at each modification of the structure, unthinkable.

I don't think we should cover the SQLite files; what is there anyways of user interest? cookies, bookmarks, saved passwords?

5. the most absurd thing in android is that the application has no management of when androidbackup does the backup or restore!
and this is the main problem because to restore we have to relaunch the application, since some settings require it (always incognito or javascript jit and all about://flags).

There is no way to detect a restore happened? But perhaps it will automatically close it before restoring?

6. and finally, the backup is not currently encrypted and goes straight to google's servers (for those who have it active), although this seems to be editable with backup_rules.xml as also written in Enable encrypted Backups #1431.
seedvault seems to be a good alternative, but from what I understand it needs to be integrated into the android build so it is not possible to install it stand alone (I'm waiting for someone to prove me wrong)

So #1431 would be useless for all those that do not have a rooted phone/custom ROM?

As for the backup going to Google servers: is this the functionality used when switching to a new phone? It works differently than the sync profile.

a possible alternative is to run bmgr ref as it does for logcat, so you can manage when the user wants to backup and restore, you tell me.

Would this require a rooted device as well?

other alternative is to throw everything and start over, emulating BackupDataOutput to save the file when and where I want.
instead point 4 I would see it together with #244

It depends from what we want to maintain; I would first study a bit further how backup used to work for Chromium on Android, to see if we can restore some functionality (and whether it is useful or not). In the end if we do not want to use the core Android functionality we could have some import/export of all settings and flags alone, in a file, but sooner or later we would start thinking about encrypting it etc which becomes scope creep.

[uazo]

is activated only during the official Chrome builds?

no, backup_key is completely without references
but, not working for google, i don't know exactly how they compile...

Also: have you read this? https://bugs.chromium.org/p/chromium/issues/detail?id=661188 The backup logic was disabled at some point

no, i saw now, they had taken it off and then put it back to not fix the build, but without reactivating it.
it seems they were afraid it would not work due to a possible overlap with the autobackup mode
that commit is from 2016, maybe something has changed today, because according to today's android documentation either you use autobackup or the key-value pairs mode.

I don't think we should cover the SQLite files; what is there anyways of user interest? cookies, bookmarks, saved passwords?

I don't know exactly, certainly cookies and offline pages and the history.
i dont think passwords, at least i hope not, i hope they are in something more secure than a sqllite db.
I will check.

There is no way to detect a restore happened? But perhaps it will automatically close it before restoring?

i know when it happens, after all the backup/restore is done by chromium.
what I don't know is who asked for it and when, because there is latency between the request and the actual action that is not under my control.
I think that I could ask the user for confirmation, but I don't know if it is possible, because I have not yet fully understood the concept of context / application and how it binds to the android ui, that is, if I can always and when I want to show of the activities to the user or if there are particular situations that do not allow me to do so (such as when I am called up by a service).

is this the functionality used when switching to a new phone?

yes, that's probably it is so

It works differently than the sync profile.

yes, it is quite another thing.

Would this require a rooted device as well?

I don't know for sure yet. I don't use adb root though, and it works.
I'll try.

but sooner or later we would start thinking about encrypting it etc which becomes scope creep.

the chromium code already provides encryption functions, but from what I have seen, they seem to me linked to the device, that is, when the device is changed it is no longer possible to decrypt what has been encrypted.
other ways I don't know, and, so far, I still don't know how to add external libraries to the project.

But perhaps it will automatically close it before restoring?

no, there is no force quit of the application.

[csagan5]

Also: have you read this? https://bugs.chromium.org/p/chromium/issues/detail?id=661188 The backup logic was disabled at some point

no, i saw now, they had taken it off and then put it back to not fix the build, but without reactivating it. it seems they were afraid it would not work due to a possible overlap with the autobackup mode that commit is from 2016, maybe something has changed today, because according to today's android documentation either you use autobackup or the key-value pairs mode.

I think it's worth restoring what has been deleted to see if it works.

I don't think we should cover the SQLite files; what is there anyways of user interest? cookies, bookmarks, saved passwords?

I don't know exactly, certainly cookies and offline pages and the history. i dont think passwords, at least i hope not, i hope they are in something more secure than a sqllite db. I will check.

Let me know what you find.

There is no way to detect a restore happened? But perhaps it will automatically close it before restoring?

i know when it happens, after all the backup/restore is done by chromium. what I don't know is who asked for it and when, because there is latency between the request and the actual action that is not under my control. I think that I could ask the user for confirmation, but I don't know if it is possible, because I have not yet fully understood the concept of context / application and how it binds to the android ui, that is, if I can always and when I want to show of the activities to the user or if there are particular situations that do not allow me to do so (such as when I am called up by a service).

How do other apps do this? Perhaps the restore only happens on "cold" files which are restored on restart, and the app detecting the restore will ask user to restart?

Would this require a rooted device as well?

I don't know for sure yet. I don't use adb root though, and it works. I'll try.

We should try with a non-rooted device.

but sooner or later we would start thinking about encrypting it etc which becomes scope creep.

the chromium code already provides encryption functions, but from what I have seen, they seem to me linked to the device, that is, when the device is changed it is no longer possible to decrypt what has been encrypted. other ways I don't know, and, so far, I still don't know how to add external libraries to the project.

That is why I am saying it is scope creep: because we should not do it.

But perhaps it will automatically close it before restoring?

no, there is no force quit of the application.

If the backup/restore functionality is used by other apps, there must be a way to do it safely. The browser is not different in this sense.

[uazo]

I think it's worth restoring what has been deleted to see if it works.

I wouldn't worry about that, I'd put a flag.

Let me know what you find.

• Floc: Interest Group Database + Aggregation Service
• Offline Pages
• Attribution Reporting (conversion_measurement_report)
  to check: content/browser/attribution_reporting/attribution_network_sender_impl.cc
• Opt Out Blocklist
• Media History
• Explore Sites
• Autofill
• Top Sites
• Password Manager
• Favicon
• Predictors
• Shortcuts on Omnibox
• Appcache
• Cookies
• Trust Token
• Explore Sites
• Web database
• Nel policies
• Quota manager

follow this

there are also other types of db based on proto files (chrome/browser/persisted_state_db/profile_proto_db_factory.cc): PersistedStateContentProto, ChromeCartContentProto, CouponContentProto, CommerceSubscriptionContentProto, MerchantSignalContentProto. apart from the first one that is used to serialize the tabs (currently under flag), the others do not know what they are.

That is why I am saying it is scope creep: because we should not do it.

but what if we simply did an encrypted zip?
EDIT: I did not know, no support for encrypted zip with the standard java library, too bad.
EDIT2: chromium however has already included the library javax.crypto
here the list of functions present in the base code: https://source.chromium.org/chromium/chromium/src/+/main:crypto/;bpv=1;bpt=0

[csagan5]

• Password Manager

But is it encrypted or not?

the others do not know what they are.

Most surely related to the functionality to follow prices and make purchases directly from the browser.

but what if we simply did an encrypted zip?

There is no "simply" in encrypted. It is better to provide no encryption rather than a malfunctioning one.
Once the file would be created, would other apps be able to access it?

[uazo]

But is it encrypted or not?

the password yes

Once the file would be created, would other apps be able to access it?

only if you know the decryption key

[csagan5]

But is it encrypted or not?

the password yes

https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/os_crypt_posix.cc;drc=5539ecff898c79b0771340051d62bf81649e448d;bpv=1;bpt=1;l=74?q=EncryptString16&ss=chromium%2Fchromium%2Fsrc

  // This currently "obfuscates" by encrypting with hard-coded password.
  // We need to improve this password situation by moving a secure password
  // into a system-level key store.
  // http://crbug.com/25404 and http://crbug.com/49115

https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/os_crypt_posix.cc;drc=5539ecff898c79b0771340051d62bf81649e448d;bpv=1;bpt=1;l=39?q=EncryptString16&ss=chromium%2Fchromium%2Fsrc

  // We currently "obfuscate" by encrypting and decrypting with hard-coded
  // password.  We need to improve this password situation by moving a secure
  // password into a system-level key store.
  // http://crbug.com/25404 and http://crbug.com/49115
  std::string password = "peanuts";
  std::string salt(kSalt);

I do not consider this encryption with a hard-coded password valid from the perspective of securing user data; it corresponds to obfuscation.

Once the file would be created, would other apps be able to access it?

only if you know the decryption key

I am talking about the Android sandbox: can other apps open files created by other apps, without any limitation?

[uazo]

chromium however has already included the library javax.crypto

what do you think of this?

This currently "obfuscates" by encrypting with hard-coded password.

you are right, i forget that for android i have to look at posix and not linux code.
really anomalous, but there was no safer method?
basically the passwords should never be saved using the chromium internal manager on a rooted android, correct?

I do not consider this encryption with a hard-coded password valid from the perspective of securing user data

what if it was manageable by the user? provided that that value is then registered in a store that is really valid for security purposes. I wonder where the credit card details are.

I am talking about the Android sandbox: can other apps open files created by other apps, without any limitation?

as far as I understand, in a non-rooted system, if the file is on the internal memory, only if the application allows it through a saf provider.
and also, before A11, if an application was installed on the external card (which is accessible by all applications), but I don't know if there is a possibility to install that way now.

more than the other applications, the problem is the browser itself, as he obviously has access to those files. an example is the page chrome://local-state/ if for some reason was readable by the sites.
when i've done the crashui i saw that access is governed by IsAccessAllowedAndroid, if there was a way to cheat that function you would have access to all chromium files.

[uazo]

I wonder where the credit card details are.

Seems it works the same way for credit cards: encryptor BindCreditCardToStatement

[csagan5]

really anomalous, but there was no safer method?

Asking the user to enter a master password...to encrypt all the other passwords, would be safer. And it would still need key derivation.

basically the passwords should never be saved using the chromium internal manager on a rooted android, correct?

There is no right answer to this. If your phone is rooted it does not mean that all apps can do anything they want. Most SU managers still require you to give permissions before root is granted to apps; some other security features are disabled when you root, but not all and might not be applicable for this specific attack scenario.

I do not consider this encryption with a hard-coded password valid from the perspective of securing user data

what if it was manageable by the user? provided that that value is then registered in a store that is really valid for security purposes. I wonder where the credit card details are.

chromium however has already included the library javax.crypto

what do you think of this?

This export feature can work without any form of encryption; it is up to the user to figure that out, meanwhile we can further think about the use-case.

I am talking about the Android sandbox: can other apps open files created by other apps, without any limitation?

as far as I understand, in a non-rooted system, if the file is on the internal memory, only if the application allows it through a saf provider. and also, before A11, if an application was installed on the external card (which is accessible by all applications), but I don't know if there is a possibility to install that way now.

more than the other applications, the problem is the browser itself, as he obviously has access to those files. an example is the page chrome://local-state/ if for some reason was readable by the sites. when i've done the crashui i saw that access is governed by IsAccessAllowedAndroid, if there was a way to cheat that function you would have access to all chromium files.

There are many more barriers to break before sites can access a local file, it is not just governed by IsAccessAllowedAndroid.