Most Firefox hardening setups stop at a static user.js. That is useful, but I wanted something stricter and easier to audit over time, so I built hifox. https://github.com/q1sh101/hifox hifox treats the repo as the source of truth and Firefox as the deployed target. Instead of relying mainly on editable profile prefs, it generates autoconfig.cfg, uses lockPref() for the main hardening layer, keeps policy-only behavior in policies.json, and then verifies that the live browser still matches what the repo says it should be. It also supports isolated Firefox webapps. That part was important to me because I did not want the answer to be "just weaken the main profile until everything works." With hifox, the main profile can stay maximally hardened, while separate profiles can selectively unlock only what they actually need. Another goal was update visibility. On startup, hifox generates a full pref dump. If a Firefox update adds or changes prefs, that diff can be copied back into the repo so I can review what changed before deciding what to lock down or allow. This is not a claim that Firefox becomes secure in any absolute sense, and it is not protection against browser, kernel, or OS-level exploits. The goal is narrower: make Firefox hardening more deterministic, more auditable, and harder to let drift silently over time. Repo: https://github.com/q1sh101/hifox I would especially value feedback on: Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - hifox deploy pushes the generated hardening into Firefox- hifox verify checks for drift in deployed files and important prefs- if hardening breaks or drifts, Firefox can be stopped and a notification can be raised - a Discord profile can re-enable mic, camera, and WebRTC- a Spotify profile can re-enable Widevine and media keys- those changes do not have to weaken the main browser profile - supports Flatpak Firefox and standard Firefox- built with Bash, Firefox autoconfig, policies.json, and systemd --user- optional best-effort immutability for deployed files via chattr +i - whether the repo -> deploy -> verify model seems useful or too brittle- obvious weak points in the threat model- whether isolated-profile webapp hardening feels practical or overengineered