A777ance · Field Guide

Conforming Firefox to the house rules

The endpoint half of the localDNS stack. Unbound, Pi-hole and WireGuard govern what leaves the network; this governs what the browser gives away before a packet is ever sent. Follow it on any machine to bring a Firefox profile to the same posture the t630 and the XPS-13 run.

Why this posture is strict in some places and relaxed in others

Read the two layers together or none of it makes sense. Cookies, form data and sessions survive shutdown here — only cache and browsing history are cleared. Most hardening guides would call that a failure. It isn't. It is a dividend of network-layer security.

Destroying all browser state on every exit is what you do when you cannot trust the network the endpoint sits on: the browser is the last line of defence, so it has to behave like one. That is not this network. Unbound resolves recursively with DNSSEC, Pi-hole filters at the DNS layer, UFW is default-deny, and WireGuard carries everything off-box. The perimeter is real and it is holding — so the endpoint does not have to compensate for a threat the network already absorbed.

So the strictness goes where the network layer genuinely cannot reach: fingerprinting, WebRTC address disclosure, telemetry, tracker classification. It does not go into ritual session destruction, which here would buy nothing but friction.

A harder posture is not automatically a better one. It is only better where it closes a gap something else isn't already closing. Copy these prefs onto a laptop on hostile Wi-Fi with no tunnel and no local resolver, and you should tighten the shutdown behaviour — because there, the browser is the last line.

Set your paths

Every command on this page rewrites itself to match. Firefox stores profiles under a random ID, so fill in yours once and the rest follows.

5

Pin DNS to your own resolver

Optional, and the one step that only makes sense on a network running its own recursive resolver.

Firefox can enable DNS-over-HTTPS on its own and send every lookup to Cloudflare. On a normal laptop that is a privacy win. On this network it is a bypass: it routes around Unbound, around Pi-hole's blocklists, and around the split-resolution policy that decides which domains are allowed off-box in the first place.

The captured profile leaves network.trr.mode unset, so DoH sits at whatever Firefox's default happens to be. Making it explicit is the point.

  1. Open about:config and accept the warning.
  2. Search for network.trr.mode, set it to 5 — “off, by explicit user choice.” Firefox will not re-enable DoH behind you.
  3. Confirm your queries are landing on your own resolver. From the box running Pi-hole, watch the query log while you load a page in the browser.
Prefer this in the file rather than the UI? The line already exists in user.js, commented out — uncomment it and skip the clicking.
4

Expect the breakage — and what to do about it

All of this is intended. None of it is a failed install.

What you'll noticeCauseIf you need it back
Theme is forced light; window reports an odd size privacy.resistFingerprinting standardises both Accept it — these are two of the highest-entropy signals you have
Video calls in Firefox never connect media.peerconnection.enabled=false disables WebRTC Use a separate un-hardened profile for calls, not a global re-enable
Maps, 3D and some canvas-heavy sites fail webgl.disabled=true Per-site is not possible; flip the pref temporarily or use another profile
A login or checkout flow breaks Both Mozilla tracking allow-lists are switched off Add a per-site exception via the shield icon in the address bar
A page loads blank over plain HTTP HTTPS-Only mode is interstitialling it “Continue to HTTP site” for that one site only
Use exceptions, not rollbacks. The shield icon disables protection for one site. Turning a pref back off globally to fix one checkout page undoes the posture everywhere — which is how hardening quietly decays into a default install.
3

Verify the posture took

Check the effect, not the copy. A file in the right place proves nothing until Firefox has read it.

  1. Open about:support and find Important Modified Preferences. Your prefs should be listed there. If the section looks stock, Firefox never read the file — check the filename and that it sits beside prefs.js, not in the parent directory.
  2. Spot-check two in about:config: privacy.resistFingerprinting and webgl.disabled, both true.
  3. Confirm the WebRTC leak is actually closed — the check that matters most if you are behind the tunnel. Visit browserleaks.com/webrtc; it should disclose no local and no public address.
  4. Confirm the GPC signal is going out at global-privacy-control.glitch.me.
2

Install the user.js

Why this file and not the one Firefox already writes.

Firefox rewrites prefs.js on every clean shutdown. A posture recorded there is one crash away from being lost and cannot be version-controlled meaningfully. user.js sits in the same directory, is re-applied at every startup, and is the only file in the profile worth tracking in git.

  1. Quit Firefox completely. It reads user.js only at startup, and will overwrite prefs.js on the way out.
  2. Copy the house user.js into the profile directory:
  3. Start Firefox again.
Already have a user.js? Concatenate rather than overwrite, then remove duplicate user_pref lines — on a collision the last line in the file wins.
1

Locate your profile

Start here on a machine you have not hardened before.

  1. Find the profile directory. The folder name is a random ID, so let the shell find it:
  2. If nothing comes back, Firefox is installed by a different method than the one selected above — switch it in Set your paths and re-run. On any platform, about:profiles inside Firefox shows the true path under Root Directory.
  3. Put the folder name — the part before /prefs.js — into the Profile directory field above. Every command on this page updates.
Ubuntu ships Firefox as a snap, so the profile is not at ~/.mozilla/firefox/ where most guides send you. That path existing but being empty is the usual first wrong turn.