What's new

ARMANOS is one app with a browser inside it. The app is version 0.1.0. The browser is ARMANOS Browser 153.0.7978.0, a Chromium build we compile ourselves, with the fingerprint work applied to the source rather than to the page.

Neither number is written into this page by hand. The app version lives in apps/desktop/package.json, and the publishing script reads it from there. The engine version is declared in packages/shared/src/index.js as ARMANOS_BROWSER_VERSION, and every screen that names it reads that constant.

A check opens whichever engine binary sits in apps/desktop/engines for a platform, reads the version and the product name straight out of it without running it, and fails when either disagrees. Two more places say the version aloud: the MCP server the app ships for AI assistants, and the answer to --version on the command line. In both the number is written in, because after packaging there is no package.json beside them, so a separate check requires all of them to match.

App version

0.1.0

Engine

ARMANOS Browser 153.0.7978.0

Fallback engine

Chrome 130, the one inside the app

Fingerprint generation

4

Engine capabilities declared

9

Automated checks in the tree

2233: server 440, app 1602, site 191

Read from packages/shared/src/index.js, apps/desktop/package.json and the armanos-engine.json capability manifest that sits next to each compiled engine.

macOS gets two disk images, one for Apple Silicon and one for Intel, because an arm64 image does not open on an Intel Mac at all. Windows gets an installer and a portable build. Linux gets an AppImage and a tar.gz for people who unpack into /opt themselves.

The names are fixed, because the download page builds every link from them. A guard derives the expected list of files from the page itself, so a missing file makes the release stop instead of shipping five out of six. Checksums travel beside the files as SHA256SUMS.txt.

The sizes below are the ones printed under the buttons in all 22 languages. A check compares each of them with the real built file on disk, and says out loud when the files are absent instead of passing quietly. It exists because the page once promised 261 MB for a file that weighed 217: the number had stayed behind from an older build.

Two weeks of work sat on the build machine and reached nobody. The live site was from 20 August, the live server from 22 August, and all four download buttons answered 404, because publishing was manual and nobody called it. Most of this month's entries are about getting the compiled engine onto every platform and then out of the building.

Dates below are the day the work landed, not the day it was planned. Where a build and its verification happened on different days, both are named.

• 1 September 2026: the Linux builds were cut

  AppImage and tar.gz were produced and passed the packaging guard, on an engine compiled on 31 August. They were deliberately not offered for download: nothing had ever run them on a Linux machine.

• 2 September 2026: the Windows engine and both Windows builds

  The Windows engine is branded in the source tree before the build, so chrome.exe and chrome.dll carry ARMANOS Browser 153.0.7978.0 in their own version resources. The installer and the portable build were cut the same day on a Windows host.

• 5 September 2026: three reviews, and the money findings closed first

  The site was read along eight axes, 55 claims, 28 confirmed after two refutation passes each. Buying extra profiles used to rebuild a 1000 profile subscription into a 200 profile one, and the plan card showed a base of 200 to a customer who had a thousand. The server review confirmed 27 findings and closed 25, the app review confirmed 18 and closed all of them.

• 5 September 2026, 23:13: the Intel engine finished linking

  Linking had been starved of memory for three hours by other programs on the same machine. When they were closed the write phase started at once, and the engine was laid into apps/desktop/engines/mac-x64.

• 6 September 2026, night: both macOS images built and opened

  verify-build.sh mounted each image and found that day's code inside. The Intel build was then started under Rosetta on an Apple Silicon machine: five processes in fifteen seconds, window initialised without errors.

• 6 September 2026: every published build carries the compiled engine

  macOS on both chips, Windows x64 and Linux x64 now ship the browser inside the installer, and a fresh install selects it on first run.

• 6 September 2026, night: unsent edits are tracked field by field

  The mark that says an edit has not reached the server stopped being one flag for the whole profile and became a list of fields. What that fixes is described below.

• 6 September 2026: the download page got real build switchers

  Each card holds a radio group that works with keyboard and screen reader: Apple Silicon or Intel, installer or portable, AppImage or archive. One button leads exactly to the chosen build, and the extension and size under it follow the choice.

• 6 September 2026: Linux was checked by running it on Ubuntu

  A workflow on a clean Ubuntu 22.04 machine took the AppImage from the release and opened a profile with it. Only after that did the Linux card appear on the site.

• 6 September 2026: signing in on the site carries into the app

  A one time code, valid two minutes, opens armanos://login in the app, and the app finishes the login through the same path a typed password takes.

• 6 September 2026: the extension catalogue seeds itself

  Enable used to answer extension not found, because nobody had seeded the catalogue on the live server. The server now seeds it from the shared package at start and on demand, and Enable installs the files itself when they are missing.

• 6 September 2026, 13:27 and 14:03: installers, site and server published

  Six files went into the public release, then the site and the server were deployed with the standard script. The live site was looked at by eye at 1440 and 390, and all six links were requested from outside and checked for their real size.

Until September the app fell back to the built in engine unless someone went looking for the setting. Since 6 September every published build carries the compiled browser inside the installer, so on first run the app selects it. The built in engine stays the default only where no compiled one exists, and on a fresh install that no longer happens.

An explicit choice is never overridden after that. If you pick the built in engine it stays picked through updates. It also stays selectable on purpose: RPA Plus and the Synchronizer work on both engines, and the built in one is the fallback when the compiled browser cannot start. When that fallback happens, the app says so instead of quietly running something else.

Two guards stand between a broken engine and an installer. One refuses to package when the engine directory for the target architecture is empty, because the engine is not stored in the repository and an empty directory copies without a sound. The other refuses an engine older than the patch set: a build from July carries the same version number as a build from September, so a version check alone would have let it through, and the pixel reading work would have been missing with nothing to show for it.

The Linux builds existed since 1 September and were hidden on purpose. There is no Docker and no qemu on the build machine, so nothing had ever opened them. Offering a file when you do not know whether its window comes up is not a release, so the card on the download page was switched off and a check kept it that way.

The verification runs on a machine that is not ours: a workflow on Ubuntu 22.04 in the public downloads repository, started by hand. It pulls the AppImage from the release, so it tests exactly the file a customer receives, not a local build directory.

1. 1

   Download and unpack without FUSE

   The AppImage is taken from the release and extracted with --appimage-extract, with APPDIR set. The first attempt failed here on our own mistake: without APPDIR the path to the binary collapsed to /armanos.

2. 2

   Start under a virtual display

   The app is launched under xvfb with the local API switched on in advance, so the run can drive it without a person at the keyboard.

3. 3

   Create a profile and open it

   A profile on the linux-chrome template is created and started, which is the shortest path that touches the engine, the fingerprint and the window at once.

4. 4

   Read what actually answered

   The engine answered ARMANOS Browser 153.0.7978.0, the local API responded after 4 seconds, the window came up without errors, and the profile ran on processes under engines/armanos-browser/chrome with the namespace sandbox intact and no sandbox weakening flags.

Before September, signing in on the site and signing in inside the app were two separate acts with the same password. Now the site can hand the session over.

The site asks the server for a one time code on behalf of someone who is already signed in. The code is 24 random bytes, it lives two minutes, and it works once. The site then shows a panel that opens armanos://login with that code, and the app takes it from there.

The app registers the armanos scheme and finishes the login through the same path a typed password takes, taking the address from the server's answer. The second step of login is not asked again, because the code is only issued to an account that has already passed it. The exchange deletes the code before it checks the expiry, so a second attempt with the same link fails whether it is late or not.

• macOS

  The system delivers the link through the open-url event, whether the app was running or not.

• Windows and Linux

  The link arrives as an argument to a second instance, or to the first one when the app was not running at all.

• Either way

  The login is written to the history as coming through a handoff, so you can see later which route opened that session.

Here is what used to happen. You rename a profile with no connection. A colleague, on another machine, changes the proxy on the same profile. When you come back online, sync keeps your local copy of every field, and the catch up writes your stale proxy over their new one. Their edit disappears without a word, and nothing on either screen says so.

The mark that says an edit has not reached the server was one flag for the whole profile, and a profile has nine fields a person can edit. Now the mark holds a list of field names, and the list of editable fields lives in one place beside it, so the two cannot drift apart.

• Only what you touched is marked

  The difference is taken against the stored record before the write, because the editor window sends all nine fields on save and every one of them would otherwise count as touched. Objects and lists are compared by content, with ordered keys.

• Sync keeps only the dirty field local

  Neighbouring fields are taken from the server, so a colleague's change to a field you did not touch survives your reconnect.

• The catch up carries only the debt

  Pairs travel together, a proxy with its library link, a folder with its number. An empty request is not sent at all.

• The mark is set before sending, not after a refusal

  A field that changes while the request is in flight stays in debt, because the mark is cleared against a snapshot taken at the moment of sending.

• Old marks read as all fields

  A mark written by an earlier version means the whole profile is in debt, so an edit made on an older install is never dropped.

Everything below is true today. Each item is written down in the repository rather than only remembered, which is why we can list it here without softening it.

Three of the six are the owner's decisions and are deliberately last in the order of work: signing, notarization and the payment provider.

• The Windows installer is not signed

  Windows SmartScreen warns about it. The download page says so under the Windows card in all 22 languages, and tells you to choose More info and then Run anyway.

• The macOS images are not notarized

  They are signed with an Apple Development certificate, which Gatekeeper rejects on a machine that is not ours. The first launch needs System Settings, then Privacy and Security, then Open Anyway. Developer ID and notarization come at the end.

• The Windows build is from 2 September and misses three fixes

  The keychain prompt fix, the login handoff and the extension install path all landed on 6 September. The Windows installer can only be built on a Windows host, so those arrive with the next Windows build.

• Card payment is not connected

  The checkout is written, but it stays inert without keys, and the payment provider has not been chosen yet. Nothing on the site takes a card today, and plans are granted by hand until it does.

• The app does not fetch updates yet

  The update address in the packaging config is a placeholder. The app never checks by itself, and a check started from the Update Centre reports an error rather than up to date, because a failed check is not evidence of being current.

• Two engine gaps are written down, not hidden

  The automation bit that a debugging port sets is still cleared with a command line switch instead of inside the engine, and the macOS engine is branded after compiling rather than in the source tree. Both sit in engine/patches/PENDING.md with the measurement that found them.

The steps below are a script, not a habit. Almost every one of them exists because the manual version failed once and failed quietly.

The order matters. Verification happens on the built files, before anything is uploaded, and again from outside after the upload. A check that only reads the source tree would have passed on all the days when the shipped file was wrong.

1. 1

   Build

   npm run dist from apps/desktop produces the images and executables for the current host. Windows binaries need a Windows host, which is why Windows can lag the other two systems.

2. 2

   Look inside the built files

   verify-build.sh mounts each macOS image and reads the Windows build as it is, then searches both for markers of the code this build was made for. Yesterday's app inside today's installer looks identical from the outside.

3. 3

   Rename, checksum, copy

   publish-installers.sh reads the version from package.json rather than carrying its own copy, links each file under the name the site calls, writes SHA256SUMS.txt and copies the set into the site's public folder.

4. 4

   Assemble the update feed and verify it

   The feed files travel with the installers. For every line in a feed the script takes the file it names and recomputes its sha512 the way the app would. One mismatch stops the release, because a stale feed and a stale file agree with each other perfectly.

5. 5

   Publish to the release

   With the publish switch set, the files go into the public release and replace what was there. Each one is then requested from outside and checked for its real size, so a half finished upload cannot pass as done.

6. 6

   Deploy the site and the server

   Only through the standard deploy script. It refuses to run when a stray railway.json sits in the repository root: such a file once put the server image on the site and took the site down for eight minutes.

7. 7

   Wait for a new deployment number, not for a status

   An upload can fail to start at all, and then the first entry in the list is still the previous success. Polling the status would report SUCCESS about a two week old deployment.

8. 8

   Check from outside

   The server's health endpoint, the live pages by eye at 1440 and 390, and all six download links for their real size, before the word published is used.

The installers weigh about one and a half gigabytes together, so they are not in the source repository. A site built from the repository alone would have an empty downloads folder and six dead buttons, which is exactly what visitors met for two weeks in August.

So the address is passed into the site at build time, and the build fails when it is missing. That is deliberate: an error during a build costs minutes, a published site you cannot download from costs customers.

The same rule applies to the server address. It is compiled into the site, so changing it means rebuilding the site, otherwise the account area keeps knocking at the old place.