Firefox to Introduce Additional Protections Against User Fingerprinting

Thorin Oakenpants, the creator of the arkenfox project—which offers a set of add-ons and configuration tweaks for Firefox to boost user privacy and security—has shared updates on the development of new anti-fingerprinting tools in Firefox.

Fingerprinting refers to the passive creation of unique browser identifiers based on indirect characteristics such as screen resolution, supported MIME types, specific HTTP/2 and HTTPS header parameters, analysis of installed plugins and fonts, availability of certain Web APIs, browsing history analysis, graphics card-specific rendering features via WebGL and Canvas, CSS manipulations, mouse and keyboard behavior, and storage of identifiers in areas not meant for persistent data (so-called “supercookies,” like the Favicon cache or form autofill database).

Two Built-In Anti-Fingerprinting Systems

Firefox plans to support two built-in anti-fingerprinting implementations (in addition to external add-ons like CanvasBlocker):

• RFP (Resist Fingerprinting): This is the anti-fingerprinting technology ported from Tor Browser, long available in Firefox via the privacy.resistFingerprinting setting in about:config.
• FFP (Future Fingerprinting Protection): Also known in the source code and Bugzilla as the legacy name RFPLite, this is a new, “lightweight” implementation designed to address usability issues with RFP that have been reported in bugzilla.mozilla.org. FFP can be enabled via the privacy.fingerprintingProtection setting in about:config.

Both systems can be enabled at the same time, in which case the strictest protection will apply.

Strengths and Weaknesses of RFP

The main advantage—and drawback—of the current RFP system is that it is active in all windows and tabs (except for add-ons): protection is either on or off globally, with no selective activation. On one hand, this prevents users from disabling protection for dominant sites that may issue ultimatums or force users to switch to Chrome. On the other hand, less influential sites cannot abuse this, as users are more likely to simply switch to another site rather than disable protection for them.

However, the presence of major sites that refuse to work with anti-fingerprinting enabled prevents Firefox from enabling this protection by default—users might simply switch to Chromium-based browsers, whose privacy protections are generally weaker. Another benefit of RFP is that having a single toggle simplifies integration of complex functionality across browser subsystems, reducing the number of system states to consider.

Advantages and Drawbacks of FFP

The new FFP system’s main advantage is its flexibility: it offers over 60 configurable protection aspects, which can be managed via the privacy.fingerprintingProtection.overrides parameter. This includes the ability to disable protection for specific services or enable it by default when site breakage is minimal.

However, FFP’s strengths come with trade-offs:

• Complexity: The system is more complex to implement and debug. As a result, with equal resources, FFP may lag behind RFP in functionality and stability, and both systems would be less robust than if all resources were focused on a single solution.
• Configurability as a Fingerprint: Since the protection can be finely tuned and it’s impossible to hide specific settings in practice, the combination of enabled protections itself becomes a fingerprint. Privacy-conscious users may coordinate their settings, but the possibility of uncoordinated configurations means some users will end up uniquely identifiable.
• Service Ultimatums: Complying with one service’s ultimatum may expose user data to all services that exchange data server-side. This is not a theoretical risk; it underpins the business models of some companies and is confirmed by the source code of certain services. The necessity and value of an additional anti-fingerprinting system thus remain debatable.
• Default Activation Risks: Enabling the system by default would increase the share of protected users, reducing data brokerage revenues and incentivizing service owners to discriminate against users with protection enabled, pressuring them to disable it for their service.
• Simulation and Detection: Safely simulating vulnerable systems is a complex task, though potentially solvable with generative models and software component reuse. Browser developers do not prioritize undetectability, so they are likely to lose this “arms race,” leaving users with no choice but to comply with service ultimatums. Even if browser developers win technologically, site owners can still block unwanted browsers using Web Environment Integrity.

Conclusion

Firefox’s upcoming anti-fingerprinting features aim to provide users with more robust and flexible privacy protections. However, the ongoing battle between browser developers and service providers means that the effectiveness and adoption of these protections will depend on both technical advancements and the broader web ecosystem’s response.