1909829 - Backup with sensitive information doesn't work

Status: RESOLVED WORKSFORME

(Firefox :: Profile Backup, defect, P3)

Description

[Ciprian Georgiu, Desktop QA]

Found in

• latest Nightly 130.0a1

Affected versions

• latest Nightly 130.0a1

Tested platforms

• Affected platforms: Windows 11, Ubuntu 22.04 and macOS 14

Preconditions

• browser.backup.preferences.ui.enabled = true
• browser.backup.scheduled.idle-threshold-seconds = 5
• browser.backup.scheduled.enabled = true
• make sure the profile contains senstivie information, e.g. passwords, cookies, payment methods.

Steps to reproduce

1. Go to the backup section from "about:preferences" page.
2. Click on the "Back up your sensitive data" checbox, provide a pasword, then hit the "Save" button.
3. Leave the browser in idle mode, around 5 seconds.
4. Click on the "Restore..." button from "Restore you data" section.
5. Choose the backup file, then restore it.

Expected result

• Backup file contains senstive information, e.g. passwords, cookies, payment methods.

Actual result

• Backup file does not contain senstive information, e.g. passwords, cookies, payment methods.

Regression range

• Not a regression.

Additional notes
Other issues tirggered by the fact that backing with sensitive information functionality does not work:

1. "Not encrypted" string appear in this backup page even though it was backed up with encryption.
2. "Back up with sensitive information data" checkbox remains unchecked after providing a password.
3. Backup section is not turned on after providing the password. (STR: browser.backup.scheduled.enabled set to false - Click on the "Manage backup" - Check the "Back your sensitive data" checbox -> Enter a passowrd -> Turn on backup).

Comment 1

[Ciprian Georgiu, Desktop QA]

(In reply to Ciprian Georgiu, Desktop QA from comment #0)

3. Backup section is not turned on after providing the password. (STR: browser.backup.scheduled.enabled set to false - Click on the "Manage backup" - Check the "Back you sensitive data" checbox -> Enter a passowrd -> Turn on backup).

We've observed that this issue occurs only with short passwords. When a user sets a long password, the backup section and the option to "Back up your sensitive data" are both activated.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Setting to P3 for now - but once this is assigned, let's set this to a P1.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Ciprian Georgiu, Desktop QA from comment #1)

(In reply to Ciprian Georgiu, Desktop QA from comment #0)

3. Backup section is not turned on after providing the password. (STR: browser.backup.scheduled.enabled set to false - Click on the "Manage backup" - Check the "Back you sensitive data" checbox -> Enter a passowrd -> Turn on backup).

We've observed that this issue occurs only with short passwords. When a user sets a long password, the backup section and the option to "Back up your sensitive data" are both activated.

Hi Ciprian,

Can you give us an example of a short password vs a long password? Like, what testing password was used when this failed to work?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Actually, I just reproduced this on the build from July 25th. The reason I asked the above question was because I couldn't reproduce the issue in the current Nightly, because I believe we've fixed it elsewhere.

Specifically, I believe bug 1896772 fixed this, which was closed just the day after this bug was filed.

Can you confirm that this bug is no longer reproducible?

Comment 5

[Ciprian Georgiu, Desktop QA]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)

Actually, I just reproduced this on the build from July 25th. The reason I asked the above question was because I couldn't reproduce the issue in the current Nightly, because I believe we've fixed it elsewhere.

Specifically, I believe bug 1896772 fixed this, which was closed just the day after this bug was filed.

Can you confirm that this bug is no longer reproducible?

I am still able to reproduce this bug, although not consistently. I managed to restore my passwords, cookies, form autofill, and credit cards a few times using latest Nightly 130.a01. However, in the last hour of trying to back up and restore this sensitive information, I haven't been successful.

I’m importing all my data from Chrome first, then creating a backup in Firefox (clean profile). I’ve also tried using chrome://browser/content/backup/debug.html to trigger the backup, but the sensitive information still hasn’t been restored.

I’m trying to understand why it worked in those previous scenarios, and will investigate further. If you have any input, please let me know.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Thanks, Ciprian.

Would you be able to attach to this bug two backup HTML files:

1. One that fails to recover the passwords, cookies, form autofill and payment methods
2. One that succeeds in the above

Also, if you enable logging with browser.backup.log and restart the browser, the Browser Console log produced may also be of interest when the backup gets created.

Comment 7

[Ciprian Georgiu, Desktop QA]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #6)

Thanks, Ciprian.

Would you be able to attach to this bug two backup HTML files:

1. One that fails to recover the passwords, cookies, form autofill and payment methods

I've investigated further and discovered that the failures occur every time the data is imported from Chrome into a clean Firefox profile. I've uploaded the HTML file for the failed backup here.

2. One that succeeds in the above

It seems that the sensitive information is correctly recovered if I create save some passwords, credit cards and autofill forms in a clean Firefox profile before performing the backup. You can find the HTML file for the successful backup here.

Also, if you enable logging with browser.backup.log and restart the browser, the Browser Console log produced may also be of interest when the backup gets created.

... BackupService: Resolving configured archive destination folder: /Users/ciprian.georgiu/Documents/Restore Firefox BackupService.sys.mjs:968:21 BackupService: Wrote backup to staging directory at /Users/ciprian.georgiu/Library/Application Support/Firefox/Profiles/pwphfxpj.veew/backups/snapshots/2024-08-07T07-29-37Z BackupService.sys.mjs:1220:27 BackupService: Compressing staging folder to /Users/ciprian.georgiu/Library/Application Support/Firefox/Profiles/pwphfxpj.veew/backups/snapshots/2024-08-07T07-29-37Z.zip BackupService.sys.mjs:1447:21 BackupService: Done writing archive file BackupService.sys.mjs:1456:27 BackupService: Exporting single-file archive to /Users/ciprian.georgiu/Library/Application Support/Firefox/Profiles/pwphfxpj.veew/backups/snapshots/archive.html BackupService.sys.mjs:1253:27 BackupService: Moving single-file archive to /Users/ciprian.georgiu/Documents/Restore Firefox/FirefoxBackup_veew_20240807-1029.html BackupService.sys.mjs:1358:21

I've deleted some of the data from the first part of the logs, as it was mostly related to addons. Let me know if this helps, or if you need the full log instead. The password for both HTML files is "cipriantest".

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Hi Ciprian,

I have some follow-up questions here, because I feel like there are a number of things being reported here and I want to get this narrowed down to something specific.

1. Are you still noticing the "Not encrypted" string in the backup file sometimes, despite encryption being enabled? (From Additional Notes in Comment 0)
2. Are you still noticing that the "Back up your sensitive data" is still unchecked despite enabling encryption? (From Additional Notes in Comment 0)
3. Are you still noticing that enabling scheduled backups with sensitive data still results in the backup not being turned on? (From Additional Notes in Comment 0)
4. How quickly are you performing the backup after importing from Chrome? I've examined the "not working" HTML file, and it contains some of your sensitive data, but doesn't contain the files for logins or payment methods. This makes me think they weren't yet flushed to disk when backup occurred. If you increase browser.backup.scheduled.idle-threshold-seconds to 15 seconds instead, does the issue go away?

Comment 9

[Ciprian Georgiu, Desktop QA]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #8)

Hi Ciprian,

I have some follow-up questions here, because I feel like there are a number of things being reported here and I want to get this narrowed down to something specific.

1. Are you still noticing the "Not encrypted" string in the backup file sometimes, despite encryption being enabled? (From Additional Notes in Comment 0)

No, it doesn't happen anymore. All the backup HTML files contain the "Encrypted" string, even those where the sensitive information was not restored correctly.

2. Are you still noticing that the "Back up your sensitive data" is still unchecked despite enabling encryption? (From Additional Notes in Comment 0)

I could no longer reproduce this issue. Maybe it was fixed on bug 1896772.

3. Are you still noticing that enabling scheduled backups with sensitive data still results in the backup not being turned on? (From Additional Notes in Comment 0)

I'm encountering an error when trying to follow again the steps from additional notes (no. 3) in the latest Nightly build. You can see in this screenhost. Should we file a separate bug for this?

4. How quickly are you performing the backup after importing from Chrome? I've examined the "not working" HTML file, and it contains some of your sensitive data, but doesn't contain the files for logins or payment methods. This makes me think they weren't yet flushed to disk when backup occurred. If you increase browser.backup.scheduled.idle-threshold-seconds to 15 seconds instead, does the issue go away?

I've always set browser.backup.scheduled.idle-threshold-seconds to 5, so the backups were created fairly quickly. Sometimes, I've left the laptop in idle for approximately two hours, and then performing another backup.

Unfortunately, my passwords still aren't being restored from the backup, even after changing browser.backup.scheduled.idle-threshold-seconds to 15. Let me know if there's anything else I can help with. I'll be returning from PTO on Tuesday and can follow up then.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

(In reply to Ciprian Georgiu, Desktop QA from comment #9)

Unfortunately, my passwords still aren't being restored from the backup, even after changing browser.backup.scheduled.idle-threshold-seconds to 15. Let me know if there's anything else I can help with. I'll be returning from PTO on Tuesday and can follow up then.

If you browse to your profile directory, does a logins.json or logins-backup.json file exist in it?

Comment 11

[Ciprian Georgiu, Desktop QA]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #10)

(In reply to Ciprian Georgiu, Desktop QA from comment #9)

Unfortunately, my passwords still aren't being restored from the backup, even after changing browser.backup.scheduled.idle-threshold-seconds to 15. Let me know if there's anything else I can help with. I'll be returning from PTO on Tuesday and can follow up then.

If you browse to your profile directory, does a logins.json or logins-backup.json file exist in it?

No, it doesn't. I cannot find either of the files in the profile directory.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mconley, could you have a look please?

For more information, please visit BugBot documentation.

Comment 13

[Chris DuPuis]

Bogdan, do you have a reproducible set of steps to hit this error?

Comment 14

[Mike Conley (:mconley) (:⚙️)]

I suspect this was actually caused by bug 1985641. In that bug, the CredentialsAndSecurityBackupResource class was failing out in the recovery method because it assumed that autofill-profiles.json would exist in the recovered backup, which would only be true if an address or payment method had ever been saved.

If that's true, then this bug might actually be a dupe of 1985641, and is fixed. It'd certainly be good to get a sense of whether or not this is still reproducible.

Comment 15

[Chris DuPuis]

Let's try to repro this and see if it's a current issue.

Comment 16

[Bogdan Maris, Desktop Test Engineering [OUT until 12 Jan]]

I can't reproduce this with the latest Nightly 146.0a1 build, restoring an encrypted backup file will correctly restore passwords (short and long) and payment methods, if no encryption is used those are not restored. I also imported passwords from Vivaldi directly, from file via .csv (both vivaldi and Chrome don't use html anymore), using the file from comment 7 which does not work with the restore function now.

In short I can't reproduce but I would leave this open for now until QA has concluded testing on Firefox Backup feature, in case we'll find a way to repro, leaving needinfo on me until that happens.

Comment 17

[Nick Rishel [:nrishel]]

:bogdan since we can no longer reproduce (thus far) and are holding onto this bug in case it surfaces again in testing, I'm going to drop this to a P3 to get this out of our priority queue.

If we find we can reproduce again could you bump this back to a P1?

Comment 18

[AmirH [:Amir]]

Removing 145 dot release uplift bug

Comment 19

[Bogdan Maris, Desktop Test Engineering [OUT until 12 Jan]]

I think I'll go ahead and close this bug for now, during our testing in Nightly 146, Beta/Release 145 and 145.0.1 we did not have issues with this. Will reopen if at any point we'll find related to this.