hifox: Deterministic Firefox Hardening as an Enforcement Workflow

Giorgi Kishmareia — Thu, 26 Mar 2026 16:00:26 +0000

hifox is a Linux-first Firefox hardening framework that treats a Git repo as the source of truth and the browser as a deployment target. Instead of stopping at a static config, it generates enforced runtime config, verifies drift, surfaces update changes, and isolates webapps into separate profiles with selective unlocks.

https://github.com/q1sh101/hifox

The Problem

You spend time hardening Firefox.

Then the browser updates, a file drifts, or an exception gets added for a real app.

How do you know the browser that is running still matches the hardening you intended?

Most Firefox hardening setups stop at a static user.js.

That is useful, but it leaves a real gap between:

the hardening you meant to have
the browser that is actually running

Files drift. Browser updates add new prefs. Exceptions for real apps slowly pile up. Over time, the setup becomes harder to trust because it is no longer obvious whether the live browser still matches the model in your head.

That is the problem hifox is trying to solve.

What hifox changes

hifox treats Firefox hardening as an enforcement workflow, not just a config dump.

The basic model is:

keep the repo as the source of truth
generate the effective Firefox config from that repo
deploy it into Firefox
verify that the live browser still matches it
watch for drift and react if integrity breaks

In practice, that means hifox does not rely mainly on a static user.js.
It generates autoconfig.cfg, enforces base rules with lockPref(), uses policies.json where Firefox policy support is the right layer, and keeps the deployed browser tied back to the repo.

That distinction matters.

A static config is easy to copy once and forget.
An enforcement workflow is designed to keep the browser in the state you intended.

The runtime side of hifox is built around a simple loop:

deploy pushes the generated hardening into Firefox
verify checks important prefs and deployed files against the repo
watcher and timer layers catch tampering, deletion, or silent drift
if integrity breaks, Firefox can be stopped and a notification can be raised instead of silently continuing

There is also an update-detection angle that mattered a lot to me.

Firefox updates can add or change prefs quietly.
hifox generates a full pref dump on startup, compares that against the repo copy, and surfaces meaningful changes back into version control. That turns "Firefox changed something internally" into a visible git diff that can be reviewed and acted on.

Why isolated webapps matter

Another part I cared about was separating the main browser profile from app-like browser usage.

The default profile can stay maximally locked.
Then app-style profiles can selectively unlock only what they actually need.

For example:

a Discord profile can re-enable mic, camera, and WebRTC
a Spotify profile can re-enable DRM
everything else stays under the same hardening model unless you explicitly relax it

That gives a different shape than normal browser usage.

Instead of one giant profile where tabs, cookies, permissions, and exceptions all accumulate together, hifox uses isolated Firefox profiles as webapps. Each one gets its own state, its own permission surface, and its own override rules while still sharing the same Firefox runtime.

What it is not

The goal is not to claim that Firefox becomes "secure" in any absolute sense.

hifox is not a defense against browser exploits, kernel exploits, or a compromised OS.
It is also not trying to be a universal hardening standard for everyone.

The goal is narrower and more practical:

make Firefox hardening deterministic
reduce silent drift
make changes auditable
keep exceptions explicit
keep the running browser closer to the declared model

Current scope is intentionally narrow:

Linux only
Flatpak Firefox and standard Firefox
Bash, Firefox autoconfig, policies.json, and systemd --user

The core thesis

So the main idea is simple:

Firefox hardening gets much more interesting once you stop treating it as a static file problem and start treating it as a deploy, verify, and integrity problem.

That is what hifox is.

Repo: https://github.com/q1sh101/hifox

Your bundle didn't suddenly get bigger. You just never saw it change.

Giorgi Kishmareia — Wed, 21 Jan 2026 20:43:17 +0000

Most bundle size regressions don’t come from bad code. They come from small, reasonable decisions that add up quietly.

A helper here. One more dependency there. Everything makes sense in isolation.

This kept bothering me, not because I don’t care about size, but because managing it properly always meant extra setup, extra rules, extra friction.

What actually helped wasn’t optimizing harder. It was seeing size changes automatically, at the exact moment code is reviewed.

When size becomes part of the pull request, behavior shifts naturally. No enforcement. No policing. Just visibility and better decisions.

I built this because the problem wouldn’t go away. If it helps you even a little, that’s already a win.

https://github.com/q1sh101/build-size-diff