Selenium

It is the oldest of the three common roads and the one most existing test suites are written in. Here it can take over a profile the app has opened, and the pieces you have to bring yourself are named below.

Selenium is an open toolset that drives browsers through WebDriver, a standard command set served by a separate driver program.

What sits underneath it

Your script does not talk to the browser. It talks to a small driver program, and that program talks to the browser in whatever way that browser needs.

A driver process in the middle
One program stands between the script and the window and translates each command into what the browser understands.
Many languages, one command set
Java, Python, C sharp, Ruby and JavaScript all send the same commands, which is why so many old suites are written here.
A published standard
The command set is a web standard rather than one maker's channel, so the same script reaches browsers from different makers.

Attaching it to a profile here

The app opens the profile and answers with the port its control channel is listening on. A driver pointed at a listening address takes over that window instead of starting a browser of its own.

1
Switch the local interface on
It stays off until you switch it on in the app, and the screen then shows the address and the token.
2
Start the profile and read the port
The answer carries the port number, and on the main engine that port belongs to one profile only.
3
Point the driver at that address
The driver is told to use an existing debugging address rather than to launch anything for itself.

Your browser right now

These are read in the browser you are reading this in. The first row carries the name of this very protocol, and almost every bot check reads it first.

Ihr Gerät, jetzt gerade

Automation flag: wird auf Ihrem Gerät gemessen
User agent: wird auf Ihrem Gerät gemessen
Platform: wird auf Ihrem Gerät gemessen

In Ihrem Browser gelesen und hier angezeigt. Nichts wird irgendwohin gesendet.

What you bring yourself

This road needs pieces that nothing here installs. Naming them is more useful than a promise of support that would fall apart on the first run.

The driver program
You download it and keep it current, and the app neither ships it nor checks that you have it.
The version match
A driver built for a different browser release will not talk to this one, so its version has to follow the engine.
The wiring itself
The worked examples that ship are written for the libraries that speak the channel directly, so this one you assemble.

The automation flag and this road

A browser started by a driver normally announces that it is being automated, and that single value ends a check before anything else is read.

A profile here is started by the app instead, with launch arguments that clear the flag, and attaching afterwards does not put it back.

Behaviour is still read separately

A clear flag says nothing about how the run moves. Straight pointer paths, identical pauses and inhuman speed are signals of their own, and no launch argument touches any of them.

Often confused with

The flag that carries its name
The value a page reads is named after this protocol, but the other road sets it too. The name is history rather than a maker.
Puppeteer
That library speaks the browser's own channel with no driver in between, and it attaches straight to the profile address.
A cloud grid
A grid spreads a suite across many machines. What runs on each of them is still one driver and one browser.

What this does not do

It does not arrive with ARMANOS. No driver program ships in the app, nothing here downloads one, and nothing checks which version you have.
It does not open our engine with your profile. A driver left to start its own browser gets a plain one, without the fingerprint, the proxy or the cookies that make a profile.
It has no worked example in the app. The examples that ship connect over the channel directly, and this road you build from the port in the answer.
It does not reach a profile that is closed. The port opens with the window and is gone with it, so a suite asks for a fresh one at every start.

Check it

Each line above is a file you can open and a stand that holds it.

The launch arguments every profile gets, including the one clearing the flag: apps/desktop/src/lib/forkEngine.js
The automation flag is read from a real page in the real engine: apps/desktop/test/webdriver-flag.js
The start route, the port it answers with and the gate in front of it: apps/desktop/src/lib/local-api.js · apps/desktop/test/local-api-gate.js
Where a profile publishes the port it is listening on: apps/desktop/src/lib/forkPage.js

Questions

Can it drive a profile here at all?: Attaching to an open profile works, because the answer to a start carries the port that profile listens on. What is missing is a driver program and an example written for this road.
Why does the answer carry a port and not only a socket address?: Because this road wants a host and a port, while the other libraries want the socket address. Both are in the same answer, so either can be used.
Can I let the driver start the browser itself?: You can, and you would get a plain browser rather than your profile. Everything that makes a profile is applied by the app at launch.
Does attaching set the automation flag?: Not by itself. The value is cleared by the launch arguments the app assembles, and those are the same whoever drives the window afterwards.
Which version of the driver do I need?: The one matching the Chromium release our engine is built from, which is named on the engine page. A mismatched driver fails at connect rather than quietly, which is the better of the two outcomes.

Next to this

Take over a real profile from your suite

Switch the local interface on, start a profile from code, and hand the port to a driver you already have.

Download ARMANOS Local API