Compare

Running a profile with nobody there

A profile can be driven by a program instead of a person. Two things decide how far that gets: what you aim at the browser, and what it says about being driven.

Two ways to aim a program at a browser

One way comes from outside. A library attaches over the browser's debugging protocol and sends commands, the way known automation toolkits work.

The other comes from inside. The app holds an ordered list of steps and runs them in a profile it opened itself.

Eight ways under a program

Read the rows as approaches rather than as product names. The last row is ours, and every cell in it came from the code.

Where an approach has nothing to say on a column, the cell says so. A blank is better than an invented answer.

Approach	What drives it	Many accounts at once	The automation tell	Nobody at the keyboard
An ordinary browser as it comes	An outside library over the debugging protocol	One identity for every window	The open channel announces automation	Your own scheduler
Incognito mode	Not its job	One identity for every window	Belongs to the browser, not the mode	Not its job
Separate profiles of the same browser	An outside library aimed at a data directory	Separate cookie jars, one device	The open channel announces automation	Your own scheduler
An extension that rewrites page values	Not its job	One identity for every tab	Cannot undo the browser's own flag	Not its job
A VPN	Not its job	One exit for everything	Not its job	Not its job
A virtual machine per account	A library inside each guest	As many guests as the host boots	As the guest's library leaves it	The guest system's scheduler
Separate hardware per account	A library per machine, or a person	One account per device	As that machine's library leaves it	Per machine, if at all
A browser with the engine itself changed	Steps in the app, or your code over a loopback port	A queue sized to the open window limit	The channel is open, the flag is put back off	A schedule while the app is open

One flag against a whole fingerprint

Opening the debugging channel makes Chromium set a flag saying this browser is driven. It is the first line of every bot check, and that one boolean outweighs everything a fingerprint gets right.

So on the ARMANOS Browser the channel stays and the announcement does not. A launch argument puts the flag back off, and a stand reads the value off a real page.

An endpoint per profile on the ARMANOS Browser
That address lives on loopback and only while the profile is open. The built in engine opens one shared port for the whole app, and only with the local interface on.
The noisy domain stays off
The protocol domain that installs hooks a page can notice is never switched on, and a flow needs none of it.
Readiness is asked, not subscribed to
The page is polled about its own state instead of reporting lifecycle events.

What drives a profile here

You add a step from a form: pick the kind, fill the fields, save. There is no recorder: the synchronizer follows a lead window to repeat it live, not to save a flow.

Any text field of a step can carry a name in braces, replaced per profile as the run reaches it. That is how one flow signs into a whole folder of accounts.

Pages and waiting
Open an address, wait for a time or an element, scroll, press a key.
Filling and reading
Type into a field, read a value into a variable, take a screenshot.
Order and branching
Repeat a body, walk a list, take one side of a condition, work across tabs.
Cookies and your own code
Read or clear cookies, run your own JavaScript under a time limit, wait for a request.

What still reads as a machine

A flow repeats what you wrote at the pauses you set, and one rhythm across every account is a pattern of its own. Warm up pauses and scroll distances come from a range for that reason.

It cannot answer a question meant for a person. There is no captcha solving here and no model deciding what to click.

A selector is a guess about a page
A site that changes its layout breaks the step pointing at it.
A failed step does not end the run
It is logged with its error and the next one is tried, and the run ends marked failed.
A new profile is a signal by itself
The warm up robot browses ordinary public sites first, so the jar is not empty at the first login.

When nobody is at the keyboard

A schedule belongs to a flow and names the profiles, the time and how many run at once. Times are local, so after a clock change nine in the morning is still nine.

A missed run is counted and never replayed in a burst. Three days of skipped warm ups arriving together is the spike a platform reads as a robot.

What this comparison does not claim

There is no recorder. The synchronizer watches a lead window to repeat it live.
No captcha solving, no image recognition, no model in the loop. A site that asks a human question stops the flow there.
Schedules run only while the app is open. There is no background service, and a closed laptop misses its runs.
Leaving the noisy protocol domain off removes one signal. It is not a claim about detection in general.
Rows about the other approaches describe the approach in general. We publish nothing about any named product, because we cannot measure someone else's honestly.

How to check this

Each claim below names the file behind it, and the automation flag has a stand that launches the real engine.

The automation flag is read off a real page, on the real engine, with the real arguments: apps/desktop/src/lib/forkEngine.js · apps/desktop/test/webdriver-flag.js
The protocol domain a page could notice is never switched on for a run: apps/desktop/src/lib/cdp.js · apps/desktop/src/lib/forkPage.js
The unprotected app wide debugging port opens only for the built in engine: apps/desktop/src/main/main.js · apps/desktop/test/cdp-port-only-when-needed.js
A missed schedule is skipped rather than replayed: apps/desktop/src/lib/schedules.js · apps/desktop/test/schedule-runs.js
Warm up pauses come from a range: apps/desktop/src/lib/cookieRobot.js · apps/desktop/test/cookie-robot.js

Questions

Can I record a scenario by clicking through it?: No. The synchronizer follows a lead window to repeat it live, not to save a flow.
Does my own library bring the automation flag back?: On the ARMANOS Browser no: a launch argument puts the flag back off, and the endpoint your library attaches to is that profile's alone. The built in engine has neither.
How many profiles run at once?: You pick the width of the queue, and a run never starts more workers than this machine allows open. A worker that meets the limit waits for a slot.
What happens to a run that was missed?: It is counted as missed and skipped. Three days of skipped work done in one go is the burst platforms read as a robot.
Can a web page drive my profiles through the local port?: No. The interface answers programs and turns away anything shaped like a page, and the address it listens on is checked as well.

Try a flow on a free profile

The free plan runs the same engine as the paid ones, so a flow behaves there exactly as it will later.

Download ARMANOS How a launch works