Since the ArchiveJSONBlock uses a $ref to reference the metadata in the
BackupManifest schema, we have to change the JSON validation mechanism
we're using to one that supports $ref's.
Differential Revision: https://phabricator.services.mozilla.com/D212860
Factoring this out, as computing these keys is something that we need to do both
when generating the ArchiveEncryptionState, as well as when performing a
decryption.
This also renames "authKey" and "encKey" in ArchiveEncryptionState to use
"backupAuthKey" and "backupEncKey", as these are more in-line with what the
encryption design document uses (and because there are "authKeys" and "encKeys"
that will be used by the encryption mechanism that are distinct from the
backupAuthKey and backupEncKey).
Differential Revision: https://phabricator.services.mozilla.com/D212858
This patch adds a new dialog for disabling a backup's password protection.
Steps to test this feature:
1. First ensure that the following prefs are enabled: browser.backup.enabled and browser.backup.preferences.ui.enabled
2. Then ensure that the existing backup for the current profile has encryption enabled (should have enc-state.json)
3. Else, access the debug page (chrome://browser/content/backup/debug.html) to enable encryption
4. Once encryption is enabled, the sensitive data checkbox should be checked in about:settings / about:preferences
5. Clicking the checked checkbox should now show the new dialog for removing password protection
6. If the dialog is confirmed, the checkbox should be unchecked in both the settings/preferences page and the debug page
Other notes:
- If the checkbox is *not* checked, nothing will happen. This is because the dialog for enabling password protection is not yet implemented
- Added tests and Storybook entries as well
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=9NNUojWMeOLwe3rD-0
Differential Revision: https://phabricator.services.mozilla.com/D213171
- Adds button in the preferences backup settings to restore from a backup file.
- Adds a dialog component `restore-from-backup` which will open a filepicker to select a HTML backup file to restore from, show the backup's date and prompt to input a password if needed.
- Adds a stub `getBackupInfo` event to eventually return metadata and config JSON from `sampleArchive` in Bug 1901132.
Does not yet implement:
- Expanding the input to fit multiline files names.
- Restoring the selected backup file.
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-8701&t=zvoykS3OusX9YVCv-4
Differential Revision: https://phabricator.services.mozilla.com/D211248
Patch by kpatenio <kpatenio@mozilla.com>.
Makes several updates to turn-on-scheduled-backups dialog:
- Selecting the encryption option will disable the Confirm button until matching passwords are entered
- Confirming turn-on options with encryption enabled will call BackupService.enableEncryption
- Does not turn on scheduled backups if there is any issue with enabling encryption.
Differential Revision: https://phabricator.services.mozilla.com/D211945
Patch by kpatenio <kpatenio@mozilla.com>.
1. Allows for selecting a custom path or the default (Documents) path for saving backups. The selection is passed from the "turn-on-scheduled-backups" dialog to "BackupService".
2. After pressing the "Choose" button in the dialog, a filepicker will appear so that a folder can be selected.
3. Once the dialog is confirmed, the absolute path is saved to a pref called "browser.backup.location" and saved in the service state.
Other changes:
- Added the Documents folder as the default save location
- Added an onUpdate function for "browser.backup.location" that passes the updated BackupService state to registered widgets (backup settings section, dialogs)
- Added Storybook entries and tests for the newly updated input and filepicker
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=tILUMKfg8c6Ed1Ul-0 (turn on backup dialog)
Differential Revision: https://phabricator.services.mozilla.com/D210850
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
Makes several updates to turn-on-scheduled-backups dialog:
- Selecting the encryption option will disable the Confirm button until matching passwords are entered
- Confirming turn-on options with encryption enabled will call BackupService.enableEncryption
- Does not turn on scheduled backups if there is any issue with enabling encryption.
Differential Revision: https://phabricator.services.mozilla.com/D211945
1. Allows for selecting a custom path or the default (Documents) path for saving backups. The selection is passed from the "turn-on-scheduled-backups" dialog to "BackupService".
2. After pressing the "Choose" button in the dialog, a filepicker will appear so that a folder can be selected.
3. Once the dialog is confirmed, the absolute path is saved to a pref called "browser.backup.location" and saved in the service state.
Other changes:
- Added the Documents folder as the default save location
- Added an onUpdate function for "browser.backup.location" that passes the updated BackupService state to registered widgets (backup settings section, dialogs)
- Added Storybook entries and tests for the newly updated input and filepicker
Figma: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4568&t=tILUMKfg8c6Ed1Ul-0 (turn on backup dialog)
Differential Revision: https://phabricator.services.mozilla.com/D210850
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
This class will be used to generate the keys and ephemera necessary to
encrypt backups. The actual encryption will occur in a later patch.
The state can be serialized and deserialized to disk.
Differential Revision: https://phabricator.services.mozilla.com/D210718
This class will be used to generate the keys and ephemera necessary to
encrypt backups. The actual encryption will occur in a later patch.
The state can be serialized and deserialized to disk.
Differential Revision: https://phabricator.services.mozilla.com/D210718
Move style persistence from XULstore to SessionStore.
Follow up bug to fix persistence of sidebar when only a new tab is open and window is closed, and its
accompanying test `browser_sidebar_persist.js`: Bug 1898613
Depends on D207048
Differential Revision: https://phabricator.services.mozilla.com/D207787
backup-settings changes:
- adds a new button in the Backup section of about:preferences / about:settings
- shows the turn on dialog after pressing the button
Turn on dialog behaviour (implemented):
- pressing the cancel will close the dialog
- pressing the confirm button will set the pref browser.backup.scheduled.enabled=true and close the dialog
- pressing the passwords checkbox will show more options
Turn on dialog behaviour (not implemented):
- requiring a password for the backup (see Bug 1895981)
- modifying the save location and showing a file picker (see Bug 1895943)
Other changes:
- tests for backup-settings and the turn on dialog
- Storybook template for the turn on dialog
Lo-fi Figma designs: https://www.figma.com/design/vNbX4c0ws0L1qr0mxpKvsW/Fx-Backup?node-id=147-4558&t=PYLY0QMN1n8GR9vW-0
Differential Revision: https://phabricator.services.mozilla.com/D209769
This is an intermediary stage before the compressed archive gets (optionally)
encrypted and written into the container file. This is why there's not a whole
lot of testing for the compressed file - those tests will get added once it
completes its journey into the container file so that we can test both
extraction and decompression at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D210311
This is an intermediary stage before the compressed archive gets (optionally)
encrypted and written into the container file. This is why there's not a whole
lot of testing for the compressed file - those tests will get added once it
completes its journey into the container file so that we can test both
extraction and decompression at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D210311
Data science wants us to copy the client IDs from whichever profile initiated recovery.
For legacy telemetry, the client ID is stored in a datareporting/state.json file.
This patch ensures that the client ID exists in the state.json file in the profile
that initiated recovery before then copying it over into the destination profile
for recovery.
This patch also updates the Marionette test to use a separate user profile to
initiate recovery from to ensure we get a unique client ID for it, compared to
the profile that the backup was created for.
Differential Revision: https://phabricator.services.mozilla.com/D209555
