Create a new Device UX flow

[marmarta]

Brief summary

Current device UX: not great. Desired state: better.

Main pain points:

• USB storage devices are a UX hell: they appear in the widget in multiple places, it's definitely not simple to decide what to connect to a qube
• it's easy to misclick something in the widget
• notifications are confusing and not very helpful
• it's very easy to not connect one or more of the webcam/microphone pair when doing a call
• devices are confusing and badly named
• it would be nice to decide which qubes can get device attachments at all

[marmarta]

Current early prototype: https://design.penpot.app/#/view/94d0bf99-a273-8157-8003-202ca9b178da?page-id=8a7ef8a5-cf6f-807c-8003-2165f016cdc1&section=interactions&index=0&share-id=52961d58-0a92-80c2-8003-285ff4e779c2

[DemiMarie]

Current early prototype: https://design.penpot.app/#/view/94d0bf99-a273-8157-8003-202ca9b178da?page-id=8a7ef8a5-cf6f-807c-8003-2165f016cdc1&section=interactions&index=0&share-id=52961d58-0a92-80c2-8003-285ff4e779c2

I’d like to see some more separation between the qube names, to reduce the chances of accidentally clicking on the wrong qube.

[jamke]

Thanks for the preview. Is that a future default font for R4.2 or images are just stretched vertically? Spaces are a bit off, especially on the 3-rd image.

[jamke]

An idea: per-device favorite qube list, even automatic (see at the end).

If user has devices webcamera, usb printer, flask disk, usb-ethernet they probably want to connect each of them the same qube or qubes, e.g.:

1. skype and whatsapp qubes, or some videoconf qube
2. printer qube with printer proprietary drivers
3. some usb-storage qube that manages flash drives safely without connecting block device to more valuable offline qubes.
4. some qube that should get network access.

So, adding all these qubes to favorites will be not great, it will make chances to connect wrong device to wrong qube quite high, including adding network adapter to always-offline qubes and vaults.

Seems better to provide submenu for each device a bit differently, on PER-DEVICE basis.

In can be done automatically without user actions - user connects some device to some qube(s) several times and this/these qube(s) are in the top part of the qubes list for this device, maybe also with different distinctive font color or background.

[marmarta]

The problem with per-device favorites is simple: what is a device? There is no good way of actually ID-ing a device; the best we have is what the device introduces itself as, which can be nothing (for many usb sticks it's like that), and device type; I'm think right now a "per device-type" favorites could work.

[marmarta]

Thanks for the preview. Is that a future default font for R4.2 or images are just stretched vertically? Spaces are a bit off, especially on the 3-rd image.

That's just a mockup, using Source Sans Pro because it's convenient.

[jamke]

There is no good way of actually ID-ing a device; the best we have is what the device introduces itself as, which can be nothing (for many usb sticks it's like that), and device type; I'm think right now a "per device-type" favorites could work.

lsusb shows ID for the device model, plus BUS and Device numbers. Those combinations stay unique till hardware configuration change.

udevadm info --name=/dev/bus/usb/001/002 --query=property shows a lot of properties, too. Here 001 - BUS number, 002 - Device number. That call does not even require root rights, so OK for user's apps.

Advanced users can modify udev rules to name devices based on their serial IDs.

[rocodes]

Thanks for opening this discussion @marmarta, the mockups look so great. I'm going to try to separate feedback into 'stuff around the UI itself' and 'possible feature changes.'

Possible feature changes

• [re deciding which qubes get USB attachments] An optional default USB dispvm configurable eg via qubes-prefs would be cool. (For example, if your system default dispvm is fedora-38-dvm, but you want your default USB qube to be a non-networked/otherwise hardened dispvm)
• [re it would be nice to decide which qubes can get USB attachments] absolutely, this would be huge. (eg if we could configure via RPC policies that qubes don't advertise themselves as 'attachable', then they would at least not show as attachment targets in the GUI).

Feedback on current UI (sounds like much of this is what's on your mind already to address with these mockups):

• The Qubes docs indiciate that attaching devices as block devices is preferable to attaching the whole USB. Currently, there's nothing in the device menu that would indicate to the user that one choice is better than another (or that they are mutually exclusive- eg a USB device can be attached via USB passthrough to one qube but still show up as block storage in the devices menu, and the user might not realize they have to detach whole usb from the first qube before they can attach a block storage partition from the usb to another qube).
• People find the current Device Widget tray icon itself unclear
• If a device name is too long, the name of the VM it’s currently connected to is truncated, so it's hard to see what VM it's attached to from the GUI
• Are there ways to make the menu easier to read/less information-dense:
  • Does the "device type" icon (small icon of USB, mouse, microphone, etc) add to the menu or does it duplicate the information already there (eg if a mic is in the "Audio Input" sub-menu, does it also need a microphone icon beside it, or is that unnecessary?)
  • Is displaying the device id sys-usb:X-Y in the top menu?
  • is there some way to simplify the display of multi-partition devices and/or devices that can be attached as either block storage or via usb passthrough?

[rocodes]

To @jamke's point, this is something SecureDrop Workstation has discussed a lot (is there any way to "remember" devices that are always attached to certain VMs to make a user's life more convenient), but basically, devices can lie or represent themselves badly, so it seems like a risky idea. It might be OK if you were treating all your devices as default-untrusted and just deciding which untrusted environment to dump them into, but as soon as you are trying to do that to identify trusted devices (and presumably autoattach them to more trusted VMs) it seems risky.

[jamke]

but basically, devices can lie or represent themselves badly, so it seems like a risky idea.

How is it possible for USB device to lie about Bus and Device numbers inside dom0 or sys-usb? And PCI IDs?

[jamke]

And about name that device provides itself: it simply should be used as an additional factor. If unspoof-able IDs like Bus+Device and PCI id are the same as saved in config and the name is different then consider that device as not favorite to this qube, it simply will be among other devices as it is now.

[marmarek]

Here 001 - BUS number, 002 - Device number.

Those do not identify device itself, but rather where and when it was plugged in. If you want to see yourself, unplug a device and plug it back in. It will get a different device number even though it's the same device. Similarly, the current ID used by qvm-block/qvm-usb is only about where device is plugged in (more or less controller/hub number) - if you plug a different device into the same port, it will get the same ID as the earlier one.

udevadm info --name=/dev/bus/usb/001/002 --query=property

Those properties on the other hand is what device says about itself. And most of those can be trivially spoofed by the device itself. This is for example what USB Rubber Ducky and similar products do. Benign device will present some sensible values, but nothing prevents a malicious device (you found on a parking lot for example) presenting the same thing and hoping it will get automatically attached to some sensitive qube.

[jamke]

Those do not identify device itself, but rather where and when it was plugged in.

I see, I thought those stay the same (like in qvm-pci) until PCI hardware configuration is not changed. Than yes, Bus and device numbers are changed too often to rely on. Unspoofable by device, but not persistent enough.

Those properties on the other hand is what device says about itself. And most of those can be trivially spoofed by the device itself.

Yes, that I understand, that is why I proposed to consider it as an additional factor that can only be considered only as an addition to some unique IDs.

What is the solution in case of usual GNU/Linux? Can it somehow distinguish devices or it is not possible by design (by USB protocol or something)?

[jamke]

Another thought: is it that important to rely on some ID in case we consider adding favorite USB devices in the first place? I mean, if there are favorite USB devices, they still can be spoofed in the same manner, then why use combined favorite device instead of much more convenient per-qube approach I described before?

In other words: What is the advantage of united favorites over per-qube favorites? The latter is more convenient and more error-resistant, and both not secure in the same way. Maybe I do not see something.

[marmarek]

What is the solution in case of usual GNU/Linux? Can it somehow distinguish devices or it is not possible by design (by USB protocol or something)?

Generally no, USB specification does not provide any means for unspoofable device identification. And most OSes do not deal with this issue at all - for example if you connect something that presents itself as a keyboard, it can freely type in commands - that's why devices like USB Rubber Ducky are very effective.

[brendanhoar]

I Like the granularity of "device presents itself as this type" (perhaps depending on Linux kernel in sys-usb to categorize):

• Mass Storage/UASP
• Mouse
• Keyboard
• Security Device
• Network
• Composite
• Etc.

And creating opt-in or opt-out associations with each Qube.

Yes a device can spoof but maybe you want to always block storage devices from your Vault, say.

Possibly also consider a guard in sys-usb that by default auto-disconnects a device that changes flavors (if not already there), unless that behavior is disabled by the user.

Composite devices exist, as do devices that modify their endpoints (as a non-hacking feature) like some of the older YubiKeys.

Just food for thought. May or may not be a user need for this kind of filtering.

B

[jamke]

I have a brilliant UX idea for this topic! At least I would find it very convenient.

How about showing some label or icon "NEW" near device name in the list that

• was not show in the previous time widget was open, and
• was inserted in the last, let's say, 10 minutes.

The device should stay NEW after being shown for the first time for some small time like a minute to prevent it from loosing NEW icon after opening the widget menu fast twice.

Also connecting device to any qube should instantly make the device not NEW.

It should cover the most common case: user inserts device (block device or not) and tries to connect it somewhere. He will instantly find the connected device. And no spoofing is possible if the system can process events of connections and disconnections. When I think about it, I do not know why isn't it a case in all OSes yet. :)

[andrewdavidwong]

Current early prototype: https://design.penpot.app/#/view/94d0bf99-a273-8157-8003-202ca9b178da?page-id=8a7ef8a5-cf6f-807c-8003-2165f016cdc1&section=interactions&index=0&share-id=52961d58-0a92-80c2-8003-285ff4e779c2

Small typos: USB Input Devices -> USB input devices, diable -> disable, Note: in -> Note: In

[DemiMarie]

To @jamke's point, this is something SecureDrop Workstation has discussed a lot (is there any way to "remember" devices that are always attached to certain VMs to make a user's life more convenient), but basically, devices can lie or represent themselves badly, so it seems like a risky idea. It might be OK if you were treating all your devices as default-untrusted and just deciding which untrusted environment to dump them into, but as soon as you are trying to do that to identify trusted devices (and presumably autoattach them to more trusted VMs) it seems risky.

The only unspoofable information about a device is where the device is plugged in. FIDO2 security keys are an exception because of attestation.

[rocodes]

The only unspoofable information about a device is where the device is plugged in.

For the above reason (and also because some people's workflows involve different kinds of block storage devices, some trusted and some decidedly untrusted), it would be nice to avoid a redesign that makes any assumptions or nudges the user towards opening all devices of one type in the same qube. (This is a slight counterpoint to what @brendanhoar is suggesting and/or to the "favorite qube" in the mockups, I think).

[DemiMarie]

For certified hardware, I think Qubes should display a graphic explaining where the device is plugged in, which the user can cross-reference against the physical devices currently plugged in.

[moonlitOrca]

Just saw the talk @marmarta gave at the QubesOS Summit today and I love the new device manager idea. My favorite would be concept "Bob" but with all the information concept "Alice" supplies available on mouse hover.

It's brilliant work in the mock-up :). I also like the idea I saw @jamke suggested above about including a marker for "new" devices since the menu was last opened or in the past few minutes.

[marmarta]

After a lot of exploration of feasibility, portability to other desktop environments or Wayland weirdness, I figured out that a big part of this approach was not great - menus, as an object type, are not made to be so fancy. We can extend functionality in widget menus, but this remains badly discoverable and awkward to use (also awkward to use without a mouse). Thus, an upgrade of the plan:

• add all the fancy extended device widget functionality from designs above to the qubes menu (as a separate tab, but also available from a qube, if you select a qube and want to attach stuff to it), which has space and functionality for that and would ideally allow the user to see all the needed stuff in one place (yes, this needs much more improvements to menu filtering etc., which will come, I will not do the repeat of qubes manager fiasco with removing functionality before a reasonable replacement is working well), and hopefully at some point sunset the device/qube widgets.
• improve backend stuff, like "how block devices work"
• improve existing widget with minor functions like latest qube used, better attach/detach UX, but not the complex visual redesign of the main list (because there are limits to what can be crammed into a menu)

[DemiMarie]

After a lot of exploration of feasibility, portability to other desktop environments or Wayland weirdness, I figured out that a big part of this approach was not great - menus, as an object type, are not made to be so fancy.

Can you please explain? Menus that are rendered out-of-process are indeed limited, but I assume that the devices code would render the menus itself via GTK.