ARMANOS

Start page

The start page every profile opens on

Before a profile reaches the site you wanted, it opens one page built on your own computer. It shows the address a site will see, the proxy it travels through, the engine, its version and the whole fingerprint.
First, before the site
Opens
On your computer
Assembled
One: the address lookup
Requests out
22
Languages

A profile opens its own page before it opens a site

You launch a profile and ARMANOS puts one page in front of the destination. It is generated on your machine and describes the identity this profile is about to wear.

On ARMANOS Browser the start page is tab one and the site is tab two. Tabs you agreed to restore after a crash come after both, in the order you left them.

The built-in engine has no tab strip. There the start page takes the profile window, the site opens as a second window on the same partition, and the page is raised back to the front.

The destination is the profile's own start URL when you set one. When you did not, it is the address of the profile's use case.

  1. 1

    Tab one: the start page

    Registered for this launch under a fresh token and served by the local server inside the app.

  2. 2

    Tab two: your destination

    The profile's own start URL, or the address of its use case when it has none.

  3. 3

    Then the restored tabs

    Only what you agreed to bring back after a crash, in the order you left them.

  4. 4

    Headless: no start page

    A windowless launch opens one address. Nobody is there to read the page, and the engine refuses several targets without a window.

The ARMANOS start page: exit address with country and city, proxy summary, profile card and engine card
The start page of a desktop profile. The app was set to Russian, so the page is Russian: its labels come from the same 22 dictionaries as the app.

The banner says whether the proxy is really carrying you

The largest thing on the page is the address a site would see. Under it sit the country, the region, the city and the owner of that address.

An address on its own proves nothing unless you know your own by heart. So the page compares. The app asks for your real address once when it starts, outside the profile proxy, and keeps the answer for an hour.

That gives three plain outcomes: the profile has no proxy, so sites see your own address; the exit address equals your own, so the proxy is not working; the exit address differs, so sites see it and not you.

When your own address could not be learned, there is no verdict at all. An invented "all good" is worse than silence, because people believe it and go to work through a dead proxy.

Profile has no proxy
Sites see your own address
Exit address equals yours
The proxy is not working right now
Exit address differs from yours
Sites see this address, not yours
Your own address unknown
No verdict, only the exit address

The comparison runs inside the page, on values it already holds. Nothing about it is sent anywhere.

The page is assembled on your computer, and the profile never leaves it

A small HTTP server inside the app binds to 127.0.0.1 on a free port. Each launch registers the profile under a fresh random token, and the page lives at a path built from that token.

The token matters even on loopback: without it another program on the same machine could walk profile ids. Relaunching replaces the old token, and stopping, deleting or moving a profile revokes it.

Everything the page shows is injected into the document before the page's own script runs. Values are escaped, so no profile name, note or tag can end the script block early.

Some tools in this category fetch the same kind of page from their own server, with the profile id in the URL. Every launch is then announced to a third party. Here the document is written locally and read locally. One field is deliberately absent even so: the proxy password. The page is local, but it renders inside the profile browser, where an extension could read the DOM.

  • default-src 'none'

    Nothing loads from anywhere: no external styles, scripts, fonts or images, even if the template asked for one.

  • connect-src: five hosts

    The only network the page can perform is the address lookup, and only to the sources listed for it.

  • img-src data:

    Icons are inline, so there is no image request that could act as a beacon.

  • form-action and base-uri 'none', frame-ancestors 'none'

    Nothing to submit, nowhere to re-base, and no page may put this one in a frame.

  • no-store, no-referrer, nosniff

    Sent as real headers by the local server, not as promises written in the markup.

One request leaves the page, and it goes through the profile's proxy

The lookup runs in the profile's own browser, so it takes the same route as everything else in that profile. That is what makes the answer the exit address rather than yours.

Five sources are tried in order, six seconds each, once through. Four of them return geography; the last returns the address alone, so a total geo outage still shows where you come out.

Four geo sources are there for a reason. These services are free and therefore rate limited, and this product launches many profiles in a row from one machine. Each extra source is an independent quota.

The country name is produced by the browser itself from the two-letter code, in your language. A failed lookup clears everything: no stale address stays on screen and the copy button goes with it. The Try again button is the only way the lookup runs a second time.

SourceWhat comes back
ipwho.isAddress, country, region, city, connection provider
get.geojs.ioAddress, country, region, city, organisation
ipinfo.ioAddress, two-letter country, region, city, organisation
ipapi.coAddress, country, region, city, organisation
api.ipify.orgAddress only, tried last so an outage still shows the exit

Two cards name the profile and the engine that will render it

The left card is the profile: name, group, use case, profile id, proxy line, launch time, notes and tags. The proxy line repeats the type, host, port and country, with a key chip when that proxy has a login.

The right card is the engine, with a badge you can read across the room. It says either ARMANOS Browser or Built-in Chromium, and it prints the version as it is.

ARMANOS Browser reports 153.0.7978.0. The built-in engine is Electron's Chromium and it is more than twenty major versions behind, which is a signal on its own. Claiming a newer number would be worse, because feature detection would catch it.

The card also states where substitution happens: inside the engine on ARMANOS Browser, before any page script runs, and at page-script level on the built-in one. Reading this line is how you notice a launch fell back, before you spend an hour on a site.

Badge: ARMANOS Browser
Fingerprint substituted inside the engine, version 153.0.7978.0
Badge: Built-in Chromium
Substituted at page-script level, on a much older Chromium
Proxy row with a key chip
This proxy has a login, and the password is not on the page

The engine card is the fastest way to see that the fork was not installed or did not spawn, and the launch used the fallback.

The fingerprint card prints what a site would read

One card lists the identity in full: user agent, platform, screen with pixel ratio and colour depth, languages, locale, time zone, CPU cores, memory, touch points, WebGL vendor and renderer, and how many fonts the profile exposes.

These are not a second guess at the fingerprint. The launch and the page are handed the same object, derived from the profile seed at generation 4 and its template, so the two cannot disagree.

The templates are macos-chrome, windows-chrome, linux-chrome, android-chrome and android-tablet. The user agent row is the quickest way to see which one this profile is wearing right now.

  • User agent

    The full string on its own row, selectable, so you can paste it straight into a checker.

  • Screen

    Width by height, with the pixel ratio and the colour depth printed beside it.

  • Time zone, locale, languages

    The three values a site cross-checks against the country of your exit address.

  • WebGL vendor and renderer

    The two strings a graphics probe reads first when it wants to know your hardware.

  • Fonts

    How many faces the profile exposes, counted from the same list the engine is given.

The page speaks the language of the app

Every label is resolved once per launch and travels inside the payload, in all 22 languages. The font count follows the plural rules of the language, so nobody reads "1 fonts". Arabic turns the page right to left, and the browser tab carries the profile name, because a person with fifteen profiles open reads tabs.

The checkers are one click away and open as this profile

A row of five external checkers sits under the banner. They are the tools this audience already uses, and they are on the page so that looking costs one click instead of a copied URL.

They open inside the same profile, so they read this profile's fingerprint through this profile's proxy. On ARMANOS Browser the link opens a new tab; on the built-in engine, which has no tab strip, that window navigates to the checker.

Links are validated before they are made clickable. Only http and https survive; anything else is shown as plain text and never as a link.

A second row holds ten everyday sites. The same ten are written into the bookmarks bar of a new profile once, and only when the profile has no bookmarks file at all, so your own bookmarks are never touched.

  • BrowserScan

    A broad report over address and fingerprint in one pass.

  • BrowserLeaks

    Separate pages per interface: canvas, WebGL, fonts, WebRTC, one at a time.

  • CreepJS

    Looks for contradictions between values rather than just printing them.

  • Pixelscan

    Looks for the signs of a substituted browser.

  • IP2Location

    Where the exit address is placed, in the words of an address database.

On a phone profile the page checks the window against the profile

A phone is not proved by a small screen and five touch points. So the page measures the window it is actually in and compares that with what the profile claims.

Four disagreements are reported in a row called What sites see: the window is wider than the declared screen, the orientation contradicts the screen shape, there are no touch events, or the pointer is not a coarse one.

This came out of a measurement, not a guess. On the fork the first seconds gave a window 500 points wide against a declared 393, and the orientation stayed the host's. The numbers on the card were green while sites saw something else.

Mobile profiles also get a device model row. Five touch points and a 360 screen say nothing to a person, while a model name says everything about which phone you arrive as.

The start page of a phone profile, with an Android user agent in the fingerprint card
The same page for an Android profile. The user agent row reports Android and Mobile Safari, and the engine version stays 153.0.7978.0.

You can switch it off, and the same local server does two more jobs

The switch lives on the Engine screen, beside the engine choice, because that is the "what happens when a profile opens" screen. It is on by default and remembered in a small file in the app data folder.

Off means a profile opens straight on its site. The feature also steps aside quietly: if the local server cannot bind a port, launches carry on without the page instead of failing.

The same server also serves a blank page on loopback for the fingerprint self-test. Loopback counts as a secure context and about:blank does not, and four checks used to fail for that reason alone and drag the score down.

It also holds one address per profile that the protection extension of ARMANOS Browser posts its blocked counters to. It takes POST only, caps the body, and carries its own token, so counters keep working with the start page switched off.

  • The page itself

    One address per running profile, revoked when the profile stops, is deleted or moves to another machine.

  • The secure blank page

    Where the fingerprint self-test measures, so that values hidden outside a secure context are visible to it.

  • The counter inbox

    How the fork's protection extension reports blocked trackers back to the app, independent of the start page switch.

What this does not do

  • It reports what your own machine can measure. It is not a verdict on how any platform will treat the profile, and a green line is not a promise about anything.
  • The verdict needs your real address, learned once per app launch outside the proxy. If that request failed, the page shows the exit address and stays silent about it.
  • City and provider come from free public lookup services. Those fields are estimates, they can be missing or wrong, and a rate-limited source is skipped for the next one.
  • It is not a leak sweep. WebRTC, DNS and font enumeration are not measured here; the app's network diagnostics and the external checkers do that.
  • It shows a mismatch, it does not repair one. Changing the proxy, the template or the window size is still your move.

How to check

Every claim above is one file away, and most of them have a stand that fails when the behaviour changes.

The page is served only from 127.0.0.1, under a per-launch token, with a locked content policy
apps/desktop/src/lib/start-page.js
No verdict at all when your own address is unknown
apps/desktop/src/start/start.html · apps/desktop/test/leak-verdict.js
No label on the page can render as a raw key
apps/desktop/src/start/start.html · apps/desktop/test/подписи-стартовой.js
A phone profile is told when its window contradicts its own claims
apps/desktop/src/start/start.html · apps/desktop/test/mobile-window.js
The font count follows the plural rules of the language
apps/desktop/src/i18n/messages.js · apps/desktop/test/plural-agrees.js

Look before you go anywhere

The page costs three seconds at launch. It is the cheapest way to catch a dead proxy or a fallback engine before a site does.