>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. …
Qubes OS is a great solution for this threat model. By my (admittedly cursory) understanding of this attack, one would have to chain the attack to escalate to dom0 to get around it.
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.
> one would need to spawn new disposable VMs for each identity
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
You should note that improperly using Qubes OS, creating a New Identity inside of Tor Browser, even in a disposable Whonix workstation VM, would leave one vulnerable to this.
A user would have to manually start a new disposable VM for each identity.
> It seems Qubes OS and Qubes-Whonix are not affected.
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.
I believe you are correct, and that this poses a significant risk for people who don't properly understand the underlying concepts.
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.
On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
> On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.
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.
You are right, and I am saying exactly the same thing. You seem to misunderstand that Qubes saves you whenever you use it as designed by its security approach. To benefit from Qubes security, you have to use virtualization to compartmentalize your tasks. Only virtualization is a guarantee of security. Everything running in the same domain is assumed to be not isolated, and a compromise would affect everything in it. Even root access has no password by default in VMs. So what you're saying is obvious to any Qubes user. This is why I didn't mention it. (But I should have indeed.)
By you reasoning, Qubes doesn't provide more protection than the underlying operating systems. I've seen this myth on HN multiple times.
This has nothing to do with "No True Scotman", because my definitions and assumptions are not flexible. They are defined by the Qubes developers and documented. You misunderstanding me does not equal me being wrong.
When I say "this tool protects you" and you reply "it doesn't protect you if you misuse it; you give dangerous advice", you are the one misleading everyone. (Same with the kill switches on Librem 5.) Other people asked me for details instead of making a personal attack, https://news.ycombinator.com/item?id=47868133
Perhaps you are right that I could add more details for newcomers, but I was not wrong or harmful, unless you think every advice must have a full documentation for tools attached to it.
In the last ten years has qubes moved on to support more hardware? Every 4 years I would try to use it only to find it didn't support any of my hardware.
Qubes OS hardware support, while still far from perfect, is vastly better than it was ten years ago.
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.
We buy off the shelf laptops, not sure anyone ever checked that it can run Qubes specifically before trying to install it (I'm sure of at least one person: myself). Doesn't just about any x64 machine with hardware where drivers are available in standard kernels also work with Qubes? What have you bought that's not supported?
Most hardware (especially GPUs) is hard to virtualize in a secure manner, which is the entire point of Qubes. People who use it typically buy compatible hardware.
Tested hardware can be found here https://qubes-os.org/hcl. New hardware is being constantly added. If you plan to switch to Qubes, consider buying something from that list or, better, certified, or community-recommended hardware linked there.
People who use tools incorrectly bear responsibility for corresponding dangers themselves. They can always ask for an additional advice or more details. I don't understand why you are attacking me for that. See also my answer elsewhwere (and please stop repeating the same thing in every comment thread): https://news.ycombinator.com/item?id=47878794.
> I would care if my data is (1) available to Apple to read by virtue of not being e2e encrypted, and (2) used to train models and target those advertisements.
Here we go:
Apple fined $8.5M for illegally collecting iPhone owners' data for ads (gizmodo.com)
Kinda weird to argue for longer life via battery replacement and against longer life via contaminant protections. My phone is regularly covered in chalk dust, sawdust, water, …
Phones cannot have non-updated software due to another EU Regulation: Cyber Resilience Act. You need to support devices at least for 5 years starting from December 2027.
How sure are you that the vendor is actually providing device-specific updates? What about firmware updates? Outside of x86 ecosystem the whole-device-family updates in mainline Linux kernel is rare. You're probably deceiving yourself believing that your devices are up-to-date.
Most of the time laptops and many "mainline-friendly" phones stop receiving firmware updates in 2 years. By "firmware" I mean the binary blobs for the peripherals. Most of the SoCs have unified memory for the LTE and CPU modules. If a vulnerability found in the firmware of the LTE module, it can be used for data extraction.
CRA puts hard requirements on documenting and fixing vulnerabilities in device software in 5 year period. It cannot be infinite amount of years, so a reasonable update period had to be choosen. It covers everything provided by the vendor itself too. So if there are vulnerabilities in FW they have to fix it unlike the current situation.
> How sure are you that the vendor is actually providing device-specific updates?
First of all, my phone runs an FSF-endorsed operating system, so no closed drivers. Granted, not everything has been upstreamed yet, but they're working on it and I trust that it will be done soon. (They have done it with the devkit.)
Second, my phone has removable modem and removable WiFi card (no unified memory), so when the firmware can't be updated anymore, the card itself can be replaced. (They actually have already done it by releasing a new WiFi card; 5G modem is also being tested). In the worst case, the device can still be used as a pocket computer with no wireless communications.
reply