Counterpoints - Why Anonymity No Longer Exists in 2026

General Discussion
1

Continuing the discussion from Why Anonymity No Longer Exists in 2026 - Open Discussion:

Simply installing anything in privsec field is a dubious claim. Have it ever been different?

complexity

I have a suspicion that computing cannot be simple by nature. Things like package managers and privacy extensions for browsers just shift the problem around. Real simplicity is achieved either through science, like a better performing algorithm, or minimalism, e.g. cgit vs codeberg or alpine vs QubesOS. But even in these cases you may argue that we’re just shifting complexity - either by using trickier algorithm, or by shifting the burden of missing features elsewhere.

In any case, some described problems are unreasonable or wrong. Privacy is hard, and it’s unlikely to get better any time soon. I guess topics like this are a reminder of the uneven struggle.

To make this post qubes-specific, here are some correctoins:

AFAIK it’s the other way around, and you can set up Ethernet MAC spoofing

I refuse to believe there is a significant portion of tor users tat is not aware of the built-in bridge mechanism. Are not default as a government blocking counter-measure.

Does not discuss qubes, although qubes is very good at generating background noise. In any case, unintentional background noise is useless against DPI, and arguably harms your privacy if you’re running Qubes.

Related: NovaCustom + BusKill partnership
Together with encryption should be okay for all but highest-ranking supervillains.

Everybody is vulnerable to lightning strikes. That is why I never leave the house.

Also whonix shouldn’t pass because network software 0-days are not impossible

Qubes is actually decent at this as it doesn’t come with audiovm preinstalled, and you can whitelist which qubes are allowed to use media system.
There are other similar techniques, sound from media isn’t the only option.

3 Likes
The grandest obstacle to making anonymous web browsing possible in QubesOS
2

:100: Clickbait titles are frustrating

If I understand correctly, almost entirely agree. My only (minor?) disagreement may seem semantic; the term “privsec”. Combining privacy and security into a single term seems, from my perhaps confused view to be oversimplification. It may seem like nitpicking, and may well be, but as I understand it security does not necessarily include privacy. Confidentiality yes, but privacy not necessarily. On the other hand “privacy” not based on a secure foundation seems to me to be an illusion. But may be that is a failure of imagination on my part. Would gladly read/learn I am wrong. Not looking to debate or argue but would appreciate being educated if I have overlooked something or am just outright confused.

No disagreement from me. Wonder if this would be more productively discussed in the Whonix forum or other places, but completely agree “…it’s unlikely to get better any time soon” Would go even further, but since this is the Qubes - reasonably secure - forum so will refrain.

Very interesting comment @otter2
Personally lean toward the qubes generating background “noise” “…arguably harms your privacy if you’re running Qubes.” Yet again would appreciate being educated if I have overlooked something or am just outright confused.

Giant GRIN! Any tips for finding where supervillain ranking lists are these days (or better yet where they might be discussing their opsec, hardware, and other supervillainary techniques :wink: )?

Thank you for your thoughts and posts. Not need to reply.
Kind regards…

3 Likes
3

Doesn’t a malicious actor need to break out of the (App)VM, in order to exploit Meltdown/Spectre, as CPU is virtualized/abstracted? domU shouldn’t have access to dom0 memory management at all.

Isn’t this easily achievable e.g. with GNOME NetworkManager? If not, just take another tool/distro of your choice - that is the beauty of a meta/Xen OS like Qubes.

These points are Tor or ISP network layer-related and not about operating system.

Author writes about general anonymity in the intro, but quickly switches to threat model of rather sophisticated, physical and targeted attacks.

Not sure about this one with regards to Qubes OS. Can anybody comment?

Conclusion:
I see 8 out of 10 attacks unrelated to topic of general anonymity and operating systems. Author seems to confuse security, anonymity and privacy as well. Overall rather click bait.

2 Likes
4

The “author” (of that video) is a clanker.

1 Like
5

Doesn’t a malicious actor need to break out of the (App)VM, in order to exploit Meltdown/Spectre, as CPU is virtualized/abstracted?

No.

“Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.” (XSA-254 - Xen Security Advisories)

domU shouldn’t have access to dom0 memory management at all.

Then what will manage dom0’s memory?

Not sure about this one with regards to Qubes OS. Can anybody comment?

As @unman explained earlier, revealing Qubes OS usage is not about TCP/IP level but about the hosts the OS contacts, e.g. during updates.

2 Likes
6

Thanks @qubist . In practice for Qubes, does that mean firmware and domU OS patches form the only protection layer against these types of attacks? Learned something.

Not sure, how to understand this. To my understanding, you might be exposed to TCP/IP fingerprinting by comparing OS-specific charateristics in TCP headers when contacting any host - be it updates, websites, or tor nodes.

2 Likes
7

To my knowledge, the following is still true:

https://wiki.xenproject.org/wiki/Respond_to_Meltdown_and_Spectre

So it’s been the same since 2018. Check the VM types of your running Qubes/VMs. Keep SMT disabled and use the latest kernels and firmware. It can’t get (much) better than that!

2 Likes
8

@sam

Thanks @qubist . In practice for Qubes, does that mean firmware and domU OS patches form the only protection layer against these types of attacks?

There are patches in Xen itself too:

https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ

Not sure, how to understand this. To my understanding, you might be exposed to TCP/IP fingerprinting by comparing OS-specific charateristics in TCP headers when contacting any host - be it updates, websites, or tor nodes.

So, the question comes down to whether the OS-specific TCP/IP characteristics of a Fedora/Debian template are different from those of upstream Fedora/Debian.

I am not aware of any TCP/IP-level modifications applied by Qubes to the guest templates, so I wouldn’t expect any differences. Hopefully, someone who is familiar with the matter may provide evidence.

3 Likes
9

Powerful LLMs can be used to scan for vulnerabilities throughout the project—many open-source projects do this—and security will only become more robust

1 Like
10

Thanks for the links to both of you. If I see that right,

  1. PVH and HVM mode VMs are already protected - which should be most of qubes, with PVH being default.
  2. Besides, there are Xen patches.
  3. Kernel patches for domU form another protection layer.
  4. Last, firmware updates - but depending on availability, this shouldn’t even be needed anymore.

Hence I don’t see, why article author states

This sounds like FUD - most of Qubes users should already be protected by default.

Yes, fortunately SMT per default also is disabled. I am not sure of security implications when enabling SMT, but it still doesn’t seem to be a good idea.

1 Like
11

Since 4.1.2 I have been getting this:

user@dom0:~ >  cat /sys/devices/system/cpu/vulnerabilities/srbds 
Unknown: Dependent on hypervisor status

I still have no idea what the hypervisor status is and how to check this particular vulnerability.

And… nothing of what we are discussing has anything to do anonymity, so can we probably have a proper split/topic?

cc @moderators

1 Like
12

The last time I ran some checks, I used xl dmesg in dom0 and compared the output with:

https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

Perhaps there is an easier way that I am not aware of.

Edith adds: Your above command works over here (“Not affected”) … Qubes 4.3 with 4.19.4 (dom0 kernel 6.18.31-1).

1 Like
13

@OvalZero

Thanks for this.

The last time I ran some checks, I used xl dmesg in dom0 and compared the output with:

xen-command-line

I am getting:

user@dom0:~ > xl dmesg | grep -i srbds
(XEN)   Hardware features: IBPB IBRS STIBP SSBD L1D_FLUSH MD_CLEAR SRBDS_CTRL TSX_CTRL GDS_CTRL

On the link you shared I read nothing about dmesg, so I am not sure what output to compare that with. The only reference in the text that seems to have some relation is:

“On hardware supporting SRBDS_CTRL, the srb-lock= option can be used to force or prevent Xen from protect the Special Register Buffer from leaking stale data. By default, Xen will enable this mitigation, except on parts where MDS is fixed and TAA is fixed/mitigated and there are no unprivileged MMIO mappings (in which case, there is believed to be no way for an attacker to obtain stale data).”

but considering this CPU is not affected by MDS or TAA, I have no idea how to read this.

1 Like
14

There should be more statistics about the settings in use (or compiled in). I’m not at home right now, but I’ll take another look at it.

1 Like
15

@OvalZero

Thank you. Looking forward to your feedback.

1 Like
16

Just for the history books – I was inspired by this announcement earlier this year:

https://www.openwall.com/lists/oss-security/2026/01/27/3

So, I tried to check what was going on with my configuration. In the dom0 terminal, the command xl dmesg | grep -i spec produced the following output on the machine I tried to check:

(XEN) Built-in command line: ept=exec-sp spec-ctrl=unpriv-mmio
(XEN) Speculative mitigation facilities:
(XEN) Xen settings: BTI-Thunk: JMP, SPEC_CTRL: IBRS+ STIBP+ SSBD- PSFD- BHI_DIS_S+, Other: IBPB-ctxt VERW BRANCH_HARDEN
(XEN) Support for HVM VMs: MSR_SPEC_CTRL MSR_VIRT_SPEC_CTRL RSB EAGER_FPU VERW
(XEN) Support for PV VMs: MSR_SPEC_CTRL EAGER_FPU VERW

Then I looked up the explanations for the various settings on the Xenbits page cited above (they can be found – as already said – under 1.2.176 Spec-Ctrl (x86)). Regarding your specific interest, Xenbits states:

Unless otherwise noted, options only have any effect in their negative form, to hide the named feature(s). Ignoring a feature using this mechanism will cause Xen not to use the feature, nor offer them as usable to guests.

Currently accepted:

The Speculation Control hardware features srbds-ctrl, md-clear, ibrsb, stibp, ibpb, l1d-flush and ssbd are used by default if available and applicable. They can all be ignored.

It further explains under 1.2.176 spec-ctrl (x86):

On hardware supporting SRBDS_CTRL, the srb-lock= option can be used to force or prevent Xen from protect the Special Register Buffer from leaking stale data. By default, Xen will enable this mitigation, except on parts where MDS is fixed and TAA is fixed/mitigated and there are no unprivileged MMIO mappings (in which case, there is believed to be no way for an attacker to obtain stale data).

The unpriv-mmio= boolean indicates whether the system has (or will have) less than fully privileged domains granted access to MMIO devices. By default, this option is disabled. If enabled, Xen will use the FB_CLEAR and/or SRBDS_CTRL functionality available in the Intel May 2022 microcode release to mitigate cross-domain leakage of data via the MMIO Stale Data vulnerabilities.

So another check in dom0: xl dmesg | grep -i unpriv, which yields:

(XEN) Built-in command line: ept=exec-sp spec-ctrl=unpriv-mmio

As far as I know, that means that if the CPU of that machine is vulnerable, the necessary mitigations are in the loaded firmware and therefore ‘in place’.

1 Like
17

Targeted surveillance and mass surveillance is in practice the same thing because first they do mass surveillance with Palantir giving everyone an risk score.
Every time you say something online, such as anti age verification, your risk score goes up.
It’s officially proven that they used to put people on lists just for being a linux user.
That shows how easily your score goes up.
PRISM was designed to target only suspects… and their entire social network. This had the effect of using targeted surveillance on everyone, so there was no different between targeted surveillance and mass surveillance.

Today its essentially the same thing, but it begins with Palantir score, then targeted surveillance on all people with a risk score. And that’s so many people its basically using targeted surveillance techniques for mass surveillance.

And if you think they wouldn’t use such targeted attacks on someone who’s not important, then you’ve missed out on the news of how FBI used to SWAT MAGA people constantly. It led to the few honest FBI agents quitting because it was too wrong and biased and obviously corrupt and weaponized as a political weapon.

I made a new topic about an actual real way to deanonymize users who browse web sites. And its specific to qubesOS because QubesOS is the only OS which doesn’t have an effective solution.

1 Like
18

contradicts: Why does Tails not spoof full Mac Address? - Tails - Tor Project Forum

1 Like
19

@OvalZero

Thanks for the additional feedback.

It further explains under 1.2.176 spec-ctrl (x86): […]

That’s what I quoted too. It is still difficult to understand what it means though because, as I said, this particular CPU is not affected by MDS or TAA, so nothing to be “fixed” or “fixed/mitigated”.

So another check in dom0: xl dmesg | grep -i unpriv, which yields:

(XEN) Built-in command line: ept=exec-sp spec-ctrl=unpriv-mmio

I get the same too.

So, based on all this, and according to the quote, it is not immediately clear if srb-lock= has a place at all, i.e. I don’t know if it is implicitly applied by default or whether I should somehow set it explicitly. What do you know about that?

The intel.com link is interesting though. It says Comet Lake H, S and U62 CPUs are not affected by SRBDS, and U42 is “MCU + Software” but no word about other Comet Lakes. The reason is unlikely the marketing status because discontinued CPUs are also in the table. FWIW, I don’t even have an idea what “U62” or “U42” means. The Wikipedia page doesn’t even mention such group - there are only S, W, H and U. On gets lost in all that.

1 Like
20

I understood the passage to mean that it is enabled by default when applicable.

By default, Xen will enable this mitigation, except on parts where MDS is fixed and TAA is fixed/mitigated and there are no unprivileged MMIO mappings (in which case, there is believed to be no way for an attacker to obtain stale data).

1 Like