A browser kernel per profile

The browser version is part of what a site reads about you. It stands in the User agent, the client hints and the features a page can test for.

With one engine for the whole app, an update moves every profile to a new version on the same day. Twenty accounts changing browser together is the pattern a platform reads as one person at one machine.

A warmed account has a history of versions behind it, and that history is supposed to move the way one person's browser moves. So the build belongs to the profile.

A build is a folder named by its version with the browser program inside it. The app keeps them in its own data folder, one folder per version.

A folder with nothing runnable inside never shows up in your list, so an interrupted copy never looks like a working build.

• The name is the version

  Two to four numbers with dots. A folder called latest, or one that climbs out of the builds folder, is turned down.

• The program is found by name

  ARMANOS Browser.app or Chromium.app on a Mac, armanos-browser.exe or chrome.exe on Windows, chrome or armanos-browser on Linux.

• Newest first

  Versions stand in number order, so 99 never sorts above 153.

• The row carries its weight

  Size on disk and the names of the profiles pinned to it stand on the same line.

You unpack a build into a folder and point the app at it: Engine > Browser kernels > Install from folder. Nothing is downloaded for you.

1. 1

   You name the version

   The field takes digits and dots and hands anything else back to you before a file is touched.

2. 2

   The folder is copied

   Cleaning out Downloads later changes nothing, because the build now lives inside the app.

3. 3

   A half copy is thrown away

   A folder only takes its name once the program is found inside it, so a copy that broke off never becomes a build.

4. 4

   A version already here is refused

   You are turned down when you install over a build profiles may be pinned to, rather than having it overwritten.

A profile with a pinned kernel opens on that kernel, whatever app wide path the Engine screen holds.

The version a site reads comes from that browser program itself, not from the folder name. The folder name stands in only when the program answers nothing, and then a name typed wrongly reaches the site.

A profile can carry a pin for a kernel this computer never had, because a profile record moves between machines far more easily than a browser kernel does. Quietly handing it another one would put an account in front of a browser version it has never seen.

So you hear about it twice: in red on the Engine screen with the profiles that are waiting, and in the notification list at the moment such a profile opens.

In the profile card the version stays where you put it, marked as not installed here, rather than falling back to the default and losing your choice.

Profiles run on one of two engines: ARMANOS Browser, or the built-in engine the app falls back to. Pinning belongs to the first of them.

With the app set to the built-in engine a profile opens through that instead, and a pinned kernel sits unused until you switch back.

A kernel no profile in the list is pinned to you remove with its folder. A kernel one of them is pinned to you cannot, and the refusal names those profiles. A profile waiting in the recycle bin is not in that list, so its kernel can go while it waits there.

The alternative is finding out tomorrow, when a window does not open the way it did yesterday and nothing on screen connects that to a folder you tidied away.