A new drawback of using my custom-compiled Firefox

January 11, 2019

For years I've used a custom-compiled Firefox, with various personal modifications. Usually this works okay and I basically don't notice any difference between my version and the official version except that the branding is a bit different (and since I build from the development tree, I'm usually effectively a Firefox version or two ahead). However, I've now run into a new drawback, one that hadn't even crossed my radar until recently.

The short version is that I read a spate of news coverage of what compiler Firefox was using, starting in September with the news that Firefox was switching to clang with LTO but really picking up steam in December with some comparisons of how Firefox builds with GCC and clang compared (part 1, part 2), and then Fedora people first considered using clang (with LTO) themselves and then improved GCC so they could stick with it while still getting LTO and PGO (via Fedora Planet/People). All of this got me to try building my own Firefox with LTO (using clang), because once I paid attention the performance improvement of LTO looked kind of attractive.

I failed. I don't know if it's my set of packages, how my Fedora machines are set up, or that I don't actually know what I'm doing about configuring Firefox to build with LTO (Link-Time Optimization), but the short version is that all of my build attempts errored out and I ran out of energy to try to get it going; my personal Firefox builds are still plain non-LTO ones, which means that I'm missing out on some performance. I'm also missing out on additional performance since I would probably never try to get the PGO (Profile-Guided Optimization) bits working, as that seems even more complicated tha LTO.

On the one hand, my impression is that much of the performance benefit is on Javascript-based benchmarks and sites, and in my main Firefox instance I block almost all Javascript from almost everyone (although I'm getting a bit more relaxed about that). If I'm using Google Maps or some other Javascript heavy site, it's in the official Fedora Firefox and very soon that's going to have both PGO and LTO.

On the other hand, there are two cases where I actually do care about Javascript performance in my main Firefox and it's probably a limiting factor. The first is for our new Grafana dashboards; I usually view these in my main browser for convenience, and my typical style of dashboard winds up running rather a lot of Javascript, DOM manipulation, CSS (re)sizing, and so on that takes a visible amount of time and CPU. I don't look at our dashboards all that often, but it would be nice if they were more responsive.

The second and much bigger case is Firefox addons themselves. All WebExtensions addons are completely written in Javascript, and things like uBlock Origin are not small and do an appreciable amount of Javascript computation in the process of blocking all of the other Javascript for me. In fact, uBlock Origin has started using WebAssembly for some of its CPU-intensive internals (currently for a hostname trie, and see also, and there's also WASM lz4 stuff). Improving the performance of addons would basically improve the performance of my Firefox as a whole, since addons potentially run on everything I visit (and both uBlock Origin and uMatrix are probably active on basically every page load).

(LTO and PGO may not improve the performance of WASM and JIT'd Javascript very much, though, and hopefully much addon code is heavily JIT-optimized because it runs so often and is in a more or less permanent context.)

In the long run hopefully I'll be able to build my own version of Firefox with LTO and most of this will be irrelevant (because I'll have most of the performance of official Fedora and Mozilla builds). I'm happy to do it with either GCC or clang, whichever is easier to get going (I'd say 'works better', but I'm honest; I'll pick whichever is less hassle for me). Even if I can't get LTO going, I'm not likely to give up on my custom-compiled Firefox because my patches are fairly important to me. But the whole LTO experience has certainly given me something to think about.

(Chrome is a much more extreme case for differences between official builds and your own work or even Chromium, because only the official Google Chrome versions come with Flash magically built in. There are things that still might need Flash today, although fewer than there used to be. Your Linux distribution's Chromium builds probably come with much less Google surveillance, though.)

Comments on this page:

By Jukka at 2019-01-14 02:31:01:

Are you sure about the extensions? Check this out:


At this point, I'm inclined to say that one shouldn't use any extensions whatsoever, but instead patch a browser by hand (and preferably your own hand).

By cks at 2019-01-14 11:21:40:

Extensions are dangerous in general but I feel that addons in Firefox are less risky than Chrome for various reasons and my curated set is not dangerous in particular. All of them are open source (and I have copies of the source), and many of them are highly regarded and used and thus very likely have a lot of people paying attention.

(I also have Firefox set to not auto-update extensions. Since I track the repos for the extensions, I should see a strong correspondence between Firefox offering new versions of extensions and changes in extension repos. If I see an update with no repo changes or no new version tag (for the repos that use them), that's a red alert.)

By Jukka at 2019-01-14 12:55:57:

I concur in the sense that the comment was not about uBlock, NoScript, or anything like that. I'd trust those as well. But think about the grand issue in probabilistic terms: what would be the probability for picking out a random Firefox extension with glaring security and privacy issues?

At a more practical level, I think the problem is that extensions, add-ons, etc. bypass the traditional sanity-checks done at the distribution-level. The same goes for repositories; people are nowadays commonly using random software from random repositories (CPAN, CRAN, PyPI, npm, you name it). In this sense, many open source ecosystems are increasingly becoming like the malware-ridden Android "app" marketplace.

So in terms of browser extensions, do we even have a mailing list for curating common security and privacy issues? Even better would be a vulnerability (privacy) database. I wouldn't exactly trust Mozilla/Firefox or Google for these tasks.

Written on 11 January 2019.
« Why I still have a custom-compiled Firefox (early 2019 edition)
I have somewhat mixed feelings about Python 3's socket module errors »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 11 01:25:24 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.