Up and running in three steps

What actually happens when a profile opens

The diagram above is the shape of it. Here is the sequence, because the details are where this differs from the tools it looks like from the outside.

Launching a profile starts a real browser process with its own data directory. Not a tab, not a container inside a shared browser -- a separate operating system process with its own memory, its own cookie jar, its own cache and its own storage. That is what makes the isolation genuine, and it is also why the practical ceiling on how many you run at once is your RAM rather than your plan: roughly five concurrent profiles per 4 GB with low-memory mode on. If a profile has a proxy, the address is resolved first and, where the proxy needs authentication or speaks SOCKS, bridged through a local endpoint so the browser sees a clean connection. The exit location is then looked up and used to derive the timezone and language, which is why those match the IP without you setting them by hand.

The fingerprint is applied in the engine, not injected

This is the part most worth understanding, because it is the difference that survives contact with a serious detector. There are two ways to change what a page sees. The common one is to inject JavaScript into every page that overrides the APIs -- redefine the canvas methods, swap the WebGL strings, patch the navigator object. It is far easier to build, and it leaves evidence: overridden functions whose source no longer looks native, timing differences, the ordering of properties, and above all gaps. A web worker or a cross-origin iframe frequently runs outside the injected context and cheerfully reports the machine underneath.

Dual Login takes the other route. The values are compiled into a signed, encrypted configuration file that the browser engine reads at startup and applies in its own C++ code paths, before any page script runs. There is no injected script to detect, because there is no injected script -- the engine simply reports different values, the way a different computer would. The practical consequences are that the fingerprint holds in workers and iframes, that there is no per-page injection cost, and that there is nothing for a detector to catch in the act. The configuration is bound to the profile’s own directory, so it cannot be copied to another profile to clone an identity.

Why automation does not announce itself

The usual way to drive a browser leaves a mark. WebDriver sets navigator.webdriver to true and adds artefacts that any script can read; attaching a debugger and holding the connection open is itself a signal. Dual Login’s default launch attaches nothing: the browser starts as an ordinary process with no automation flags, which is what lets profiles pass the sign-in flows that reject automated sessions outright. When you drive a profile, clicks and keystrokes are issued as trusted input events at the protocol level rather than dispatched from page JavaScript -- the difference between a click a site treats as a person and one it can tell was synthesised.

The same care applies to what is deliberately never called. Enabling the runtime evaluation domain is one of the loudest things an automated session can do, so the driving path does not use it at all; the three actions that genuinely require it are opt-in and flagged as such. You can drive profiles over CDP or over plain HTTP, with no driver to install, which matters because most automation in this field is not written in a browser-automation language -- it is a script or a job runner that can make a request.

How a login survives moving between machines

A session lives in cookies and local storage, so those are captured while a profile runs and again when it closes -- read from the browser directly rather than scraped from files. That is what makes a login portable: the same profile opened on a second computer arrives with the session intact rather than at a sign-in screen. Two rules keep this honest across machines. A profile checks for a newer copy before it opens, so you never browse on a session another PC has already replaced; and an empty session is never pushed over a good one, which is the failure that silently destroys logins in tools that treat every write as authoritative.

Why profiles cost memory

It is a fair question why each profile needs a whole browser process when a browser already supports several profiles of its own. The answer is that Chrome’s profiles separate storage and nothing else -- same process, same engine, same reported device -- so they solve the cookie problem and none of the rest. Giving each identity its own process is what makes it possible to report a different machine per profile, because the fingerprint values are set when the engine starts. The cost is real, about five concurrent profiles per 4 GB, and it buys the only version of this that a detector cannot see through.

What this does not do

It is worth being direct about the boundary. All of the above addresses the device layer, and the device layer is one input among several. Platforms also weigh IP reputation, account age, payment instruments, phone numbers, content and behaviour -- and behaviour is the one that most often undoes good technical work. Twenty accounts created in an hour from one machine, following identical click paths at identical intervals, describe a single operator no matter how convincing each fingerprint is. The tool gives you separation; the pacing is yours.