Multilogin froze Stealthfox, and what a legacy engine means

Multilogin calls Stealthfox, its Firefox-based browser core, legacy. Its release notes and its help page on the two cores point users to Mimic, the Chrome-based core, and say the Firefox one will not get new versions. Existing profiles still open. What changes is that the browser they imitate keeps moving and they do not.

What a legacy Stealthfox core means

An anti-detect browser's core is a modified build of a real browser. Each time the real browser ships a new major, the vendor rebases its changes onto the new source, rebuilds and ships a new core. Firefox and Chrome both put out a new major roughly every four weeks, so this is monthly work, and it never ends.

Legacy means that work has stopped. Nothing is broken on the day a core is frozen. The problem grows one release at a time.

How it works: Its own Chromium

Why a frozen version becomes a signal

Real browsers update themselves, so the share of visitors on any one old version shrinks with every release after it. A frozen core sits on its last version while that share drains away underneath it. The version string alone does not mark anyone, but the profiles left on it end up in a smaller and smaller crowd, and that crowd is increasingly made of browsers that never update.

A core can claim a newer version than it is. That only moves the problem. A page does not have to trust the User-Agent; it can test for the features each release added. A browser that says it is a newer Firefox and lacks what that version shipped has contradicted itself in a few lines of script, and the contradiction is stronger evidence than an old version ever was. The same holds below JavaScript. The TLS hello a browser sends changes with its releases, which is why JA4 moves with the Chrome major: a version claim also has to agree with the handshake underneath it.

And "no fixes" covers the fingerprint work too. When a detector learns to read a new surface, an active core gets a patch. A frozen one does not.

Why the vendor tells you to move

Two cores means every fingerprint change done twice, in two codebases with different internals. Firefox and Chromium differ in how they draw canvas, report WebGL, list fonts and shape their network traffic, so very little transfers. Keeping a second engine current is a second monthly rebase. Multilogin has chosen to spend that effort on Mimic and asks its users to follow.

If you run Stealthfox profiles, the practical reading is the one Multilogin gives: export them and plan the move before the version gap gets wider.

What keeping one engine current costs us

We made the same choice from the other end. Mosaic has one engine, Tesseract Chrome, built from stock Chromium source with our patches on top, and no Firefox core. That is a real limitation if your work needs Firefox profiles, and the Multilogin alternatives roundup compares the other products, engines included.

Staying current is the job we did not want to have twice. We timed our last move to a new Chrome major: 93 minutes for the near-full rebuild a version bump costs, against one or two minutes for an incremental build after changing a single patch. Our comparison against a real browser refuses to run across two majors, because comparing one major with the next measures the release, not our changes. So every new major means running that comparison again, and it keeps finding things a version number would never show, such as twenty API entries where a plain Chromium build and Google's Chrome differ.

Moving profiles out of Multilogin

Mosaic's importer recognises a Multilogin export by its shape. It maps across the profile name, notes, proxy, start pages, cookies where the export carries them, and the fingerprint fields Multilogin recorded. The profiles land in Tesseract Chrome, a Chromium engine. The difference between the two products as a whole, local engine against cloud platform, is laid out in Mosaic vs Multilogin.