RFP vs FPP on Arkenfox.js, with Dark Reader extension

Questions
1

I’m trying to understand the current default / recommended best practice for FPP (fingerPrintingProtection) vs RFP (resistFingerPrinting) on Firefox + Arkenfox.

Confusion about current arkenfox defaults

According to this page of the arkenfox wiki, which was last updated in 2023, “the best tool for [fooling naive fingerprinting scripts] is RFP” and Arkenfox enables it by default, but “in Firefox 120+ you can fallback to using FPP (fingerprintingProtection),”

3.3 Overrides [To RFP or Not] · arkenfox/user.js Wiki · GitHub

This seems to be outdated, as it seems to directly contradict this announcement from August 2024, which I found only because it was linked in a comment on a Privacy Guides forum post:

ATTN: arkenfox v128 is now RFP-inactive and FPP is default · Issue #1804 · arkenfox/user.js

If I understand this announcement correctly, it says that starting with Firefox 128 (current Firefox version is 147), the default Arkenfox strategy will be to use FPP rather than RFP.

What’s frankly tripping me up the most here is that the announcement contains a todo checklist which includes “change user.js” and “update wiki”, both of which are checked off, but the wiki seems manifestly to not be updated, which makes me unsure if the rest of the checked off items have happened or not, and also makes me worry that I’m reading an entirely outdated version of the Arkenfox wiki and there’s a secret more current version somewhere else?

So I welcome any clarification on the state of Arkenfox documentation, broadly speaking. But my more actionable specific question about my own use-case is:

Should I use FPP or RFP given that I have to use Dark Reader

I have to use the Dark Reader browser extension to enforce dark mode on websites that don’t have their own dark mode. I am photosensitive and can’t safely use the internet without this.

I understand that by using an extension that changes the appearance of my browser, I am rendering certain kinds of anti-fingerprinting useless. This is a fact outside my control, so the question is what is the best configuration to fool as many naive fingerprinting scripts as possible given this immovable variable.

(If someone has a suggestion for a different method of consistently enforcing dark mode that is less injurious to privacy, I would love to hear it. But please do not respond to this post just to tell me that I shouldn’t enforce dark mode; that is not a useful or meaningful suggestion.)

So, I’m trying to figure out whether RFP or FPP’s randomization strategy is least undermined by enforcing dark mode, and I’m running into a wall because what seems like the clearest most accessible description I’ve found so far of what RFP is and how it works also seems to be 2.5 years out of date and directly contradicted by a later post from the same source.

My understanding of RFP vs FPP - is this correct?

Broadly, this is my current understanding of the difference between RFP and FPP, and I welcome any corrections or clarifications:

  • RFP attempts to protect against fingerprinting by creating a crowd of identical users, by standardizing various metrics so that a fingerprinting script can tell you are a member of that crowd, but not which member of the crowd you are.

    • When used correctly in Tor Browser or Mullvad Browser, RFP is capable of fooling advanced fingerprinting scripts.

    • If the user makes any changes to how the browser looks (such as enforcing dark mode), RFP becomes useless.

  • FPP attempts to protect against fingerprinting by randomizing various metrics so that, while a fingerprinting script can certainly tell you’re unique, it can’t actually tell who you are.

    • FPP can fool some naive scripts but cannot fool advanced fingerprinting scripts.

    • If the user makes changes to how the browser looks, this reduces the efficacy of FPP but does not necessarily eliminate it.

Concluding questions

If that summary is accurate, for my use case FPP is the better choice. So my questions are

  1. Is my understanding of the difference between the two accurate, and am I correct in concluding that FPP is the better option for my use case?

  2. What is the current actual Arkenfox default?

  3. If, as it turns out, the current Arkenfox default is RFP and what I need is FPP, how can I go about setting overrides in Arkenfox to set FPP instead of RFP, when I don’t have any experience using a user.js file and have no strategy beyond following the Arkenfox wiki instructions to the letter and the Arkenfox wiki seems to be out of date?

2

I’ll start at the end. I think FPP sounds right for you, & it’s Arkenfox’s current default.

For some other clarifications, Section 3.3 on the wiki never claims Arkenfox uses RFP by default, and it is not lying about it being the strongest option. While stronger than FPP, the difference without a crowd is not dramatic, and thus if you don’t want to use a browser like Mullvad/Tor browser, FPP is good enough. Both fool naive scripts (RFP covers more metrics (along with covering canvas better than FPP does, according to the second post you linked) and protects against side channel attacks, at the cost of being more prone to website breakage than FPP is), which is about all you can ask for without a crowd.

While most wiki pages have not been updated in years, I can assure you this is not an act of neglect, it merely means there is nothing noteworthy to update. You are reading the correct wiki, and can follow it’s advice without worry.

3

FPP enables a customizable subset of RFP protections. These granular protections are called RFP targets in Firefox source code. Here’s a list of default FPP targets and all possible targets. FPP with privacy.fingerprintingProtection.overrides set to +AllTargets should offer same protections as RFP.

Default FPP targets protect little compared to RFP. Default FPP canvas randomization is broken in recent Firefox versions which makes it a failure for fingerprinting protection.

Main RFP downsides are timezone spoofing to Iceland and peculiar screen resolution spoofing (e.g. 1400x600). Inconsistencies like this may trigger anti-fraud flags on financial websites.

Create Firefox profiles with different settings and test them with TorZillaPrint to see the difference between RFP, FPP and default firefox settings. Then try tweaking privacy.fingerprintingProtection.overrides to customize FPP protections you are comfortable with.

Your physical fingerprint also doesn’t directly tell who you are until it is matched with another fingerprint sample in some database.

Default FPP is lacking adequate fingerprinting protections. RFP or customized FPP is the better approach. Repeat your testing after Firefox updates because things tend to change or break.

FPP in its default state.

Start with this to try protections closer to TB/MB.

user_pref("privacy.resistFingerprinting", true);
user_pref("privacy.resistFingerprinting.letterboxing", true);
user_pref("webgl.disabled", true);
user_pref("privacy.spoof_english", 2);

Try this instead to tinker with individual FPP targets.

user_pref("privacy.fingerprintingProtection.overrides", "...");