Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 17
Generated: 12:29:32
First thing I do on a fresh QubesOS install is keep the foundation clean. Anything that touches the system—sys-net, sys-firewall, sys-usb, sys-whonix, all the service qubes—stays minimal. I don’t install a thing into the templates attached to those qubes. Same goes for the default DVM. Clean base, minimal attack surface. When I need to install apps, I don’t contaminate the original templates. I clone the template, rename it, and point my daily App Qubes (personal, work, etc.) to the clone. So if Fedora ships as fedora-41-xfce, mine becomes fedora-41-xfce-custom, and that’s where the apps I need get installed. If I’m building a sensitive qube—banking, crypto, whatever—I’ll clone the untouched template again and keep that one lean too. Only install what I need. Nothing more. And this applies to everything in Qubes: Fedora, Debian, Whonix, Arch, Kali… whatever template you bring in. The rule is simple—keep the base template pristine, do your work in cloned templates, and let compartmentalization actually mean something. Keeping things minimal, isolated, and compartmentalized is one of the cleanest OPSEC habits you can build in QubesOS. #IKITAO #QubesOS #OPSEC #INFOSEC
2025-11-26 16:02:01 from 1 relay(s) 5 replies ↓
Login to reply

Replies (17)

Not for everything, but for some things, yes. It depends on the application, the attack surface, and the threat model. If an app touches identity, finances, private comms, or needs special networking—Signal, banking, crypto wallets, torrenting—then it gets its own minimal template. Clean base, small attack surface, no bleedover. It’s also utilitarian and performance-based. For example, I have a dedicated template and AppQube for gaming. But for normal day-to-day stuff—if the apps share the same identity and the same risk profile, putting them in one template keeps things sane and still respects compartmentalization. I isolate by threat model, not by religion.
2025-11-28 03:20:50 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
I use a dedicated machine. It’s not recommended to dual-boot Qubes because even if the Qubes install is encrypted, /boot isn’t. A second OS can modify it and compromise Qubes before it loads. Sharing hardware also means the other OS can tamper with BIOS/UEFI firmware, which puts the entire system at risk. Anti Evil Maid can alert you if /boot was changed, but it can’t prevent it or undo the damage. It’s also recommended to buy new hardware if you’re serious about security. And if you’re looking to run QubesOS on a dedicated machine, the hardware compatibility list is your friend. With Qubes, newer doesn’t always mean compatible. It should be noted that the unofficial community-recommended hardware list is for 4.1, and we are on 4.2.4 with 4.3-rc3 already released for testing, but you can find good recommendations and answers on the forum. https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html#choosing-hardware https://www.qubes-os.org/hcl/ https://doc.qubes-os.org/en/latest/user/hardware/certified-hardware/certified-hardware.html https://forum.qubes-os.org/t/5560
2025-11-28 14:50:55 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
That's not exactly correct. I provided links to the hardware lists. As far as Heads is concerned... whether I use Heads or Tails largely depends on convenience, compatibility, and threat model.
2025-12-02 03:53:10 from 1 relay(s) ↑ Parent Reply
I am talking about you can't trust what the OS is putting in there because their source is closed. They can be mandated by Feds to put backdoors. The CIA used to sneak it in at manufacturing but that is stopped now with code signing. So now they just mandate it, including very heavy threats to the business not to disclose. If what I am saying is not true then prove it by publishing the source.
2025-12-02 17:45:45 from 1 relay(s) ↑ Parent 1 replies ↓ Reply