You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firefox releases after the current ESR (version 66) don't permit simple creation or management of generic browser profiles such as .mozilla/firefox/profile.default. This means the ibrowse tag currently only works with Firefox 66 and earlier, since ibrowse depends on this profile remaining viable.
For now, this doesn't present an issue with a default Debian 10 config, which uses Firefox ESR.
Newer Firefox versions perform a kind of (hash based?) locking of a profile to a specific binary installation of the program. When FF detects the absence of such a lock, it dumps the user into a freshly-created empty profile and urges them to sign up for Mozilla's cloud-based profile management. See bugzilla issue.
Since Mozilla appear committed to this new (and ethically questionable) behavior, we may want to find a workaround for Qubes-VM-Hardening that bypasses it. Of initial interest are Firefox configs profiles.ini, installs.ini, compatibility.ini and specific filesystem paths of the 'firefox' executable.
The text was updated successfully, but these errors were encountered:
SecBrowser ™ is a derivative of Tor® Browser, produced independently from the Tor® anonymity software and carries no guarantee from The Tor® Project about quality, suitability or anything else.
Firefox releases after the current ESR (version 66) don't permit simple creation or management of generic browser profiles such as .mozilla/firefox/profile.default. This means the ibrowse tag currently only works with Firefox 66 and earlier, since ibrowse depends on this profile remaining viable.
For now, this doesn't present an issue with a default Debian 10 config, which uses Firefox ESR.
Newer Firefox versions perform a kind of (hash based?) locking of a profile to a specific binary installation of the program. When FF detects the absence of such a lock, it dumps the user into a freshly-created empty profile and urges them to sign up for Mozilla's cloud-based profile management. See bugzilla issue.
Since Mozilla appear committed to this new (and ethically questionable) behavior, we may want to find a workaround for Qubes-VM-Hardening that bypasses it. Of initial interest are Firefox configs profiles.ini, installs.ini, compatibility.ini and specific filesystem paths of the 'firefox' executable.
The text was updated successfully, but these errors were encountered: