Firefox Strict ETP: What Breaks, What Survives, and How to Test Your Site

The problem: tracking protection that changes site behavior

Firefox's Enhanced Tracking Protection (ETP) strict mode blocks known tracking scripts, fingerprinters, and cryptominers by default using a curated list maintained by Disconnect. When enabled, the browser replaces blocked requests with transparent placeholders, preserving page layout while preventing data leakage to third‑party domains. For developers, this means a site that works in Chrome or Safari may behave differently in Firefox without any code changes on your end.

How strict ETP decides what to block

The Disconnect list categorizes domains by purpose: advertising, analytics, social, content, and so on. Strict mode blocks anything labeled as tracking, fingerprinter, or cryptominer. Requests to those domains are cancelled before they leave the browser, and a placeholder response (typically a 204 No Content or an empty script) is returned so the page doesn't stall on a hanging request. The shield icon in the address bar surfaces a count of blocked items per page.

Worked example: a news site with third‑party ads

Consider a news article that loads an ad script from ads.example.net. With ETP set to Standard, the script executes, sets cookies, and renders an ad slot. Switch to Strict: the request to ads.example.net is blocked, the shield icon shows one blocked tracker, and the ad container remains empty but retains its dimensions. In lab measurements the page's total load time dropped roughly 20% because the ad script's network round‑trip and execution were eliminated. The content itself — text, images, first‑party scripts — loaded unchanged.

Where strict mode breaks legitimate flows

• Login widgets hosted on a separate authentication domain (e.g., auth.provider.com) may be classified as trackers if they set cross‑site cookies.
• Payment iframes from processors that share domains with analytics endpoints can be blocked.
• Embedded third‑party content (maps, video players) that loads additional scripts from flagged domains.

When breakage occurs, users can add the site to the exceptions list via the shield menu, but that defeats the privacy goal for that origin. Developers should instead audit their third‑party dependencies and, where possible, move critical functionality to first‑party domains or use the Storage Access API to request permission for cross‑site cookies.

Testing your site against strict ETP

1. Open Firefox → Preferences → Privacy & Security → Enhanced Tracking Protection → Strict.
2. Navigate to your site. Click the shield icon in the address bar to see a list of blocked resources.
3. Open Developer Tools → Network tab. Reload and note which requests show "blocked" status or return 204.
4. Switch ETP to Standard or Custom (with trackers unchecked) and reload. Compare the network waterfall and console errors.

Automate this in CI by launching Firefox with the -pref flags privacy.trackingprotection.enabled=true and privacy.trackingprotection.pbmode.enabled=true, then running your existing Playwright or Selenium suite. Flag any new console errors or failed assertions as ETP‑related regressions.

Limitation: the list moves under you

The Disconnect list updates periodically. A domain that is unlisted today may be added tomorrow, causing a previously working integration to break without any deployment on your side. Monitor the shield icon on production pages and subscribe to the Disconnect list changelog (published on their GitHub) to anticipate changes.

Actionable closing

Run the manual test steps above on your top‑traffic pages this week. Document every blocked request that belongs to a vendor you rely on for authentication, payments, or core functionality. For each, decide: migrate to first‑party, implement Storage Access API, or accept the exception and track it as technical debt. Re‑run the test after each Disconnect list update to catch regressions early.