I built an AI "web harness" running on a sandboxed Chromium (using a custom side-loaded plugin that talks over websockets to a "driver") to basically do anything a normal user could do in a browser. It totally bypasses any and all bot measures and only gets the ones you yourself would get as well (and passes those successfully, e.g. Cloudflare checkbox or those annoying OCR puzzles).
Not sure if I should release it, but I'm sure more people are catching onto the power of agentic browsing.
It is, because `--remote-debugging-port` is detected via the root DOM object (and that can't be changed unless you want to recompile Chromium), so for example, if you try doing a Google search with debugging enabled, you'll get blocked (usually just by being served a blank page).
Does remote debugging port itself get detected, or does the presence of a webdriver connection to the port get detected? I believe it's the latter.
I've had success launching the browser and using dumb dumb methods to get around the captcha before attaching playwright.
Dumb dumb methods = wmctrl, xdotool, bash (work fine for Cloudflare's "are you human" check)
I think it's the latter, and that's why I think using a "normal" non-debug browser is the best idea because it's essentially undetectable. And for the record, you can technically control Chromium using IPC if you feel like adding that feature & fully rebuilding it from scratch.
dvt · · focus · HN ↗
Not sure if I should release it, but I'm sure more people are catching onto the power of agentic browsing.
onion2k · · focus · HN ↗
Is that necessary? You could start Chromium with an open debug port and use Chrome Devtools Protocol to send commands.
dvt · · focus · HN ↗
raffraffraff · · focus · HN ↗
I've had success launching the browser and using dumb dumb methods to get around the captcha before attaching playwright.
Dumb dumb methods = wmctrl, xdotool, bash (work fine for Cloudflare's "are you human" check)
dvt · · focus · HN ↗