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.

You can set preferences with a user.js file in your profile directory. See for example: https://github.com/pyllyukko/user.js/blob/master/user.js

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?

I don't know, but wouldn't that apply to about:config settings in general?

Afaik it does.

I really like this route. Thanks!

> This is probably already a thing

On about:config to the right of the search bar at the top is a checkbox "Show only modified preferences".

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.

> There is no built in tracking of manual modifications and non-default values is a very different filter in this case.

What are you looking for which the “show only modified preferences” button doesn't provide?

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.

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.

what's your firefox version and OS name and version?

Firefox 96.0.1 on Ubuntu 18.04

Is this ubuntu.com Ubuntu or flavors like xubuntu, kubuntu, ubuntu-mate etc?

Pure Ubuntu (no flavor)

This is a "chrome script" extension, which downgrades some of the built-in Firefox security features. Use at your own risk.

"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...

What are the "security enhancements" that those users are missing out on?

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.

[0] https://searchfox.org/mozilla-central/source/dom/security/ns...

[1] https://searchfox.org/mozilla-central/source/dom/security/ns...

[2]: https://blog.mozilla.org/attack-and-defense/2020/06/10/under...

First one I found was blocking of eval()

https://searchfox.org/mozilla-central/source/dom/security/ns...

As pointed out by sibling-comments, this seems to be in the context of making sandbox escapes harder.

Someone posted downthread to use this instead:

https://github.com/mozilla/policy-templates

It's from Mozilla.

I see there's an option "Resist fingerprinting", is it working well or fingerprinting is unavoidable nowadays?

Usually such "resist" stuff ends up providing more bits to the tracker so they can fingerprint you even better.

This mode exists to enable the Tor browser's idea of fingerprinting resistance. The reasoning for why it works the way it does is documented in their design document at https://2019.www.torproject.org/projects/torbrowser/design/#....

I haven't check Firefox's fingerprint resistance but Bromite's is very effective against https://fingerprintjs.com/ at least.

Just using Firefox is enough bits :P

Can you please elaborate?

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.

[2] see https://wiki.mozilla.org/Security/Fingerprinting for list of features that are spoofed, and make your own determination how common your setup is.

I am not very well-versed in this, but I have read many pieces like this: https://forum.vivaldi.net/topic/52638/to-resist-fingerprinti...

> 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.

Tor Browser also quantizes document width so it’s much less of a fingerprint.

You turn on the option. This causes your browser to act in a different, specific way, that can then be detected.

Most people do not change default options, so just turning on that option is something that identifies you.

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.

By blocking various fingerprint mechanisms you provide the information that you have fingerprint blocking on, which is in itself a data point. Whether that makes it worse to turn it on I don't know - you're removing some data points, but adding more.

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.

Now that I think about it more, yeah sadly. Even worse, it could be only effective on a per script or even just a per site basis.

I find it gives me more hardship than worth it. Notably, GitLab fails to load the login page with it on.

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)

Most of the fingerprinting resistance features aren't cache/performance related. https://wiki.mozilla.org/Security/Fingerprinting

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.

One thing it does is tell websites that you want a light color scheme.

Wow, you can still use userchrome js nowadays? I thought it has been killed by Firefox long time ago. How exactly do you load it?

The tool I used before [1] https://github.com/satyr/uc hasn't been updated since 2016, and http://userchromejs.mozdev.org/ is entirely gone.

It's quite a rickety process ever since XBL was removed in 72. This repository is usually the preferred base if you're interested though https://github.com/xiaoxiaoflood/firefox-scripts

Yes we can still create uc.js in 2022. MDN no longer serve the XUL doc. However we can search their archived doc repo, e.g. https://github.com/mdn/archived-content/search?q=nsIPrefServ...

Usually a much better option to about:config when available is a policy file:

https://github.com/mozilla/policy-templates

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...

> But Mozilla is still throwing a tantrum over having to provide it...

That's funny, I didn't see any tantrums about policies when I worked there. Citation needed.

The title reminds me of this comic: https://xkcd.com/1678/