Security and trust

Cookies, local storage, saved logins and the browser's own databases live in the profile directory on your machine. Nothing there is uploaded by itself.

You can open that directory yourself: ~/Library/Application Support/@armanos/desktop on macOS, %APPDATA%\@armanos\desktop on Windows, ~/.config/@armanos/desktop on Linux.

On Windows the system seals the passwords in the app's own files with a key tied to your Windows account. On macOS they are sealed with a key that ships inside the program, and on Linux they are written as typed, so on both this does not protect against anyone who can read your user folder. Nothing on screen says so.

A key that ships inside a program is available to anyone who downloads it, and the macOS seal rests on exactly such a key.

While you are signed in, profile settings are mirrored so a second machine and your teammates see one list: name, group, scenario, template and generation, proxy, tags and notes.

What is absent matters more. Cookies never leave, nor the profile's login pair, nor its one time code key, nor a byte of the browser's databases.

The fingerprint is stored nowhere at all: it is derived at launch.

• Your email and a hash of your password

  The plain password is nowhere. Changing it signs out every other device at once and revokes your API keys.

• Your machines

  Name, system, last seen. Unlinking is remembered, so a machine cannot register itself again.

• The history of your workspace

  A new machine records the address it came from.

• One sync row per profile and machine

  When a session last went out or came in. No file names, no contents.

• Plan, status and renewal date

  Card details never reach our database.

• A profile transfer to another account

  The request and a random key to the transfer file, sealed with our key, until the recipient places the file and for 7 days after accepting at most. You send the file with the session to the recipient yourself, past the server.

Cookies stay on the machine, so a second computer would mean logging into thirty accounts again. On the Engine screen, in Sessions on two computers, through a folder, you point the app at a folder something already synchronises, and one encrypted file per profile lands there.

The archive is encrypted with AES-256-GCM, and the key is stretched from your passphrase by scrypt with N=32768, r=8, p=1. The passphrase never enters the folder.

1. 1

   The profile closes

   The app waits four seconds and checks it is still closed, because Chromium keeps writing.

2. 2

   The archive is written next door

   It is renamed into place, so half a file never lands on a session that worked.

3. 3

   A meta file records size and time

   A bundle still downloading counts as not ready.

4. 4

   The second machine pulls before launch

   Same profile id, same fingerprint, and the cookies that came with it.

5. 5

   Both sides changed? Nothing is touched.

   Two machines worked in parallel, and the app lets you choose.

Two people on a team can reach for one profile at the same moment, and a site then sees one account live from two machines. That is the exact behaviour accounts get blocked for.

So the lock lives on the server, because two machines cannot see each other. It is held by time, so a machine unplugged from the wall frees its profile on its own.

Your password is stored as a bcrypt hash at cost 10 and never in plain form. Ten wrong attempts close the account for 15 minutes, and the same counter covers the second step.

The arithmetic of the second step is written here rather than taken from a library, because a library on the road to your password updates itself one day.

The password closes actions in ARMANOS. It does not encrypt the profile on disk.

Before a closed profile is opened, edited, exported, sent to the sync folder, deleted, copied or shared, the app, the Dashboard and the local API ask for it. Our server keeps a scrypt hash, not the password, and the pass it hands out after a correct password is signed with its own key and lives 15 minutes.

The owner and admins of your workspace can reset it, and the reset is logged. Three wrong passwords in a row close the profile for an hour for the person who typed them, not for the whole team.

A command line is readable by every process running under your account, and residential traffic is bought by the gigabyte. So the password never goes there.

A small bridge runs on 127.0.0.1 instead: it speaks to the browser without a password and to your proxy with one. Measured on the shipped 153.0.7978.0 build: a login inside the proxy address makes zero requests, the same proxy behind the bridge makes 13.

The bridge takes connections from loopback alone and asks for a one time pass from the profile's own extension.

The proxy rule covers every scheme, and WebRTC is closed at launch unless a profile is set to the Real mode; an extension with the privacy permission can reopen it. The leak tool here shows the addresses this browser hands out; whether WebRTC goes past the proxy, the app measures in Network > Run diagnostics.

The app can be driven by scripts through the local API over HTTP. It is off until you switch on Enable local API on the For developers screen, binds to 127.0.0.1 only, and every call except status carries the access token from that screen.

Loopback alone is not enough: a page you visit reaches 127.0.0.1 from your own browser, and under a rebound name it reads the answers as same origin. So a request with browser-only headers or a foreign host is refused.

Measured on this engine: opening the debugging port sets navigator.webdriver true, and the launch flag clears it.

There is no analytics in the app and none on this site. No tag manager, no session recorder, no crash reporter phoning home, no foreign script.

A problem report is assembled locally and goes nowhere until you press send. Anything that looks like a secret is removed by field name, and the name stays so you see it was there.

• The exit country check

  A public address service over HTTPS, through that profile's own proxy.

• The engine feed

  Update checks over HTTPS, installed only when the checksum matches.

• Our own server

  Profile settings, entitlement, team and support, while you are signed in.

• Support, once you press send

  Your message travels with the scrubbed report.

The free tools here measure inside your browser and make no requests. The site is served with the doors closed, and the headers below go out on every response.

Deleting a profile stops its browser first. A running Chromium keeps writing into a directory that no longer has an owner, and on Windows a live process holds its files open.

Then everything keyed to that profile goes with it: the browser directory, its extensions, its schedules, its counters and the launch entries in the notification file.

The Delete permanently button in the recycle bin clears the encrypted archive from your folder too, so no second machine brings the profile back.