Remote debugging ports and operator risk

Chrome DevTools Protocol is a remote control for a browser process. If a debugging port is listening, anything that can reach that port can read cookies, run JavaScript, and drive the page. MaskWright opens an ephemeral --remote-debugging-port so the app can apply a fingerprint, set cookies, inject localStorage, and optionally open a tab. That port is not a user automation API. This page is the risk of treating it like one.

Browser automation versus a real profile is the pillar. The rest of the cluster lives under Automation. Authorized accounts only. A debug port does not make a login yours.

What the product actually opens

On Chromium launch the command line includes a remote debugging port chosen for that process. The main app attaches over CDP for spoof, cookie import, localStorage import, and openCdpTab when a launch URL is set. The port is per launch. It is not documented for Playwright, Puppeteer, or Selenium. There is no export of a WebSocket URL in the UI. There is no official driver integration in the desktop code.

Unknown in the audit: whether an external tool on the same machine can attach to that ephemeral port. Possible, undocumented, unsupported. I will not publish a connect recipe. If you need a driver, use a browser you own for pages you own, not a work profile that holds someone else's ads login.

Firefox and Camoufox paths are not this CDP story. Do not assume the same port exists on a Firefox profile.

The port is a local operator risk even when we never document it. A leftover Node script, a "helpful" agent that scans for DevTools, or a malicious extension will treat an open port as an invitation.

What a listener can do

CDP can list targets, pull cookies, evaluate script, intercept requests, and take screenshots. That is the point of DevTools. It is also the point of a session theft. If the profile is logged into an authorized Business Manager, the port is a live key. Attaching a driver is sharing the cookies with a program.

I will not walk a proof of concept. The operator habit is simpler. Do not point a script at a work profile. Do not leave a second tool "just watching." Do not paste a ws://127.0.0.1 URL into a chat. Do not run an AI agent against a browser it does not own. Agents in a browser they do not own is the sibling.

--disable-blink-features=AutomationControlled and navigator.webdriver = false are for the page, not for the port. They do not lock CDP. They do not make a headed profile safe to drive. Keyboard timing packs will not either.

Operator risk is not a site score

People search this query looking for a stealth flag. The risk I care about is the operator's. A debug port on a work profile is how cookies leave the folder without an export dialog. It is how a contractor "helps" by attaching Puppeteer. It is how a captcha solver vendor gets a live session. Captcha solvers are not research. Official APIs versus UI bots is the rule for pages that already give you a feed.

Bulk start of selected profiles is a UI feature. It is not a reason to expose ports to a fleet script. Batch launch is not a farm. We will not ship window sync or RPA. That refusal exists so nobody treats the internal CDP as a productized driver.

The index profiles.json is encrypted at rest with AES-256-GCM. The live Chromium user-data directory is not. CDP reads the live process, not the encrypted index. Encryption at rest does not protect a running profile with a listener.

Habits that keep the port boring

Use the app to start and stop profiles. Do not add your own --remote-debugging-port on a shortcut so you can inspect. DevTools inside the launched window, opened by you, is a different act from a listening port advertised to the machine.

Keep research scripts in a different browser, on pages you own or that allow the collection. Do not reuse a brand login as a test bench.

If you find a port in Task Manager or a netstat listing and you did not mean to offer CDP to the world, stop the profile from the app. Do not "just firewall it" and keep driving. The habit you want is: the only client of that port is the launcher that opened it.

Automation ethics is the desk policy. Headed profiles are for hands. Drivers are for systems you own. Mixing them is how authorized work becomes an incident.

FAQ

Can I attach Playwright to a MaskWright profile? Not as a supported feature. There is no official driver integration. Do not treat the internal port as an API.

Does hiding webdriver lock the debug port? No. Those flags are for the page. CDP is still a remote control.

Is Firefox the same? No. This CDP story is Chromium. Do not assume a Firefox profile exposes the same port.

This page refuses a connect tutorial. Internal CDP is plumbing. If we ever ship a supported attach, it will be documented. Until then, treat a listening DevTools port on a work profile as a live key. Do not hand it out.