But that's the key thing about tails. You start it fresh every time from a clean usb stick or iso image.
It's more than a browser restart, it's a complete system wipe every time.
Tails is made on the premise that exactly this kind of trick will occur. Sometimes even persisting between browser restart. For that reason even the persistent storage is very limited. But that's optional and cautioned against for maximum anonymity.
What would be worrying with tails would be if there was some way for some hardware identifier to be exposed. Like a serial number or MAC address. But this kind of thing is exactly what it's made to protect against.
Nice, yes, a fresh Tails restart would definitely teardown the Fox process. And I think if you're disciplined, then purely ephemeral environments are the best mitigation for process-level state leaks like this IndexedDB ordering bug.
For those who want an ephemeral setup but prefer the Chromium engine over Firefox, you can achieve a similar "destroy after use" workflow using BrowserBox. It has a tor-run function that connects Chrome to a Tor SOCKS proxy and wraps all auxiliary network calls over torsocks.
You can easily spin up a purely ephemeral session using a GitHub action [0] so that absolutely no state persists once you close it. As a bonus, you can also run the BrowserBox instance itself as an onion hidden service while browsing over Tor.
You're right that BrowserBox is a commercial product and there's no free tier. Honestly, the reality of running remote browser infra and development is that a free version just gets instantly hammered by botnets, scrapers, and abuse. Keeping it paid is the only way to be sustainable.
I see Neko brought up a lot, but honestly when I tried it a couple years ago it felt pretty clunky. It seems designed more for anime watch parties than serious security or remote isolation, IMO.
I totally get the Tails/Firefox preference, tho. If you want absolute baremetal isolation on your own hardware and have the discipline for it, a fresh Tails USB is definitely the right move. BrowserBox is just a different architecture -- it's mainly for when you specifically want an ephemeral Chromium setup on ... well ... anything, need some policy controls or programmability. And don't want to fiddle with config yourself.
> Honestly, the reality of running remote browser infra and development is that a free version just gets instantly hammered by botnets, scrapers, and abuse. Keeping it paid is the only way to be sustainable.
Ah but I'd want to run it myself anyway. I wouldn't want it hosted. Especially for browsing, I don't want someone else's systems looking over my shoulder.
I avoid cloud stuff as much as possible in my personal life. When you mentioned github actions I thought it was something you could self-host too, I didn't realise it was a service only. I was looking for a docker or something but as it's not free and (less importantly) foss it won't work for me.
And yes neko is not a polished corporate solution, but it works for me as a home user. It's very flexible to build other stuff with. I have several instances here in different environments (and I don't expose them to the clear internet)
But for work yeah I know there's different options, at work we have zscaler remote browser.
Totally, I get that. That's why BrowserBox is also self-hosted, and yes, has a Docker image, too! Not free nor foss, tho. But I do try to be flexible.
As to cloud - indeed, why would you want to trust a cloud provider with sensitive internal browsing? Also, providing a SaaS is a hassle, but I feel I must do it serve that side and enable those uses, some of which are cool.
Ohh I didn't realise that it's your product, sorry. It sounds interesting but I'm only a home user (in Europe with not much budget). I just use remote browsers now for navigating the complex patchwork of blocks in the EU. Some sites are blocked in holland, others in spain, etc.
[1] https://eelhips.tumblr.com/post/7035963689/early-life-crisis
reply