The version that was never published

A browser and a portable browser are the same program with one difference that turns out to matter more than it sounds: where the profile lives. Installed in the normal way, everything you care about — bookmarks, saved passwords, extensions, sessions, the shape of the interface — is written into a location tied to the user account and to the machine, plus a scattering of entries in the system's configuration database. That is the correct design for a computer with one owner. It becomes an obstacle the moment you want the same browser on a computer that is not yours, or on several that you do not own at all. The official build has no answer to that; this one is an answer.

One folder, containing everything

Every build of this browser has portable operation built in rather than bolted on. The profile, the extensions, the bookmarks and the cookies all live inside a folder in the program's own directory, and nothing is written into the per-user application data area or into the system registry. The consequence is the one people actually want: the whole thing can sit on a removable drive, and plugging it into another Windows machine produces the same browser, with the same bookmarks, the same passwords and the same extensions. Removing the drive removes the data with it, because the data never lived anywhere else.

The same property answers a second, quieter problem. On a machine where installing software requires an administrator and an approval, unpacking a folder into a directory you can write to is not installation at all — it is a folder. Nothing is registered, nothing appears in a list of installed programs, and nothing needs to be uninstalled later. For anyone who has waited three days for a ticket to be approved in order to use a browser, that difference is the entire feature.

The same engine, so the same extensions

The build comes from the same source code, which means the engine and the rendering behaviour are identical rather than merely similar. Everything that follows from that follows here too: pages that render correctly in one render correctly in the other, the developer tools are the same tools, and the extension ecosystem is not a subset but the whole thing. Extensions, themes and the various content-blocking and page-modifying tools that people rely on install normally and work normally, because underneath there is no difference to work around.

The project is maintained by a single developer and moves on a weekly rhythm in step with the upstream version cadence, which is the honest description of both its strength and its risk. A one-person project following a large one is how many useful derived builds exist; it also means the continuity depends on one person's continued interest. The source is published openly under the MPL, so the build can be reproduced or continued by someone else if that interest ever ends.

What is actually different

Three things, and it is worth being precise because the temptation is to oversell them. The first is portable operation as a native capability rather than an external wrapper — the difference between a program designed to keep its state in its own folder and one tricked into it. The second is branding: the upstream trademarks and icons are removed and replaced with this project's own name and identity, which is why it does not present itself as the browser it is built from. The third is compilation: the maintainer's builds may carry optimisation choices at the compiler level that the official build does not make.

Beyond those three, everyday use is the same experience. Same rendering, same compatibility with the web, same tools for anyone who opens them. Anyone expecting a different browser will be disappointed, and that disappointment is the point: this is not another browser, it is the same one with the packaging problem solved.

Who it is actually for

Four kinds of people, and each is answered by a different part of the same property. Anyone who moves between computers regularly — students, administrators, support staff — carries one browsing environment instead of reconstructing one each time. Anyone on a managed machine without administrative rights gets a usable browser without a ticket. Anyone who cares about traces gets a browser whose entire footprint is a folder that can be deleted, which is a cleaner proposition than any private-browsing mode, since private modes still leave the program installed and its profile on disk.

And then the fourth group, which is the one that will actually keep using it: people who already like this particular browser's ecosystem and habits, and want those habits available where they are, rather than relearning a different one for the sake of portability. That is a modest motivation and an entirely reasonable one, and it is the sort of need that a large project rarely serves because it is too small to prioritise.

Nothing here reinvents anything. It takes a browser that is already good and produces the version that can be carried: one folder, no installation, the data travelling with the program. For anyone who needs a portable browser, that is more useful than a longer feature list.

The honest summary

This is a packaging decision presented as a product, and packaging decisions are underrated. The engineering is mostly in following a large codebase weekly and keeping a portable configuration correct across versions, which is unglamorous maintenance rather than invention. What it produces is a folder that behaves the same everywhere, keeps its state inside itself and leaves nothing behind — and for the specific situations where that matters, no amount of features substitutes for it. The limitation is equally clear: one platform, one maintainer, and an existence that depends on staying in step with something larger.