Window Title to include Template & NetVM?

General Discussion
1

It would be useful to have the Template and NetVM in the Window Title - especially for dispNNNN VMs, but also for other VMs.

Something like “[<name> from <template> via <netvm>] …”

Has anyone done this or know where it would be done?

2

Hi there. There needs to be a fine balance between what is displayed and what is implicit as not to overload the user. The user should be presented only security critical information.

I’m not sure adding that information to the user will be beneficial as it would overload quite a bit the interface. But I may be wrong. This needs user testing to be sure which is the best approach.

AFAIK the current implementation assumes the user is aware of the netVM and the TemplateVM.

So as long as the intended usage of the Qube is properly defined, the typical user (non-technical) shoudn’t need to have that level of awareness (since it increases cognitive load).

So I think the way it currently implemented is fine. But there could be improvements on traning users (through docs or elsewhere) to help them better define the scope of each qube and its capabilities / privacy expectations.

(I have changed the title slightly for clarity; feel free to change it back if you diagree @QubicRoot )

3

Thanks @deeplow. A few things:

  • I don’t seem to be able to edit the original post any longer…
  • I wanted to edit the “Something like …” to be [<name> Template <template> NetVM <netvm>]" both to be clearer and to correct the field specs to display rather than being gobbled up as HTML tags (which I didn’t notice had happened in the original post)
  • I’ll leave the Title to your call - except, the main purpose of the post was to see if anyone has made changes to the Qubes window title, not to propose an enhancement - wouldn’t want that information/help request to get lost!
  • Regarding the enhancement request aspect, I disagree.
    – For most users, certainly new users, the window color is what’s important.
    – For all users, the window title text quickly becomes something that’s “just there” - never really noticed any longer, so hardly overload.
    – Unless there’s a reason to look at it, in which case the more information the better.
    – I would also argue that both template and netvm have Security implications.
    – A user is likely certainly aware when a VM is started what its template is (although possibly less so if the user has moved away from the full template to minimals). Less likely the NetVM, which is probably more critical. And far less likely when one has many dispNNNNs (obviously non-specific) and other VMs open.
    – I would also argue that expecting the user will remember all this is rather more cognitive load than having it readily available so it doesn’t need to be “mind clutter”. This is one of the basic principles of Time Management also…
    – Yes, template and netvm can both be gotten from the Qube Manager and/or CLI, but that’s extra steps; and in my situation I look for that info fairly regularly.
    – In any case, this is definitely in the “nice to have” bucket - which is why it was an info request, not an enhancement request, at this stage.
4

:+1: I’ve fixed that for you. Editing posts in only allowed on the day it’s posted (partly for security reasons)

Whoops. Sorry about that. Let me know if it is now fine. (removed the “idea”)

Oh totally. That would be very taxing. What I meant is for the user to remember only the purpose (scope) of the qube (not the tech behind it). And the names are suggestive of that: Ex: Work: only for accessing work website; Anon-whonix: for anonymous browsing.

I agree with you that sometimes it’s good to have a quick way to check that. Maybe something like a small :information_source: icon on the window that would display quick info about the qube. Idk.

The way I do this on i3 (window manager) is with a shortcut. When I click it it opens the settings for the respective qube and I can easily see what it is based on. Not as ideal as your idea, but still faster than going to the Qube Manager

See the script "i3-sensible-settings.sh

This based on the qubes-i3-sensible-terminal

#!/bin/bash

##
# Qubes i3 Sensible Settings
# opens the settings of currently selected qube
# if in dom0 open the QubesOS's global settings
##

get_id() {
    local id=$(xprop -root _NET_ACTIVE_WINDOW)
    echo ${id##* } # extract id
}

get_vm() {
    local id=$(get_id)
    local vm=$(xprop -id $id | grep '_QUBES_VMNAME(STRING)')
    local vm=${vm#*\"} # extract vmname
    echo ${vm%\"*} # extract vmname
}

main() {
    local vm=$(get_vm)
    if [[ -n "$vm" ]]; then # in vm open vm-specific settings
        qubes-vm-settings "$vm"
    else # in dom0 open global settings
        exec qubes-global-settings
    fi
}

main
5

I also think that the choice of template and netvm are usually so closely tied to a qube’s identity that the name alone should be enough of a clue.

You can also just incorporate the template and netvm into a qube’s name, if it doesn’t change often. For example, anon-personal-d10 for the personal VM based on debian-10 that uses whonix as netvm.

1 Like
6

Pretty much. That’s what I was trying to argue but you summed it um more clearly.

I like this solution a lot. It has the flexibility that @QubicRoot desires and is already implemented.

For example, in almost all my templates I keep the OS version like the default ones: debian-10-work or fedora-32-media. This helps me notice when an OS is deprecated and I need to upgrade.

7

Thanks @airelemental. Without using up too much bandwidth here, dispNNNN doesn’t covey much identity, and for named qubes I use the (limited) name space for other useful information, so separate, quick access to these info bits would be helpful - the explicit info, not clues. :slight_smile:

@deeplow, it appears your title change may have been the way to go, as this thread keeps addressing the enhancement aspect. I’d suggest changing back, except:

I just coincidentally discovered that this information is available in the Q widget. I never noticed it before because I’m usually blasting through the list to select shutdown, etc. from the pop-out menu as fast as possible. However, this time I was distracted en route & happened to hover just right:

If you hover carefully on a qube’s name, a pop-up appears that includes this info. Carefully means exactly on the qube’s name - not to the left nor right, nor above nor below… Thanks to the dev(s) that also saw the need!

I would still like to know where in the (probably Python) code the window title is set, if anyone knows…

HTH others.

8

You can use named dispVMs (see example). From what I understand, the difference fom a regular dispXXXX is that it doesn’t shut down automatically when you close all open programs in it.

I had never ever noticed this! Thanks! :slight_smile:

Haha. I’m confused. Just let me know what I should change it to.

9

It’s rather more than that. The dispNNNN DispVM is created on the fly, and nuked after shutdown - so completely gone (although not forensically). So there’s not extra space taken up in Qube Manager, Q menu, files, etc…

In addition, multiple dispNNNNs can be created and run off the same DisposableVMTemplate at the same time - not possible with the current Named DisposableVMs.

Perhaps a future enhancement (back to that!) could abandon dispNNNN and instead use the AppVM’s name with NNNN suffix added…

Re. title, I wouldn’t worry about it any more. :slight_smile:

1 Like
10

That’s a good feature suggestion :slight_smile:, but it might make it slighly harder to find the dispVM, especially when qrexec is aking yo which vm you want to target