I think the non-screaming version might be something like this: There’s nothing wrong with what you want. Your desires and use cases are legitimate and understandable. But why should one tool be made to serve so many different masters? Isn’t it better to have a variety of tools, where each one does one thing and does it well?
Qubes OS is a tool for securely compartmentalizing one’s digital life. It accomplishes this by being a reasonably-secure, single-user desktop operating system. It does that one thing and does it well. It doesn’t do high-performance computing well. It doesn’t work well as a network server. It can be made to do such things with enough finagling, but it’s a bit like jamming a square peg into a round hole.
Should Qubes continue to focus on doing one thing and doing it well, or should it try to take on more jobs and risk doing them less well? In my opinion, it should stay focused on its primary function. Security is hard enough. If Qubes ever fails to be significantly more secure than more mainstream operating systems, there will be little reason to use it. It’ll just be a more cumbersome, less capable version of them. I don’t think Qubes can afford to be distracted if it is to succeed in its mission, especially since it is a small project with limited resources.
It’s not as though all options that sacrifice security for functionality are on equal footing. For example, some computers cannot run Qubes at all without certain accommodations. Making some security sacrifices in order to be able to run Qubes can actually increase overall security, because the alternative is having to run a completely different operating system — one that will almost certainly be less secure. This is decidedly not the same thing as sacrificing security for the sake of performance, convenience, or fancy features, because those things are not required in order to use Qubes for its intended primary purpose.
I think the main difference between the current options that sacrifice security and the ones you’re requesting is that the current ones are mostly related to basic functionality that is required for Qubes OS to work as intended on a lot of hardware. Let’s look at the specific examples mentioned:
My understanding is that this is required for computers that rely on a USB device for network access. Without this option, the computer cannot have network access at all. While it is possible to use Qubes on a completely-offline machine, I think it is reasonable for the developers to consider network access to be a basic requirement for the vast majority of intended use cases.
On some computers, the only possible way to have any kind of pointing device is with a USB-connected mouse. Again, while it may be possible to use Qubes with only a keyboard, I think it is reasonable for the developers to include a pointing device in the baseline functionality they’re targeting.
I’m not entirely sure about this one. Up until relatively recently, these qubes being non-disposable was the default. Maybe it’s still being phased in, or maybe these being disposable still causes problems for some machines. (Note that the remarks above about network access and pointing devices may also apply here. If either of these qubes were unusable, basic functionality would also become unavailable.)
This one is different. For one thing, enabling full screen mode does not have to reduce security. If you are careful, you can always check to make sure that a full-screen window is not impersonating dom0 (e.g., using a keyboard shortcut that’s intercepted by dom0 to move/switch/display windows). For another thing, this only affects qubes for which full-screen mode is enabled, which means it has no effect on security when, e.g., those qubes are shut down. The security impact really depends on how the user chooses to interact with this feature.
Now, let’s turn to consider the requested options:
I’m not sure, but I think this might already be possible with some kind of GRUB option or something. But I suppose the request is for an easier way to do it. Personally, I don’t think this would be a good use of the developers’ time, because improved performance is, almost by definition, not required for any of Qubes’ intended use cases. Of course, in the extreme case, if performance is bad enough, it can make any system unusable, but I don’t think that’s what we’re discussing here. We’re just talking about being able to do all the same things either somewhat faster or slower, but still within usable parameters.
I don’t know enough about this to comment on it.
I also don’t know anything about this, but it’s worth noting that qubes-remote-support exists. From my personal perspective, this seems almost antithetical to the purpose of Qubes. I’m trying to do everything I can to keep people on the network out of dom0 and my offline qubes, not open up holes to let them in, so this seems counterproductive. But then again, maybe there are secure ways to do this and legitimate use cases that I haven’t considered, so I’ll reserve judgment until I learn more.
My understanding is that giving a bluetooth keyboard access to dom0 would make it significantly easier for the entire system to be compromised. If there’s no other keyboard option besides bluetooth, that might be an acceptable risk (since the system would be unusable without a keyboard), but as far as I know, there are no Qubes-capable devices that support only bluetooth for a keyboard. Again, I don’t think this would be a good use of precious developer time for the general reasons discussed above.
A bluetooth mouse might be more acceptable, given that (1) mice are less security-sensitive than keyboards; (2) USB mice are more commonly granted access to dom0 than USB keyboards; and (3) wireless mice are extremely common (especially with laptops) and could eventually come to displace wired mice in the computing market, at which point some users may have no other choice.
My understanding is that bluetooth headphones can already be used in Qubes. See these related threads:
- Enabling Bluetooth on Qubes R4.1
- How-to use bluetooth in an AppVM
- How to use Bluetooth?
- How to access bluetooth hardware in sys-audio
Confining the use of bluetooth to less-trusted qubes seems unproblematic from a Qubes security perspective.