Hardening Firefox – a checklist for improved browser privacy

Set the browser.ml.chat.enabled and browser.ml.enabled to false as they intensively use the processor and drain the battery. All that to just find the best name for your tab groups. I prefer to have my laptop last one more hour instead.

I took a brief gander at its code [0] and saw it mainly focusses on k-means clustering algorithms (in JS, no less). To my ken this is likely for suggesting new tabs, something a user is even less likely to use than renaming them.

Its constant drain even when not 'in use' seems to imply it's classifying tabs as they change page (though it might be telemetry or uncommented testing). If so, it's an example of premature optimisation gone very wrong.

It's a shame, because it overshadows the fact that naming tab groups is a perfect use case for an LLM, alongside keyboard suggestions and reverse dictionaries [1]. I'm ardently distrustful of LLMs for many, many purposes, but for the tiny parameter and token usage needed it's hard to not like. Which is a shame it's (somehow) such a drain.

[0] https://github.com/mozilla-firefox/firefox/blob/7b42e629fdef... exports a SmartTabGroupingManager, though how or why that is used without being asked eludes me

[1] https://www.onelook.com/thesaurus/ Can be helpful in a pinch when a word's on the tip of your tongue, though its synonyms aren't always perfect.

I didn't know about this 2 settings but they were already disabled in my about:config. I wonder if Debian distributes a non-default about:config with Firefox.

Wasn't that a bug that was fixed weeks ago? Like early August? If you are not averse to this feature then it is better to simply make sure you are running the latest version.

I litterally gained one hour off my charged battery when I switched these two settings off, just a week ago, and I keep my browser up to date. So not for me.

It was also caught during progressive rollout, i.e. it never affected anyone who had disabled "studies" in their preferences.

They do, see /etc/firefox-esr/firefox-esr.js -- but the aforementioned settings are not in that file by default, and [0] seems to suggest Debian does not alter the compiled-in defaults either.

Some quick digging in the source suggests that it's simply not enabled by default in ESR 128. I don't know if that's because it's only enabled by default in a later release, or because it's disabled in all ESR releases; I suspect the former. Compare [1] and [2]:

  -pref("browser.ml.enable", false); # in upstream/128.14.0esr
  +pref("browser.ml.enable", true); # in upstream/142.0.1

The other pref, browser.ml.chat.enable[d] is not mentioned in that file at all.

(edit: according to [3a] and [3b], it's browser.ml.enable and browser.ml.chat.enabled... yay for consistency, I guess)

[0] https://sources.debian.org/src/firefox-esr/128.14.0esr-1~deb...

[1] https://salsa.debian.org/mozilla-team/firefox/-/blame/upstre...

[2] https://salsa.debian.org/mozilla-team/firefox/-/blame/upstre...

[3a] https://salsa.debian.org/mozilla-team/firefox/-/blame/esr128...

[3b] https://salsa.debian.org/mozilla-team/firefox/-/blame/esr128...

On an 80wh battery, say you go from 7hrs to 8hrs, so- 10wh saved over 8hrs. Thats a 1.125watt difference.

I propose the below as various factors that can be larger:

Slower fan speed because of lower ambient temperature.

Different dark/light ratio and/or adaptive screen brightness.

Wifi spectrum congestion, variable power levels to maintain proper SNR.

Wifi/ethernet- broadcast packets.

The list goes on. Most of these are below a watt, but demonstrate the point that you've got a lot more variables than just one setting in a browser.

You sound like 1.125 watts is insignificant to a laptop, but my laptop idles around 6 watts and it is currently using 8 watts since I've got some stuff running. Shaving off 1.125 watts is a 14-19% improvement.

The point is that the shaving might not be due to the firefox variable changes, but rather to other environmental differences.

Does anyone here struggle so much with naming a group of tabs that you'd reach for an LLM? I mean... really? How often does a group of tabs need a more complex name than "Work", "Gaming", etc? Maybe a suffix for the work project?

Exactly. And honestly- the screen is way way more than 1watt. According to RAPL power, a USB-PD power analyzer- changing the brightness on my 15" 4k OLED laptop screen can reduce power usage by 15-20W. The nature of OLED makes it hard to get a clear picture.

Thanks for the heads-up! Yeah, I'm running ESR 128 right now so when I upgrade to the next ESR I'll keep an eye on these settings.

I recall an extension (I think by a Mozilla dev) which could do automatic grouping of tabs (back before tab groups was removed). I'm surprised this hasn't come back.

You can preload them now in your profile `user.js` - FF will ignore any settings it does not know about, it's "safe" to leave old things that got deleted and add new things coming in the next ESR without harm (that I'm aware, been doing it for years). A user.js is portable, not relying on any given vendor configurations.

i think the implementation is more that when you connect two or more tabs, it automatically names it for you, meaning you don't have to rename it (at least, that's my experience with the feature in Edge)

Tab grouping is here, but not sure about automatic grouping.

https://news.ycombinator.com/item?id=43834101

People drew their own conclusions about the drain being caused by tab group suggestions, but that wasn't the cause: https://bugzilla.mozilla.org/show_bug.cgi?id=1982278#c4