resources than Qubes'. I mean, if the Qubes folks could fix these issues without a huge effort, even if it meant rewriting all the inter-VM communication tools, they probably would. If they didn't, I assume this is because this is just a huge undertaking (as is the whole project), and they're busy with other work which has higher priority. I would assume that you will end up in exactly the same situation. Note that SpectrumOS is going to make tradeoffs that are complete non-starters for Qubes.
True, but I'm not sure this applies to making GUI tools less buggy, or having better documentation for CLI tools.
Yes, it does apply. SpectrumOS is willing to accept quite a bit more of external code with good in-the-wild track record inside the trusted code base, at least for _most_ tasks. So where Qubes needs to reimplement something with a completely different design (allowing minimisation of TCB), Spectrum can (at least in the beginning, sometimes grudgingly) take the closest thing in existence and add only critically missing parts.
A wl_roots based tooling is seriously considered for the first full release, after all���������
Is using wl_roots a non-starter for Qubes?
Yes, and I hope it is a complete non-starter on the level of not being worth any discussion there. I can only remind you, that Qubes has doubts about KVM, a widely used part of the Linux kernel, being sufficiently secure. Thety have the same stance about half of the features of Xen, the hypervisor they do use. This does make some things Spectrum plans to do for usability and performance much harder to implement, as the underlying features are undesirable in the TCB. Compared to this, wl_roots is _way_ more dangerous. This is a library which has segfaults in relatively normal use, and apparently the users do hit these relatively frequently. Some of these seem to survive for months. I have not looked whether any of these are exploitable, but for the Qubes level of requirements one should just assume it is. Notice that for Spectrum one could also reuse some kind of VNC code if wl_roots is eventually considered too buggy. For Qubes even VNC libraries are far from good enough.
There is quite a bit of design space in the gap between ������quite a bit more secure than Firejail, with the ease of use around plain NixOS plus Firejail������ and ������less secure than Qubes, but easier to manage������. What do you mean by "quite a bit more secure than firejail"? isn't this side of the spectrum actually "firejail-like security"?
Firejail depends on namespaces, which still have some weird behaviours in some corner cases, there is a hope that VMs will be a simpler foundation.
The way I see it, the following are the major points on the usability-security spectrum for running desktop Linux (or another desktop OS for that matter), starting from the best usability and worst security, and ending in the worst usability and best security:
1. Run a regular Linux distro (some are better than others in providing quick security updates) 2. Harden the system: sandbox processes, harden the kernel and important userspace libraries like libc, enforce MAC, use Wayland instead of X11, firewall, verified/secure boot, etc.
If you do not understand what you are doing well enough, Wayland as you use it might end up being less secure than X11, by the way.
Most users, of course, don't bother and just use (1), which is actually fine in most cases. (2) gives pretty good usability, with the main issues related to sandboxing, since most Linux desktop apps were not built with sandboxing in mind, and the overall experience does not support it well (for example, there's no standard permission dialogs like in Android, where sandboxing works much better in practice).
Actually, if you write a few relatively reasonable wrappers around some kind of namespace-based sandboxing, usability problems kind of become quite different from the normal ones (some UI flows are actually better when the choices are trimmed in advance��� and also suddenly a lot of things do not need to be chosen uniformly at the entire-system level anymore). No idea how much effort is to make meaningful GUI permission dialogs. Android ones are clearly not meaningful enough, of course.