A proxy per profile

A profile in ARMANOS is a whole browser session of its own: its own cookies, its own storage, its own fingerprint. The proxy sits on that same record. Open two profiles side by side and each window leaves through a different address.

The connection belongs to the profile, not to the app. There is no global switch that quietly puts every window behind one address, and there is no per site routing either. One profile, one exit, for everything that window does.

Four kinds of connection are accepted. An unknown one is refused instead of quietly downgraded. That rule was written after a real fault: anything that was not socks5 or https used to become http, so a profile set to ssh://server:22 would have gone out on your real address while the window said it was proxied.

• HTTP

  The ordinary form most sellers deliver. The hop to the proxy is plain, everything past it is whatever the site uses.

• HTTPS

  The same thing, with TLS on the hop between the browser and the proxy itself.

• SOCKS5

  Carries any TCP connection. Hostnames are handed to the proxy rather than resolved on your machine, so the visited domain does not leak to your own resolver.

• SSH

  Not a proxy at all. A tunnel to a server you already have, turned into a real SOCKS5 on loopback before the browser ever sees it.

Proxies are bought in batches. Fifty lines from a seller should become fifty reusable entries in one paste, not fifty forms filled in by hand. The library takes the paste and reports what happened: how many were added, how many were already there, and the exact lines it could not read.

One address is stored once. A profile links to a library entry by id and also keeps its own copy of the connection. The copy is deliberate: a profile can never end up linked but proxyless, which would send that window out on your real address. Edit the entry and every profile following it is updated in the same save, and the dialog tells you how many that is before you press it.

The library rides in your account, so a second computer gets the same list. Rows are matched by their account id, not by address, because you edit addresses: changing a port must edit the row, not create a second one. An edit made offline outranks the server copy until the server accepts it, so a new password from your seller cannot be silently overwritten on the next sync.

The Proxy store next to it is a directory of 8 providers with regions and price hints. Placing an order there records a request so it can be followed up. No payment is taken, and nothing is delivered to your library automatically.

Almost every paid proxy comes with a login. The obvious way to hand it to a browser is the command line: --proxy-server=http://user:pass@host:port. That is wrong twice over.

First, the command line is readable by every process running as you, and residential traffic is sold by the gigabyte. Second, it does not work. Measured on the shipped engine: the plain form made 13 requests through the proxy, the form carrying the password made zero and loaded nothing.

So ARMANOS runs a small proxy of its own on loopback, one per open profile. The browser talks to it with no password at all. It talks to your real proxy with the login, speaking HTTP CONNECT or SOCKS5 with RFC 1929 authentication, whichever that proxy needs. The command line carries only http://127.0.0.1:port, and your password stays in the app's memory.

A loopback port is reachable by other programs on the same machine, so the bridge asks for a one time pass and answers 407 without it. The profile's protection extension supplies that pass, not you: it is a random string, valid for one launch, worth nothing outside it. If that extension could not be written to disk there is nobody to answer, so the pass is cancelled rather than leaving you with a dead window, and the app says so in its log. If the bridge cannot start at all, the launch is refused instead of pointing the browser at a proxy it cannot log in to.

--proxy-server=http://user:pass@host:port

0 requests, no page loaded

--proxy-server=http://127.0.0.1:port, bridge in front

13 requests through the proxy

Measured on the shipped ARMANOS Browser 153.0.7978.0. The credentialled form is rejected by the engine, so every profile on an authenticated proxy was simply dead before the bridge existed.

Two files hold proxy passwords: the library file and the profiles file. Owner only permissions stop the person sitting next to you. They do not stop a backup, a home folder synced to cloud storage, or another program running under your own account.

Both files seal the password with the operating system, through the macOS Keychain or DPAPI on Windows. Sealed values are written with an enc1: prefix and opened again on read. If the system cannot seal, ARMANOS writes as before and does not pretend otherwise. There is no fixed key in the source, because a key shipped inside the program would be decoration rather than protection.

In a shared account the ordinary proxy listing carries no passwords at all. A password is handed out at one endpoint, for one proxy, and that hand out is written to the audit log, so a departure actually means something. Pulling the whole library with passwords onto a machine needs the manager role.

Chromium takes proxy rules in two shapes, and one of them is a trap. Writing http=host:port means "use this proxy for http:// addresses", and only those. Measured with a fake proxy on loopback: the http request went through it, the https request was answered directly and the proxy never saw it.

Today almost everything real is https. So the window went out on your true address while the app showed the profile as proxied, which is the one thing this product exists to prevent. The address is now written as a single rule, and a single rule applies to every scheme.

WebRTC is the other way around a proxy, because it can open UDP of its own. Both engines are set to disable_non_proxied_udp: ARMANOS Browser gets it as a launch flag, the built in engine through the window's own setting. The app's leak check does not simply assert this. It opens a hidden window with the same setting and asks it for WebRTC candidates, the way a site would.

If a profile has a proxy that cannot be turned into a usable rule, the launch is refused with proxy_unusable. Opening the window on your real address would be worse than not opening it.

A timezone that disagrees with the IP is one of the first things a fraud check looks at. So the exit country is not decoration here: it decides the profile's clock and its language list.

The country comes from a probe made through the proxy itself, over TLS, asking up to four providers in turn. Four rather than one for a plain reason: a free endpoint starts answering 429 during a bulk launch, and one refusal must not be allowed to decide a profile's identity. The answer is cached on the profile and thrown away whenever the exit changes, including after a rotation.

A known country becomes a matching timezone and language stack. The list reaches the engine as --lang and --accept-lang, and the protection extension pins navigator.languages on top, because Chromium exposes only the primary language there.

If the probe cannot read a country at all, the profile still opens and you get a notice. Rewriting the fingerprint afterwards would be worse: the accounts already logged in would see a new computer.

Mobile proxies are bought precisely because the address changes. The seller gives you a link: fetch it and the modem takes a new address. ARMANOS keeps that link on the library row, so it stops living in your chat with the seller.

The request goes out directly, not through the proxy being rotated. Sending it down a channel that is restarting gets you a broken connection instead of an answer. Redirects are followed only to the same host, and the reply body is read up to a cap, so a large page cannot eat the whole timeout.

The address is measured before and again after a short pause, so the row shows the new exit rather than the old one. When the seller answered but the address did not change, the app says exactly that. Sellers apply their own rate limits, and reporting a change that did not happen would be a lie you would act on.

1. 1

   By hand

   Change IP on a library row. Before and after are both measured, so you see what actually happened rather than what was requested.

2. 2

   Before a launch

   A profile can ask for a fresh address every time it opens. If the change fails the profile does not open, because you asked for a new address exactly when the old one cannot be used. A profile already open is left alone: changing the exit under a live window would show a site an IP change mid session.

3. 3

   On a timer

   Set an interval on the profile, five minutes at the least. Only open profiles rotate, counted from the moment the window opened, and a failed attempt still records the time so a seller's change limit is not burned in an hour.

4. 4

   Round robin over a pool

   Spread a set of proxies across selected profiles. Profiles that are open are skipped and do not consume their turn, and the position in the circle is kept, so the next spread continues instead of dealing out the same thing again.

If you already have a server, you already have an exit, and it costs nothing extra. ARMANOS runs an ordinary ssh next to the profile with dynamic forwarding, which opens a real SOCKS5 on loopback. The browser is handed socks5://127.0.0.1:port and knows nothing about ssh at all, so no launch path has to change.

The password never touches the command line. ssh asks for it through SSH_ASKPASS, and the small answering script reads it from a named pipe inside an owner only folder. The pipe is removed the moment the tunnel is up, and its contents never exist as a file on disk. An encrypted key works the same way, because ssh asks for its passphrase by the same route.

Your own ssh files are left alone. ARMANOS keeps its own known_hosts inside the app's data and runs with -F /dev/null, so a ProxyJump or ProxyCommand in your personal config cannot send a profile somewhere you did not intend. Host names are stored unhashed on purpose: when a server key changes, one button can forget that host's line and only that line.

A broken tunnel looks alive, since the loopback port is open and pages simply stop loading. ServerAliveInterval makes the break visible, ARMANOS retries three times on the same port and then tells you plainly. The tunnel is torn down together with the profile, so closing a window does not leave a connection to your server open.

Checking runs the road a launch runs. A proxy with a login goes through the same loopback bridge, and an ssh entry raises a real tunnel first. That matters: while the check went its own way, a working paid SOCKS5 with a password always showed as broken and glowed red in the list, and the profile behind it got no exit country at all.

What comes back is the exit IP, the country and city, the timezone the provider reports, and the time to first response. That last number is first byte, not the whole provider walk. A provider answering 429 during a bulk check used to add its own timeout, and a healthy proxy read as twelve seconds.

The result is written on the row with its timestamp, so the list shows which entries are dead without retesting everything each time you open it. Check all walks the library and reports how many answered. The probe bridge and the probe tunnel are both torn down when the check ends, on success as well as failure, so nothing is left listening.

A check answers one narrow question: did this address answer just now, and from where. It tells you nothing about how any particular site rates that address, and nothing about the next hour.

• It can tell you

  The address is reachable, what IP and country it exits from, and how fast it answered at that moment.

• It cannot tell you

  Whether a platform considers that address clean, how many other people share it, or whether it will still answer this evening.