Next-Gen Qubes OS Settings UI

[ninavizz]

How to file a helpful issue

apologies for the biz-jargon-y phrasing of the title; this issue is not to improve an existing thing but to build a wholly new GUI to replace existing GUI, such that a new GUI could be more extendable and ideally with APIs to avoid monolith code blobs.

Problem

Qubes OS is complicated! There are tons of useful and awesome capabilities built into Qubes OS that users don't think to look for, because they do not exist in "normal" single-environment (or other hypervisor) systems. Much of what is amazing about Qubes, today, is only available on the command-line—which regrettably hinders discoverability for all users, and restricts access to technical users.

Likewise, some very basic things such as editing one's FDE password, are missing from today's GUI. For less technical high-risk users needing a reasonably secure operating system that does not require majority-use of the command line for administrative and inter-qube permissioning needs, today's basic and robust functionalities need to be made available in a GUI. Qubes is an OS (as users experience it), after all.

Solution

A Settings experience presented to users in a unified GUI that meets their expectations of a single "Settings" UI. A left-tab/navigable pane analogous to what users are familiar with on Windows, Ubuntu, and other usability-renowned systems.

When tackling the design problem of developing a GUI for Policies in #4721, some of the broader needs above were surfaced. It was determined that the most intuitive place for folks to find Policies functionality, would be in a "System Settings" UI. Likewise, early user surveys and user research have uncovered basic functionalities being absent in the UI—editing one's FDE password, changing updates proxy, and other things made available at the time of installation or initial boot.

Because this new experience will pack in much more functionality than today's Settings screen, add-in an "Apply" button so the primary actions on the experience are Ok-Cancel-Apply.

Wireframe shown below demonstrates what this could look like as an initial release, and as a matured release—with more tabs & functionality added, with each release. The InVision Prototype for Policies also demonstrates these things, and some more granular interaction patterns developed for Policies, for #4721.

The value to a user, and who that user might be

• Any high-risk, non-technical or non-Linux native user, seeking a reasonably secure operating system.
• Any technical user, excited about Qubes but lacking the attention span or time to copiously read whitepapers or the docs to learn about allthethings.
• Any user desiring the ability to do simple things w/o looking-up how to achieve things on the command-line and within which qube/template.

Windows and Mac users, especially, expect a single "Settings" UI to manage all system passwords and high-level systems control types of functionality.

Other approaches considered

Linux-native users are more likely accustomed to the FOSS/Linux model of multiple applets existing, with each offering a small handful of GUI controls to mange different control system functions. So, yes, while this is also an option it is ill advised as it delivers a poor execution and discovery experience to all users. Some have even commented that this is why they prefer navigating Linux systems on the command-line.

The experience for an end user of knowing they need to "do a thing" yet are not sure which applet may control that thing—so they open/close multiple applets looking for "the thing" is tedious. Likewise, having to open multiple applets to shape a desired outcome, is also tedious. Finally, the discovery experience of available functionality is also poor with the disparate-applets approach, as it is not natural behavior for a user to either RTFM, or to open all the applets and remember all the capabilities from that first open/close experience. With users experiencing the complete value of Qubes, discovery feels very important—as few concepts Qubes tackles are natural or known to many users.

For maintainers and developers, however, the applets approach is more scalable. As such, I am proposing the unified multi-tabbed single-UI approach with the caveat that it be built such that each tabbed pane exists on the backend as its own applet... with API calls used to unify the GUI into the easier-to-use holistic experience.

Analogous Solutions

Mac Settings

As a Mac user, I will vote against Apple's paradigm of the multi-icon pu-pu-platter screen... as it delivers a fussy/irritating experience of having to bounce back and forth between a "main" screen and a "category" screen, when I'm looking for something. The left-nav multi-pane model, offers a smoother discovery experience for users.

Windows 11 Settings Pane

KDE Plasma Settings

Ubuntu Settings

[zetigu]

Wow, I am very impressed by your work ! I really like the look of your mock-up System Settings.
Is there any work on this ? I think that this would be a great addition to QubesOS !

For the elements that have multiple sections what would be the best ? :

• A top tab like Ubuntu
• A tree sub element on the left
• A left replacement like KDE (with a back element at the top)

I like the KDE way as it provides a search [box] also. It even has a help [box] (but it should not launch a browser!). So reusing it's framework and just adding a logo + text on the top left could speed things up on development side no?

Things to consider adding in the future :

Update :

Split GPG

• Yubikey/Librem/Nitro(s) integration for split GPG for rapid integration with simple GUI that automates everything. Just select a Vault-qube and a hardware key, it will initialize it if new or guide you in adding it to a Vault-qube. This should enable anyone to use a hardware key in a few clicks.

New sections :

Backup and Restore

Just nice integration of existing tool, with Split-GPG integration if password is not sufficient. Would be nice to include possibility to backup to a s3 compatible bucket through a firewall qube (tor/vpn/wg) (s3ql/s3fs integration?) by just specifying key and url. Add a [button] to forget key/passphrase for backup if saved (better use Split-GPG and have your keys backed up elsewhere).

Coreboot

As more PCs should come with coreboot, a menu section to configure it should be useful. There is a nice gui client from StarLab called coreboot configurator that would fit well here.

Display and GPU

This panel could enable selecting sys-gui, sys-gui-gpu, sys-gui-vnc. It would feature selection options (like gpu selection) and a recovery safety checkbox. For gpu, you could check box for auto grub settings and auto assigning the GPU to desired sys-gui-gpu qube and making sure it autostarts. The safety would be that if you lock yourself out, after 5 min it would revert back to normal. Changes would need to be confirmed again in Qubes System Settings before 5 min after reboot. The previous configuration will be reloaded and the system will reboot itself (use SystemD?). Necessary for sys-gui-gpu in case something goes wrong.

Drives

• List attached storage and if they are connected to a qube.
• Check SMART status of SSD/HD of Qubes-OS rootfs.
• Launch a GUI partition manager (KDE/Gnome/?).
• Show if OPAL is available for some drives and if it is enabled.
• Secure erase a drive/partition by zeroing+overwriting and calling TRIM.

Encryption

• LUKS. View number of keys for /rootfs LUKS and make backup of header or change key.
• Enable 2FA encryption like with dracut or 2nd storage. Would be great with something like a self destroying usb with a integrated battery and SelfDestruct [button].
• Enable Yubikey/Librem/Nitro key for grub for 2FA or 3FA.
• Enable encrypted qubes support. Require GPG decryption before launch (from Split GPG with preferably a hardware key).

KVM

• There are limitations to xen and hibernation is one of them. So KVM could be enabled to run nested inside a qubes. This would allow to hibernate the KVM and then stop the qube. On restart, resume the KVM vm and you have a less than optimal, but working implementation to quickly start/resume work in a vm without closing a program. If implemented, adding a section here to configure it (in a far away future).

My Computer

• View system hardware, available storage, xen cpu, memory usage with nice graph. Pie chart storage usage by qubes and templates. A dmidecode parse would present what hardware is present in a pleasant way.

Power management

To view and config those, useful if using a sys-gui-gpu qube.

• For laptop hinge, battery, power button, cpu idle/clock, gpu, fans, pcie) or more.

Offline

• Documentation mirror
  Have a local mirror of Qubes OS wiki/faq/git issues/mailing list/helpful information in case of need while not connected to the internet. As a matter of fact, a mirror or Arch wiki and Fedora documentation would be a great addition to have on hand at all time. Just pack it up in a .rpm would be nice and I think the license would allow it.
• Repository mirror
  Necessary for air gaped/no network/poor network : Create a local qube with abundant storage and mirror fedora repository (150GB per version ?). Enabling this option would :
  • configure salt to update all qubes's repo to local qube's http adress after mirror successfully copied
  • configure firewall rule to allow communication to local repo server
  • manual update of repository or make a crontab entry

Stealth mode

• Dom0 force all wifi/BT devices off pci/usb (disconnecting them from qubes, may require a restart of those) Or forcing down those qubes. Force pcie/usb power off if available (echo 1 > /sys/device/$ADDR/remove).
• And reassign them back to where they where when out of stealth mode and activate them again. For those that don't have hardware kill switch.

Templates

• Choose Official and Community repository here.
• Choose defaults templates here.
• One click installation/removal with progress bar of templates would be nice.
• Show installed templates and list available templates with their size and a [Refresh] button.
  • Show used space by template and total space used.

Power user sections :

Experimental

Enable easy experimentation of newer or experimental versions of QubesOS. Create appropriates entries in Grub like Snapper would. In fact, it would be better to integrate Snapper and just click to create a snap or restore a snap. For any more, launch Snapper gui.

• Snapshot rootfs for reverting to older configuration or testing a debug version of QubesOS.
• List available QubesOS dom0 updates. (In addition to unstable, we could add RC candidates, preview rawhide, custom build repository).

Paranoid.

This is mostly extreme cases not many user should face. Also, TPM could be used to store a part of the secret for LUKS decryption, and flushing the TPM could provide a quick way to brick the Qubes OS encryption and prevent any access even if they hold you prisoner/hostage as the key is impossible to recuperate no matter what you could do even if you where to collaborate (under torture or not).

• Auto shutdown if logged out more than XX min. Not sure how it can be implemented if sys-gui-* is enabled.
• Panic. Assign a key combination or power button push to prompt for LUKS header erasing.
• LUKS Header Backup. To create backup of headers and/or a rescue USB with header encrypted with password on a TAILS image USB drive.
• Check state. Prompt authentication every XXX min, after no reply and delay of specified time, auto erase LUKS header and reboot. Warning, will require USB rescue disk and backup headers. In some rare cases, having the backup headers in an other country could be a good idea. Useful if laptop is seized and they preserve current with external battery to move it to a forensic specialist. In extreme case, force OPAL erasure after LUKS headers erasing if supported by SSD/Disk (permanent data loss) and/or TPM. Enable only when extreme danger is about to fall on user !
• TRIM SSD frequency.
• Ultra paranoid. Backup LUKS headed on dom0, erase LUKS header after boot and send TRIM. Only restore header on a prompt that ask your password on a shutdown request. If not supplied in required time, will need USB rescue disk to reboot or have a SAILS partition bootable that can be used as rescue or to access web in case Qubes-OS self destructed it's partition.

Remote

It would be nice to have a convenient way to enable remote ssh in a Qubes-OS system (bare or virt) ONLY FOR DEVELOPMENT ! A simple checkbox that would forward a port from a specified ip and with ssh key only to dom0. With lots of warnings explaining why this is not a safe thing and must only be used to debug a unused development system in a secure environment !

Only a greater future ahead for Qubes-OS

I know that's a lot, but if we want Qubes-OS to move to the group of people that was identified in group A "non-technical or non-Linux native user" and group C, that's the kind of roadmap that we should try to plan. Most of my points are not necessary, but a few of them would be game changer for certain features usage. But all those points go back to one thing, your great idea of a Next-gen Qubes OS Settings UI is central to pushing Qubes-OS in the hands of more people and allowing easier general usage.

Thanks @ninavizz for sharing your ideas and the same goes to all other contributors of this great system !

[marmarek]

@marmarta this is completed now, right? or is there something still pending?

[marmarta]

It is.