Your idea of "dumping the rendered window pixels out to a simple viewer" with Chromium is essentially Remote Browser Isolation (RBI). If you're looking for a packaged way to do this, BrowserBox does exactly this and has a tor-run function built-in, which:
replyconnects Chrome to a Tor SOCKS proxy and wraps all other browsing-related network calls over torsocks. It prevents local fingerprinting leaks (like this IndexedDB ordering bug) because the browser isn't running locally at all. You can host the BrowserBox instance as an onion hidden service, use it to browse over Tor, or both.
If you want to try an ephemeral "VPC in a box" style setup where the environment is destroyed after you're done, you can easily spin it up using this new GitHub action: https://github.com/marketplace/actions/browserbox (but you need a license key, obtainable at https://browserbox.io)
This is my attempt to make it easy to spin up bbx on ephemeral infrastructure that's mostly free (GitHub Actions runners are perfect).
That's great, I'll give it a try.
replyLinks can force to pass all connections to a proxy, so a FW might be redundant. Forget almost mouse, Links can be render the page either to plain X11 or a terminal.
replyI'm assuming the browser is going to be compromised at some point, for example by getting it to retrieve something without using the socks proxy.
reply