Why the server attaches to your browser

The refusal that started it

Diwall, the project this one descends from, drives a headless Chromium. On some public sites it was refused access, down to reading an article, because the site took it for a robot.

The decision

This server does not start a browser to drive. It attaches, through the Chrome DevTools Protocol, to a browser you started on a profile dedicated to it, and you signed in to your sites there yourself. The model receives the image and the accessibility tree you would see in that browser (Architecture, two layers). The server does not start or close the browser; the setup assistant does, when you ask it to (operator guide, section 8).

What the attachment checks

• The debugging port is on loopback. At each attachment the server reads /proc/net and attaches only if every socket on that port listens on loopback; otherwise it refuses (debug_endpoint_not_loopback) (Architecture, safeguards).
• The profile is not your usual one. The server refuses the browser’s default profile. Chrome 136 and later ignore the debugging port on the default profile, which is one more reason for a profile of its own; the project did not measure that behaviour (operator guide, section 3).
• The profile sits in the encrypted directory. The sessions you signed in to are kept there, and the browser can be started on that profile only once the directory is open (same section).
• Only its own tabs. The server lists and drives the tabs it opened and the windows their pages opened, never the tabs you opened yourself (operator guide, section 8).

What it costs

• You start the browser yourself, with a debugging port and the profile of the encrypted directory, or you let the setup assistant do it; it must be a browser of the Chromium family (operator guide, section 3).
• You sign in once to each site in that browser.
• While the server is attached, that browser refuses every download, in your own tabs too, except around one of the server’s clicks or Enter keys (operator guide, section 12).
• The server’s tabs stay open when it stops; the next run can close them, not work in them (operator guide, section 8).

What it does not change

The conditions of each site stay those of its operator. The server is not a way around them: it acts in your session, after your confirmation for the actions it locks, and you answer for what is done there. The sites the model may read are the ones of your list, as the origin policy of your profile sets it (The operator profile).