This is built using (ah, obviously) headless Chrome. I think a "Live Puppeteer" demo might be more suited for this HN audience, where we have, LHS a code editor to enter a puppeteer script, and RHS, a BrowserView where you can interact with it like a normal browser, and drive it with puppeteer.<p>Under the hood, I don't use puppeteer, nor chrome-remote-interface, I actually use the raw ToT (tip of tree) DevTools protocol over secure websocket with some helpers to send commands, and receive responses and events. The reason to not use puppeteer is because it is missing some functionalities that are useful for "virtualizing" a browser like this, such as book-keeping of JS execution contexts (isolated worlds) and sessions (connections to a tab), and it was easier to create my own API that mapped 1-to-1 with my requirements atop the raw protocol, rather than build my API atop someone else's API atop the raw protocol. Also earlier on there were times when puppeteer didn't keep up to date with the latest ToT methods which were useful such as "flat session mode" (the ability to send a command to a particular tab just by including the sessionId).<p>Even tho I don't use pptr to build this, you can still use pptr to connect to the debugging port of the remote headless browser. However, not in the demo I am making available, for the simple reason that, 1) such connections have no authentication, and 2) exposing them to the internet means you could connect to someone else's browser, breaking privacy and security. These blocks are affected using IPTABLES and other blocks are effected on the cloud provider (GCP) level using firewall rules. The browsers are also blocked from accessing local files via file URLs.<p>I originally made this as part of a "repetitive task" automation product, but realized that "remote browser isolation" is actually a thing, so I'm trying to monetize this as a product in itself. There are a LOT of competitors: Symantec, Cloudflare/S2 (who use a really cool way to save bandwidth and maintain security by transferring not pixels but vector draw instructions from the chrome render engine), Webgap, McAfee/LightPoint, Ericom. I'm hoping that by having an open source product, that's relatively solid (tho by no means the lowest bandwidth (compared to S2/CF), and by no means has the status of a product backed by an existing security company (Symantec), or by experts in this field (LightPoint, WebGap, Ericom)), well I'm hoping that I'll be able to get some customers. I do think open source can work here.<p>But maybe in the end using this for security will be too hard to compete against the incumbents, and it will serve better as a robust part of my original idea of repetitive task automation (RPA for web apps).<p>That's some of the story of development. It's around 35K SLOC, all by me, took around just over 1 year full time, and I learned a lot, and got some GitHub starrs. Yay. Code is at:<p><a href="https://github.com/dosyago/BrowserGap" rel="nofollow">https://github.com/dosyago/BrowserGap</a><p>You can't use it for free if you're a for profit, but you can if you are government or not-for-profit. In the former case I aim to sell per seat, or per site licenses, and also charge for install and maintain. And in the latter, aim to only charge for install and maintain. What's the point of taxing the public purse more? Sometimes I doubt I can compete with products of competitors (especially capturing the vector draw instructions, tho theoretically that should be possible to implement like S2 did), and my aim is mostly to have a fairly familiar and easy to use browser experience.