This commit would allow overriding prefs
(locked or otherwise) with a user accessible file even
on sandboxed/restricted releases (like AppImage or Flatpak).
This works because the last specific pref value that is parsed
during startup is the one that gets actually applied; this way
an empty / non existing overrides file will not have any effect,
and only prefs changed in this file will be changed, while other
prefs from the `librewolf.cfg` will still be applied.
The difference to a `user.js` is that at this stage / with this
file, even locked prefs can still be modified.
Should we desire to have some prefs _really_ locked down (which we
do not want to be changeable with this override method), we could
just place them after the changes from this MR - so they would be
parsed after those defined in the overrides file and could override
pref changes made there.
Somewhat related to #45, #27; should partially fix#8 and basically
mitigate the recurring issues of users unable to edit some locked
settings when using a more restricted release variant.
Should probably be added to the docs, once merged.
This enables users to enable it manually in their about:config instead of having to edit this file everytime after an update.
Helpful for librewolf-community/browser/linux#173
This fixes issues with webpages that depend on a correct version in the UserAgent string (e.g. connection issues with meet.jit.si) when resistFingerprinting is off
Quoting @ohfp from #10:
> I guess setting [`general.useragent.override`] to the default value of
> `privacy.resistFingerprinting` […] would probably be the most
> reasonable fallback approach
We're setting `MOZ_REQUIRE_SIGNING=0` during build, so it's possible to
set `xpinstall.signatures.required` to `false` in `about:config`, should
it be desired to install unsigned addons, while still keeping signatures
required by default with this change.
This is basically backporting some changes that have been already
implemented with my earlier Arch builds.
Mostly it's about keeping some of the settings most often causing
"issues" unlocked, to make it easier to change them once needed.
Cookie handling, for example, can be handled via
[Cookie AutoDelete](https://addons.mozilla.org/de/firefox/addon/cookie-autodelete/)
more comfortably, allowing exceptions for websites and a more granular
retention / rejection.
Having the option to actually keep a history or autofill forms can also
be desired, when the tradeoff with regards to privacy implications is
understood and accepted, so while keeping those options off by default,
it might be helpful to have them easily modifiable.
`resistFingerprinting` can cause issues (rarely), so it might be desired
to at least temporarily disable it in some cases.
The predefined useragent and other overrides sometimes cause issues with
certain websites, so being able to modify can be required as well.
The webextensions-CSP needs to be slightly modified to allow some addons
(especially μBlock Origin) to function.
Furthermore, options to allow re-enabling installing (and, optionally,
updating) extensions from the official extension store might be a good
thing, albeit somewhat of a tradeoff between privacy and security:
Basically keeping extensions up to date is crucial from a security point
of view, and the official extension store is at least a somewhat trusted
source of extensions. This also indirectly can be a good thing for
privacy, as in keeping relevant addons current with regards to privacy
enhancing techniques.
Of course, extensions can be kept up to date separately as well, but
from my experience this is often not taken care of properly and quite a
lot of extra work.
In a comparable vein, the `xpinstall.signatures.required` option might
be a good thing, but also undesired – so it's just kept unlocked.
