I think the about:config utility I want is something that keeps track of manually altered preferences. Ideally something like userChrome.css where I can simply override/extend behavior. This is probably already a thing, but it's a bit annoying to not know the origin of non-default prefs.
Once heard that once you setup your own user.js, Firefox will stop updating default settings, because they might override your settings. Over time that might cause you to not get new features enabled. Is this true?
This is well known but does not show manually modified preferences rather ANY modified preferences as the name implies. Even out of the box on a fresh install this results in pages of "modified preferences" that didn't even have a user initiated trigger.
This shows also shows preferences modified in indirect ways such as about:preferences, devtools, etc. Helpful to filter a list of potentially manually toggled prefs, but not a 1:1 filter.
Do you mean something like recording notes for _why_ a preference was changed in addition to the built-in tracking of which preferences have non-default default values?
There is no built in tracking of manual modifications and non-default values is a very different filter in this case.
The notes idea would be interesting though ideally the names of the key and values would be descriptive enough the reasoning for the change is obvious in 95%+ of cases (the other 5% being noting a bug workaround). As is the key names are usually pretty good but some of the opaque enum values could definitely use a note (or text based values instead) e.g. things like TRR mode being set to 2 vs 3 is always a google search.
I'm going to pipe up here 'cause this has bothered me a lot too.
$ grep user_pref prefs.js | wc -l
230
In this profile I have 230 modified preferences. I'm pretty sure scanning the list in "show only modified" that it is all of those. The vast majority were autoset by Firefox or Firefox extensions.
What I would love to find is prefs that I explicitly set manually in about:config. Those are the ones I realllly wanna find later if I messed something up. It would also be nice to have those explicitly set by a user action in Settings too.. Elsewhere contravariant mentioned "user.js" I'll look into that and it'll be super helpful on the desktop. Less so on Android where, thankfully, about:config is still accessible in the F-Droid Fennec firefox build (unfortunately they can't do anything about all my useful addons that were removed or removal of prior functionality but I'll take what I can get).
> What are you looking for which the “show only modified preferences” button doesn't provide?
Things handful of things I the user have actually set to be a certain value not the hundreds of things that are not the initial value the instant you launch the browser for the first time or the hundreds more that change from normal use after that. Just the 3 or 4 I have actually changed. Or even the couple dozen I have changed as a result of changing the settings in the UI over time. Anything but the hundreds of internal state values, A/B tested features, and settings which get changed without user intervention but aren't that way in the default profile for some reason.
Sometimes Firefox takes a lot of CPU power. Then I go to the about:performance tab, and kill some or even all of the tabs sometimes, but Firefox keeps consuming CPU power. What is going on?
If that happens, I typically will close Firefox and take a short break. Sometimes I will shut down my machine as well. Either way, its a win-win for me, my machine and Firefox. Everything seems better after that short break.
"Downgrades built-in Firefox security features" is a gross mischaracterization, bordering on FUD.
Chrome scripts require careful security analysis, just like software that runs with root privileges.
Firefox ships with zillions of lines of chrome script, and none of those zillions of lines "downgrade" any security features. Software isn't automatically secure simply because it came from Mozilla. Microsoft tried the same nonsense to scare people out of using Linux at one point... you'd have to be nuts to run kernel code that didn't come from Redmond!
There are security checks for detecting userChrome.js. My understanding is that Firefox is going to let people customize as before but just not enable some security enhancements for those users. https://searchfox.org/mozilla-central/rev/02bd3e02b72d431f2c...
Essentially, it allows calling eval[1] and executing "privileged loads"[0] in some elevated contexts (the System Principal, which is responsible for the browser UI[2]).
Those are useful mitigations, but disabling them for some custom user-chrome is unlikely to have a meaningful impact on your browser's security.
Using the DNT (Do-Not-Track) header as an example. When you make a request to a service, you're browser can attach this DNT header to signal to the service that you don't want to be tracked. But since services that you're getting responses from can just ignore that (no repercussions for ignoring it really), it becomes another data point they can use to separate you from other users who's headers would be the same as you.
1. resistfingerprinting (RFP) doesn't affect DNT. it's also not some sort of flag that nicely asks services to stop tracking you.
2. That's not a good analogy. If we're looking at a single choice in isolation, it's true that opting into DNT (or RFP) makes you stick out compared to everyone. There's only two options (DNT header being present or not), and one option is obviously more common than the other. However, the difference with RFP on/off is that there aren't really two options. Yes, RFP can only be on/off, and "on" is much more rare than "off", but leaving it "off" also uniquely identifies your device through fingerprinting. You're not really choosing to blend into the "all the people with RFP on" group vs "all the people with RFP off" group. You're choosing to blend into the "all the people with RFP on" group vs "all the people with RFP off and has the fingerprint as you" group[1]. Whether that's more or less identifiable is unclear. If you have the most run of the mill setup[2], then RFP might indeed make you stick out more compared to your normal setup. However, if you have an uncommon setup, it might make you stick out less, because the amount of RFP users is greater than the amount of users with the same fingerprinting attributes as you.
[1] in reality it's not really one group for RFP users and separate groups for everyone else. There are fingerprinting attributes that RFP doesn't block, so it's more like a set of groups for RFP users, and a separate set of groups for non-RFP users, but there are less distinct elements in the RFP set, since various fingerprinting attributes are spoofed to be the same.
> So in short: your normal browser does not have to be honest about it's properties, but it won't make you more anonymous because you still stand out from the other people and content on the web will break. Tor works because everyone has the same properties, including resolution. You can surely change your resolution, but there is just simply a chance that you will be standing out from other people. It's just safer to keep it the way it is.
If the "resist fingerprinting" feature changes anything in the data that is read by trackers, you will stand out like a sore thumb among the millions of browsers with the default settings.
When you are one of the few people that enable this feature, you are part of a smaller group of people. Maybe you are the only person in your own using this feature, so seeing a single client with the "resist fingerprinting" characteristics and correlating that with things that the browser cannot avoid (e.g. IP address mapping), you might now be uniquely identifiable.
Fingerprinting resistance should be more focused on feeding false information to these algorithms rather than crippling their functionality and thus sticking out from the crowd.
To my knowledge, resistFingerprinting mostly does the latter.
The problem is that "feeding false information to these algorithms" only really works if the algorithms are naive and don't try to detect whether you're lying. If your "feeding false information" mechanism can be detected, you're still in the same position.
Is there something that's the opposite? So the browser doesn't reload resources all the time and shares resources between tabs to give a smaller memory footprint and lower latency? I really couldn't care less if the websites I visit fingerprint me (if I do, then I use a private tab)
That pref is intended for Tor Browser. It works in mainline Firefox but is a massive footgun, because it enables a bunch of behaviours that most users aren't anticipating and don't realize are now occurring as a result of enabling that pref.
Yeah but check about:policies carefully every time you edit that file.
If there is even the tiniest syntax error in policies.json, Firefox silently ignores the entire file. The only way to know this happened is by checking about:policies.
Mozilla had to be dragged, kicking and screaming, into providing any kind of stability guarantee for configuration options. "Policies" are just configuration options that have been blessed with this stability guarantee. But Mozilla is still throwing a tantrum over having to provide it...
