Posted by danpinto 23 hours ago
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.
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.
For remote browser tools I use neko https://github.com/m1k1o/neko
But with Tor I like to have more safeguards. So I prefer to run tails in an isolated environment.
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.
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.
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.
https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1...
Says that Firefox has a bug that prevents favicons from being loaded from cache, which inadvertently protects against this technique. They filed a bug report on it in 2020 but nothing has happened with it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257
Dump the rendered window pixels out to a simple viewer. Mouse movement is still a pain to deal with, but I would default to spoofing it as moving between clicks, with some image parsing logic to identify menu traversal.
Then it should reboot the browser process regularly.
I've been waiting for someone to make a packaged 'VPC in a box' incorporating networking and linked VMs.
connects 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).
Just use a network namespace individual pieces of software are way too easy to misconfigure.
This is dangerously incomplete and bad advice.
Qubes OS does not work the way you seem to think it does.
Creating a new identity in the Tor Browser inside a disposable VM does not automatically stop that VM and start a new disposable VM. That initial disposable VM launches the new identity from the existing process and therefore remains vulnerable, the same as any bare metal computer running Tor Browser would.
Virtualization is not magic.
A Qubes OS user needs to spin up a new disposable Whonix VM to sidestep this attack. Creating a new identity alone is ineffective in this threat model.
If you care about these projects as much as you say you do, please stop giving harmful advice. You do it in various places on the Internet and in every thread which gives you half a chance to do so, and these projects would be better off if you either took any of the extensive well-reasoned correction many people offer you, or opted to stop making such claims. The former would be ideal, the latter still vastly preferable to the existing state of affairs.
A Qubes OS user needs to start a new disposable Whonix workstation VM to sidestep this attack, NOT create a new identity in the same disposable VM's browser, which is exactly what this attack targets.
This is technically incorrect information and could get people in trouble if followed literally.
On Qubes OS, if a user creates a new identity inside a Whonix workstation disposable VM via the browser's new identity functionality, the new identity spawns within the same disposable VM. I just tested this on Qubes OS 4.3.
That, I assume would expose one to OP's vulnerability, as its still running in the same VM. I would be glad to learn that I'm incorrect in my unverified assumption.
Even Qubes OS users still need to be mindful to launch new disposable VM when keeping identities separate to sidestep this attack.
By you reasoning, Qubes doesn't provide more protection than the underlying operating systems. I've seen this myth on HN multiple times.
Also, please stop grossly misreading the comments of others. You consistently do it to numerous people here.
Joanna Rutkowska's understandable preference for older kernels had its advantages, but the current team is much more likely to ship somewhat newer kernels and I've been surprised by what hardware 4.3 has worked well on.
Beyond that, I'm currently running a kernel from late Feb/early Mar (6.19.5).
Driver support can still be an issue, and a Wi-Fi card that doesn't play nice with Linux in general is doing to be no different on Qubes OS.
The saying about assumptions is as true as ever, unfortunately for both of us.
> For security and product stakeholders, the key point is simple: even an API that appears harmless can become a cross-site tracking vector if it leaks stable process-level state.
This reads almost LLM-ish. The article on the whole does not appear so, but parts of it do.
Did you even read the article at all? Ah my children did bad in school, time to replace them with new children and a different spouse. This is what you're suggesting essentially. A browser is not just something you simply make out of thin air. There's decades of nuance to browser engines, and I'm only thinking of the HTML nuances, not the CSS or JS nuances.
>Physical isolation is a given safeguard that the digital world lacks
…
>In our digital lives, the situation is quite different: All of our activities typically happen on a single device. This causes us to worry about whether it’s safe to click on a link or install an app, since being hacked imperils our entire digital existence.
>Qubes eliminates this concern by allowing us to divide a device into many compartments, much as we divide a physical building into many rooms. …
Sold
Having said that, fsflover exhibits a poor grasp of how this stuff works and all should be aware that even in Qubes OS, one would need to spawn new disposable VMs for each identity; relying on the Tor Browser's new identity creation within the same disposable VM would be little different from running Tor Browser on a traditional OS.
This is by design how everyone should always be using Qubes OS for any task, according to its documentation and approach to security.
> relying on the Tor Browser's new identity creation within the same disposable VM would be little different from running Tor Browser on a traditional OS
Yes, if you use a single VM on Qubes OS for everything, then all security you get is from the OS running in this VM. This is not how you use Qubes, https://doc.qubes-os.org/en/r4.3/introduction/faq.html#how-d...
I run Qubes as a daily driver according to the docs, and my workflow was not vulnerable to the discussed attack.
Yet again, please stop grossly misreading the comments of others. You consistently do it to numerous people here.
A user would have to manually start a new disposable VM for each identity.