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.
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.
Those aren't our only two choices, and this is pretty manipulative and fallacious rhetoric on multiple levels. It's difficult to take much of what you say in good faith, given how you persist despite it being pointed out to you repeatedly, and by many people.
Somewhere between your original comment and requiring all advice to have full documentation attached to it is a reasonable course of action. Another quality frequently exhibited by your comments is dealing in absolutes, which tends to undermine your points and make your positions technically fraught.
I think if you're evangelizing an OS people may be unfamiliar with, and for an audience discussing a particular vulnerability, the responsible thing to do is add even the bare minimum of context to your comment rather than continuing your habit of posting fairly bare links sometimes accompanied by terse absolutes as if they constitute substantive commentary. All that serves to do is turn people away from your beloved projects, and frequently backs you into technical corners requiring you to accept even the slightest responsibility for your comments.
Here's a way of doing it: "The bug described in the article still exists within a given VM, but Qubes OS is the most practical solution I've found to split Tor Browser identities across disposable virtual machines, which fully addresses this vulnerability."
I get that you aren't precise with your language, which is usually where people seek to correct you and you double down, but when discussing technical subjects we ought to be precise, lest we inadvertently cause problems for others. And you might, one holds out hope, actually learn that some of your technical assessments are founded on incomplete or incorrect assumptions.
It's easy to be a zealot, and anyone can do that, but it's not actually that much more work to make genuine contributions.
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.