We lock preferences because we want to avoid users to flip them possibly without realizing the consequences.
I once read of someone suggesting to disable RFP to be able to login to Mozilla sync.
I agree that locked preferences should not be used, unless extremely motivated.
If I could lock only one preference, I’d choose to lock RFP.
Disabling RFP will basically destroy your application layer protection.
RFP should be considered a core part of Tor Browser.
For example, almost all protection for hardware-based fingerprinting is gated on RFP.
The exceptions are very rare, e.g., audio devices. Mozilla found that the majority of calls to navigator.mediaDevices.getUserMedia() were not for legit purposes, and added media.devices.enumerate.legacy.enabled.
They did it only recently, but RFP has protected against this for years.
Also, when we upstream our patches to Mozilla, we often gate them behind RFP.
Disabling RFP is like saying that you don’t want some patches that used to be Tor Browser.
We’re aware that RFP introduces accessibility problems, and we’re going to work on that.
But for now, RFP is going to stay locked in release (it isn’t in alpha and nightly, where users know that they’re possibly more exposed to problems).
As for the donation requests, 13.0.4 (scheduled around next Tuesday) will keep it closed for the rest of the session, see tor-browser!843.
If you’re referring to new identity, it was a response to possibly attacks and it was suggested by a code audit we had a few months ago, see tor-browser#41765.
We have heard the requests, and opened tor-browser#42236.