ATTN: arkenfox v128 is now RFP-inactive and FPP is default

[Thorin-Oakenpants]

in the meantime read #1764 if you want - edit, I meant #1716 but the #1764 user.js info changes is also good :)

• I will summarize why soon (hence locking the issue for now)
• I have also amended the title of do not ask about ETP Custom or RFPTargets #1334 to include RFPTargets, and I will also explain that here

don't hold your breath, not looking forward to regurgitating everything :)

ToDo

• change user.js - 10fddc8 & 0d12cd9
• explain shit below
• update wiki
• make disable RFP overrides obsolete in sticky: override recipes #1080 and mentions on it in the wiki/user.js

[Thorin-Oakenpants]

Read the wiki - nothing has changed in terms of how FPing works

Assuming you mask your IP, I have always said that FPing requires a crowd, and that the best FF could do (at the time) was fool naive scripts, because it has no crowd. I have also always said that protections require built-in browser solutions: extensions leak, add distinctive entropy, and are not up to the task. We are only interested in comprehensive solutions, always assume the worst.

Also, don't listen to fuckwits who have no idea what they are talking about. If you do nothing, you are unique. We can hardly make it worse (it depends on the script, e.g. if you returned your userAgent OS as "ToasterOS" that would be really telling everywhere, but no one is advocating that)

So with that in mind, we had to do something, and RFP was our only option. FF128 is a watershed moment for users (e.g. ESR changes), so I am using v128 to change the default arkenfox strategy. Remember, arkenfox is a template, where less than 10 prefs need consideration to suit your needs.

A few bugs notwithstanding, FF128+ has what is called FPP (finger print protection). It doesn't necessarily have a crowd, not by default, but because it emphasizes no breakage (and can unbreak sites in future), it is more palatable for users, and thus likely to get a large enough crowd in time - it is enabled (in normal windows) when users change to ETP Strict (which has a UI - RFP doesn't). The crowd doesn't matter until it starts to meaningfully cover enough metrics, but it's a start

FPP is very early days. The main benefit for users is that it randomizes canvas, but subtlely and hipefully without breakage. This can allow more costly side channel attacks, but serves it's purpose - fool naive scripts. Over time more protections will get added, and hopefully more Firefox users enable EP Strict.

---

Should you use RFP or FPP?

That's entirely up to you. The default v128 will be FPP. Add overrides if you want RFP.

Personally, I will using RFP because I want to experience it, test it, play with it, and improve it. It also comes with timing precision patches which circumvent a lot of side channel attacks. It's also more robust with canvas (no averaging or leaking 1x1 pixel values)

FYI: my overrides (I am using en-US app language)

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

webgl, like canvas, is the intersection of a lot of entropy (math, gpu, anything fonts, anything css eg colors, etc) along with other entropy such as your graphics card info, parameters and values. As such, since it's barely protected by RFP, it's better to disable it.

[zipfile6209]

I understand that it breaks the purpose of FPP a bit, but are RFP and FPP mutually exclusive, or can they work well together?

[rusty-snake]

user.js/user.js

Line 754 in f906f7f

RFP overrides FPP (4000)

[xlacroixx]

Are we really sure that we will have a FPP crowd large enough in time?

I can guess that many Firefox users don't even bother enabling strict ETP.

If they have a reason to do so, they might just go for Librewolf where RFP is enabled by default, or for Arkenfox, of which the wiki still recommends RFP.

I'm guessing that a FPP-enabled crowd is more effective in fooling naive scripts than RFP, but will we realistically get one in time, now that Arkenfox uses FPP by default?

[Thorin-Oakenpants]

the crowd is not a thing - not enough metrics are covered, by a long shot. The whole point is that you get randomized canvas and that's what your also got with RFP - fool naive scripts - see https://github.com/arkenfox/user.js/wiki/3.3-Overrides-[To-RFP-or-Not]#-summar

The best any browser can confidently do, excluding Tor Browser and Mullvad Browser, is fool naive scripts.

[xlacroixx]

the crowd is not a thing - not enough metrics are covered, by a long shot. The whole point is that you get randomized canvas and that's what your also got with RFP - fool naive scripts

I see, I've misread the summary.

So I'm guessing that using RFP is currently the same as using FPP plus a few (worthy) protections.

The changes in Arkenfox are just for building up a crowd, while waiting for more metrics to be covered by FPP?

I'll personally choose to keep using RFP, while trying to stay up-to-date with FPP changes (hopefully an announcement is made when it's time to let go of RFP).

Paranoia bit: will saying I use RFP get me easily tracked?

[Thorin-Oakenpants]

The changes in Arkenfox are just for building up a crowd,

There is NO crowd. Forget this analogy. Maybe in 3 years time FPP will cover enough to be meaningful and enough users out of 150mn FF users use ETP Strict. Remember, TB is only ~6mn users.

So I'm guessing that

RFP and FPP both randomize canvas. This is enough to fool naive scripts. That's it. Nothing has changed (except arkenfox defaults). If you can handle RFP I recommend it, otherwise you never could so use FPP - as per the wiki since FF120

will saying I use RFP get me easily tracked

If you do nothing .... you are unique. You can't make it worse. With RFP or FPP at least you have a built-in browser solution to randomize canvas = naive scripts will be sucked in. FPP is more user friendly. Personally, I prefer RFP - you can exempt canvas on select sites if need be. You can even exempt domains for RFP (e.g. gmail since you log in anyway). Maybe exempt netflix or youtube if you log in and need to watch videos but can't handle the 60FPS (not knocking this, everyone has different hardware - I just don't experience it) - or use a secondary browser

[xlacroixx]

Thanks a lot for the clarification!

I'm still messing up, it seems. I can handle RFP. I even got used to 60 FPS instead of 144.

The scary thought was more about tracking companies stumbling upon this comment but, probably unlikely.

[zdat]

The changes in Arkenfox are just for building up a crowd,

There is NO crowd. Forget this analogy. Maybe in 3 years time FPP will cover enough to be meaningful and enough users out of 150mn FF users use ETP Strict. Remember, TB is only ~6mn users.

So I'm guessing that

RFP and FPP both randomize canvas. This is enough to fool naive scripts. That's it. Nothing has changed (except arkenfox defaults). If you can handle RFP I recommend it, otherwise you never could so use FPP - as per the wiki since FF120

will saying I use RFP get me easily tracked

If you do nothing .... you are unique. You can't make it worse. With RFP or FPP at least you have a built-in browser solution to randomize canvas = naive scripts will be sucked in. FPP is more user friendly. Personally, I prefer RFP - you can exempt canvas on select sites if need be. You can even exempt domains for RFP (e.g. gmail since you log in anyway). Maybe exempt netflix or youtube if you log in and need to watch videos but can't handle the 60FPS (not knocking this, everyone has different hardware - I just don't experience it) - or use a secondary browser

How do you exempt domains with RFP? I didn't know you could do that.

[rusty-snake]

https://github.com/arkenfox/user.js/wiki/3.3-Overrides-%5BTo-RFP-or-Not%5D#-rfp

[Thorin-Oakenpants]

How do you exempt domains with RFP? I didn't know you could do that.

Like this

user.js/user.js

Lines 840 to 841 in f906f7f

	/* 4505: disable RFP by domain [FF91+] ***/
	// user_pref("privacy.resistFingerprinting.exemptedDomains", "*.example.invalid");