Lock RFP in release builds

added Next label

assigned to @pierov

can we not lock RFP in alpha - it's very handy for testing

We can do conditional locking (001- is preprocessed), but it's hard to test it on our side .

We should also lock any other related FPP and RFP prefs as well, even if they're in the process of being deprecated or worked on: e.g.

RFP

privacy.resistFingerprinting.exemptedDomains
privacy.resistFingerprinting.testing.setTZtoUTC
privacy.resistFingerprinting.testGranularityMask
privacy.resistFingerprinting.pbmode (RFP pref overrides this anyway)

FPP

privacy.resistFingerprintingLite / privacy.resistFingerprintingLite.overrides (these seem to be removed or hidden)
privacy.resistFingerprinting.randomization.enabled
we should check with tom

I agree. We also have #25438 (closed), but I opened this issue even though I knew it's a sort of duplicate to give higher priority to RFP (and strictly related prefs).

@pierov since you mentioned you could use macros for conditional locking but that might make testing hard (not sure why), is @thorin's suggestion something to consider? I believe something like a .cfg could also work for different Tor Browser releases and it is handier to setup since it applies to all profiles.

Ideally stable releases could have everything locked down and alpha versions could use .cfg to unlock what needs to be unlocked. It would also be handy for alpha testers to intentionally flip prefs and keep track of them.

you mentioned you could use macros for conditional locking but that might make testing hard (not sure why)

I'm not sure either . Maybe I meant that we usually never run builds with the release profile from the default branch. So, it isn't harder, but more error-prone, since it needs an additional step on our side.

But maybe for 13.0 this approach could be feasible.

We still have to go through the preferences (sigh, I don't want to think to that task). We could check if we come up with preferences to lock. cypherpunks1 already made a list of fingerprintable prefs.

I wonder if we could do something like

#ifdef RELEASE_OR_BETA
#  define LOCKED_IN_RELEASE locked
#else
#  define LOCKED_IN_RELEASE
#endif

and then

pref("privacy.resistFingerprinting", true, LOCKED_IN_RELEASE);

I think RELEASE_OR_BETA doesn't apply to our alphas, but there's only a way to find out.

is @thorin's suggestion something to consider?

No, not really .

I like trolling @thorin (and myself), but I'm not a fan of locking down. I think only some preferences like this one should be absolutely locked. The only case for not having it locked down is testing. But our browsers without RFP are basically to be considered broken.

But about:config is too helpful for a lot of stuff to remove it, including setting debug levels. I'd rather remove the checkbox to disable the warning, and always show it instead, for starters. Maybe even making the warning more scary.

(Thorin: skulls anywhere? ).