Additions and changes

[An-anonymous-coder]

1. After Create a separate wheel account for admin purposes step 7 the yafti window will open on the admin account. It's not clear whether this window should be ignored or if the steps for yafti should be followed again.
2. Step 5 has you exit run0 before rebooting, but step 10 has you reboot without exiting. Either step 5 should be removed or an exit command should be added before step 10.
3. A Recommended Hardware section should be added to the website. The hardware there should be ones that pass GNOME's Device Security checks. Here are some resources from other projects:
   https://www.qubes-os.org/doc/certified-hardware/
   https://forum.qubes-os.org/t/community-recommended-computers/
   https://www.qubes-os.org/hcl/
   https://libreboot.org/docs/install/#which-systems-are-supported-by-libreboot
4. The Flatpak article lists the hardening command ujust flatpak-permissions-lockdown, but that command isn't listed as an option in the post install instructions. There is a mention at the end to read the FAQ, but that's not given with high priority.
5. People commonly ask about the differences between secureblue and Qubes OS. It should be added to the FAQ to explain the different philosophies and how they go about mitigating risks. Qubes OS also has an open issue for adding a secureblue template, so users should be advised whether or not that is a more secure option than running secureblue on bare metal.

[RoyalOughtness]

On 1-2 good points, those should be clarified

3. Yep, HSI-level is probably the most important piece there. Qubes has considerations that are out of scope for secureblue, like libre/coreboot support. The folks at https://privsec.dev are working on an article along these lines. Once it's ready we can evaluate whether we want to simply link to it as a reference or use it as inspiration for an article

4. Good point, we need to incorporate that into the postinstall steps. We'll have to do so with a strong disclaimer, as that script will require users to manage permissions on a per-app basis, which will inevitably cause some users significant frustration.

5. Qubes and secureblue have fairly different objectives. They're not really comparable. Apples and oranges kind of thing.

Qubes is good for those who want to use virtualization to isolate and compartmentalize.

secureblue is good for those who want to use desktop linux, but with known security holes filled and proactive exploit mitigations in place.

whether or not that is a more secure option than running secureblue on bare metal.

This misses the point of Qubes. Qubes doesn't make things more secure simply by running everything in one VM. The point is to use several VMs and isolate things from each other

A better comparison would be: is using secureblue in a qube a more secure option than using Fedora in a qube.

[An-anonymous-coder]

For the recommended hardware list, it may also be a good idea to list which FIDO2 hardware security keys are recommended for ujust setup-luks-fido2-unlock. These are a few open source options:
https://www.nitrokey.com/products/nitrokeys
https://solokeys.com/
https://onlykey.io/