Isolated profiles

Launch a profile on ARMANOS Browser and it gets its own user data directory, one folder per profile id under fork-profiles. Chromium writes everything it persists into that folder: cookies, local storage, IndexedDB, cache, service workers, saved logins and history. The path is handed to the engine as --user-data-dir at spawn time.

Nothing crosses between two of those folders, because the engine never learns that the other one exists. Two profiles on the same computer cannot read each other's cookies, and a site logged in inside one sees nothing of the other.

On the built-in fallback engine the isolation comes from an Electron partition instead, named persist:armanos-profile plus the profile id. Different mechanism, same rule: one profile, one store. That matters at deletion time, because the app has to erase both kinds of storage to keep its word.

The list itself lives in profiles.json in the app's own data directory. Pinned profiles sort to the top, then the rest by the time you last opened them, so five working profiles do not sink under ninety-five idle ones.

• Its own data directory

  fork-profiles/<profile id>, passed to the engine on the command line.

• Its own cookies, storage and cache

  Everything Chromium persists, including service workers and saved logins.

• Its own extensions

  Your enabled extensions load into that profile only, next to a protection extension written per profile at launch.

• Its own proxy

  Address, credentials and exit country belong to the profile, not to the machine.

• Its own fingerprint

  Derived from the profile id, so the same profile is the same machine on every device you sign in from.

• Its own open tabs

  A snapshot is written quietly, without touching the edit time, so a crash can offer the tabs back for up to a week.

Creation takes a handful of decisions and writes them all at once. The scenario decides the injected scripts, the tracker lists, the daily action limits and the site the profile opens on. Five scenarios are offered: privacy, e-commerce, social, ad accounts and freelance. A sixth, older one is kept in the code but hidden, because profiles already created on it must keep their own rules rather than be moved silently.

The template decides which machine the profile claims: macos-chrome, windows-chrome, linux-chrome, android-chrome or android-tablet. Group, tags and notes are yours to organise with. A start URL is validated at creation, not only at edit time, so a bad address fails in front of you instead of falling back to the scenario silently. A kernel version is accepted only as digits and dots, because it becomes part of a folder path.

You can supply the profile id yourself: 8 to 64 characters of letters, digits, hyphen and underscore, and only if it is free. This is not cosmetic. The id is the fingerprint seed, so a profile moved to another machine has to carry it. Move the cookies without the id and you get a different computer holding the same logins, which is the worst combination available.

When you are signed in, the server issues the profile and its id, and the app adopts the answer. Things the server does not store come back from what you typed: notes, tags, kernel version, start URL, the proxy key file path and the local group. Every profile is stamped with fingerprint generation 4 at creation and keeps that generation for life.

profiles.json holds names, groups, proxies, kernels and login details for everything you own. It used to be overwritten in place, which meant a power cut mid-write left a truncated file. Tab memory made writes frequent, and a rare accident became an ordinary one. The write now goes to a neighbouring file, waits for the data to reach the disk, and only then renames, because a rename inside one filesystem is indivisible.

The file is written with owner-only permissions. Inside the app directory that changes little, since the directory itself is closed. It changes a lot the moment the file is copied out: into a backup, into a cloud folder, into a bug report. Permissions travel with the copy. This works on macOS and Linux; on Windows Node cannot reach the access lists, and the app says so in the source rather than claiming protection it does not have.

An unreadable file is not an empty one. A damaged profiles.json used to read as "no profiles", and the first write erased it for good. Now a copy is set aside next to it before anything can overwrite it, and the failure is reported rather than swallowed.

Login passwords and proxy passwords are sealed with the system keychain before they touch the disk. If the keychain cannot open them later, the sealed form is kept as it is and written back untouched. One keychain hiccup used to blank every password at once.

1. 1

   Write to a neighbour

   The new content goes into a temporary file next to the real one, created with owner-only permissions.

2. 2

   Force it to the disk

   fsync runs, and a real failure here (no space, disk gone, I/O error) aborts the whole write instead of being treated as harmless.

3. 3

   Rename over the original

   The rename is indivisible, so on disk you have either the whole old file or the whole new one.

4. 4

   Fix permissions and flush the directory

   Permissions are reapplied on every write, since they only apply at creation, and the directory itself is flushed so the new name survives a power cut.

A launch is a sequence of gates, and each one is there because skipping it caused a specific harm. The ceiling on open profiles is checked first, before a server lock is taken or an extension is unpacked, so nothing is spent on a profile that will not open.

The fingerprint is built by the same deterministic call that the start page uses, from the template, the profile id, the proxy exit geo and the engine version. It is serialised to JSON, encoded as base64, and passed as --armanos-fingerprint on the command line next to --user-data-dir. The engine substitutes the values inside itself, before any page script runs, so what the first script sees is already the profile's machine.

Two refusals in that sequence are deliberate and loud. A proxy that cannot be applied stops the launch, because going direct would show the site your real address. A profile whose protection extension could not be written stops too, since a window with no tracker blocking and no page-level cover looks normal and is not.

1. 1

   Ceiling and seat

   The open count is compared to the limit and the seat is taken in one synchronous step, with no await between them, so eight parallel launches cannot all see the same zero.

2. 2

   Proxy and generation checks

   A proxy that cannot be applied refuses the launch. A profile created by a newer fingerprint generation than this build understands refuses too, rather than inventing a different machine.

3. 3

   Busy lock

   The server is asked to mark the profile busy before the window opens, so a colleague cannot open the same account from another machine at the same time.

4. 4

   Session and exit

   If a shared folder is configured, a newer session is pulled in before the engine reads its databases. If the profile asks for a fresh IP, rotation runs, and a failed rotation stops the launch.

5. 5

   Geo, extensions, protection

   The exit country sets timezone and languages, enabled extensions resolve to folders, and the per-profile protection extension is written to disk.

6. 6

   Spawn

   The engine starts with --user-data-dir for this profile and --armanos-fingerprint carrying the seed.

There used to be no limit at all, and then there was a hardcoded 12. Both were wrong. Twelve browsers flatten a machine with 8 GB, while a machine with 64 GB refuses on the thirteenth for no reason. The ceiling is now computed: three gigabytes are reserved for the system and the app, and what remains is divided one gigabyte per browser, floored at 4 and capped at 32.

The floor exists because a product that will not open four profiles is pointless even on a weak laptop, and the first refusal reads as a breakage. The cap exists because past thirty-two the constraint is the processor and the network, and work at that scale belongs on a server. You can set your own number on the Engine screen; it is clamped to the same range, and zero means "work it out from this machine".

The limit is soft. It refuses to open one more, it never closes what is already open, and relaunching a profile that is already running is not refused. Seats are counted by intent rather than by live windows, because a window is only counted after a network round trip, and eight simultaneous launches all passed a limit of five.

A refusal carries a machine-readable flag, not just a translated sentence, because the error text exists in 22 languages and nothing should be parsing it. Bulk launches, flow runs and schedules read that flag and wait for a seat, polling every five seconds for up to half an hour, instead of marking the profile failed and dragging the next one down with it.

4 GB of RAM

4 profiles, the floor

8 GB

5 profiles

16 GB

13 profiles

32 GB

29 profiles

64 GB

32 profiles, the cap

Computed as total memory minus 3 GB, one gigabyte per browser, then clamped. Your own number overrides it inside the same range.

Delete moves a profile to the recycle bin. The record is marked with a deletion time, and the data stays exactly where it was. Trashed profiles drop out of every list and stop counting against your quota, but nothing on disk has been touched yet.

Restore puts it back. When you are signed in, the server re-checks the quota first and can refuse, and that refusal now aborts the local restore instead of showing a green message that the next sync quietly undoes. A profile deleted on another machine arrives in your bin marked as such, rather than vanishing, so its cookies and logins on this disk still have an owner and a way to be erased.

Purge is the second button and it is meant literally. The browser is stopped and waited for first, because erasing under a live process is how erasing fails while the record disappears anyway. Then the Electron partition is cleared, the engine directory is removed with retries for Windows file handles, and every leftover that mentions the profile goes with it.

The result of the erase is kept, not thrown away. If some part of it failed, you are told. A sentence like "this cannot be undone" is what someone leans on before selling a laptop or handing it to an employee.

• Browsing data

  The Electron partition (storage, cache, host resolver cache, auth cache) and the engine's own user data directory.

• Local choices

  Its extension selections, its schedules and its start page token.

• Records that outlive it

  Its name in the launch notifications, its counters in the statistics and its daily action tallies.

• The cloud copy

  The encrypted session bundle in the shared folder, so no second machine can bring the profile back after you erased it.

The plan decides how many profiles you may hold at once. Free gives 2. Professional runs from 10 to 100 in four steps. Business runs from 200 to 1000. Enterprise starts at 5000 and is arranged by conversation rather than by a button. Extra profiles beyond a tier cost $2 each per month and are added to the tier price, not swapped for it. A team seat beyond the ones included costs $3 per month. Quarterly billing takes 10 percent off, annual takes 20 percent.

The app checks the quota locally as a mirror, and the server checks it for real. Ask for one more profile than the plan allows and the create fails with the plan name and the number in it, plus a notification you can see later. Trashed profiles do not count. A temporary profile does count while its window is open, which is why it is removed the moment the window closes.

Launches are gated too, not only creates. A plan that shrank used to leave two hundred profiles openable forever, so the server now answers a launch with a refusal when the open count exceeds what is paid for, and separately when access to that specific profile is closed. Both are shown as the server's own reason rather than as a generic error.

Offline, the rules stay honest in both directions. Within 24 hours of the last successful server check you can still create profiles locally, and they are kept and reported as not yet synced rather than deleted on the next login. Past that window the create refuses. A subscription that expired keeps its plan for a 3 day renewal grace before it drops to Free.

An ordinary browser separates profiles for convenience, not for concealment. Cookies are kept apart, and that is where it stops: the same screen, the same GPU, the same fonts, the same canvas, the same address. Anything reading more than cookies sees one machine wearing several hats. Container tabs are the same trade in a smaller box.

Incognito is not separation at all, it is forgetting. It throws data away when you close it, which makes every session look brand new, and a brand new session with an old machine underneath is its own signal. A VPN moves the address and touches nothing else. A virtual machine really does separate everything, at the cost of tens of gigabytes and minutes per identity, and it still reports itself as a virtual machine.

A spoofing extension works from the wrong side of the wall. It patches page objects from a page script, so what it changes and how it changes it are both visible to any script that looks first or looks twice. ARMANOS substitutes the values inside the engine, from a seed passed on the command line, which is why the fingerprint page is worth reading before you trust it.

What an ARMANOS profile adds is that all of it belongs to the profile at once: the storage, the exit, the claimed machine, the extensions and the daily limits. You are not assembling four tools per account and hoping they agree.