DispVMs should have red label, not inherit color of parent VM

[mfc]

Opening files in DispVMs from other running VMs should have a different color border (red) or the option to be so.

The user is opening the file in the DispVM explicitly because they do not trust the file. In addition, it may seem at a glance to be in the same VM rather than a separate, disposable VM since it's the same color.

It is especially counter-intuitive because the system notification upon opening a DispVM is the icon of a red lock.

[marmarek]

I think this is good idea. @rootkovska do you remember if there was any specific reason for inheriting label from the calling VM (and if this reason is still valid)? I can't find such information anywhere (neither blog post nor commit message introducing this feature).

[rootkovska]

This is not a good idea. Consider e.g. user opening an office file she got from a business partner which is under NDA, and which generally is considered part of the sensitive work-related activities, normally handled by VM(s) which got, say, green or blue labels - why should this document be suddenly displayed with a red border?

Not to mention that in Qubes we have - so far - struggled not to force any a prior interpretation of the label colors, leaving those up to the user. If we now forced DispVMs to be of particular color, sat red, we suddenly break this color-neutralism.

IMHO the DispVM should get a striped border (in the alternating original VM color and white). Technically-wise, we should have guid exposing an attribute to the Window Manager decorator telling it two things:

1. The label of the original VM (or none in case the user started it from the AppMenu)
2. The fact that this is a DispVM.

The decorator then should, based on these two information, draw the best decoration - striped, or somehow different.

[mfc]

Not to mention that in Qubes we have - so far - struggled not to force any a prior interpretation of the label colors, leaving those up to the user. If we now forced DispVMs to be of particular color, sat red, we suddenly break this color-neutralism.

This is not true, see:

It is especially counter-intuitive because the system notification upon opening a DispVM is the icon of a red lock.

There should certainly be an option for the user to define how they would prefer disposable vms. However in the current state (only one disposable vm at a time, no menu options to customize this), it needs to be red.

In our training/workshops at IFF this week, people were confused why the dispvm was not red, given that their primarily purpose is to deal with untrusted files. (same reason why a browser for visiting untrusted websites should be red.)

Adding another layer of information (stripped, etc) can be something to think about in the future, my understanding is that we do not have that ability currently.

[rootkovska]

We should change the icon shown in the system notification [*] - that's the actual bug, yes.

[*] To correspond to the color of the parent VM. In case of a manual start from Dom0 Appmenu we might leave red.

[mfc]

Please note as previously mentioned the confusion did not come about because of the system notification, but because of the expectations of the user given that red is communicated to the user to mean untrusted, which is the purpose of disposable vms. As you note, the DispVM entry in the AppMenu is red.

@bnvk can you input any thoughts you have on this from UX perspective?

Shall we can ask qubes-users list to get others' thoughts?

[bnvk]

Not to mention that in Qubes we have - so far - struggled not to force any a prior interpretation of the label colors, leaving those up to the user...

I think this is a significant misstep in the current implementation. Common wisdom / practice in good UX is standardizing colors to express properties (the green vs. red SSL lock), or communicate outcomes (green = confirm, red = deleting of data). This works very well in user testing.

What does being "ambiguous" in the meaning of our colors really gain us? Does it somehow make Qubes more intuitive & usable somehow? AFAICT, the only gain is allowing a certain margin of users (usually power users who like to tweak everything) the gratification that they can chose which colors represent what as per their bespoke understandings. The cost of this (feature) is having a standardized interface that we can refer to in our documentation, trainings, etc... as @mfc encountered in Valencia studies!

Which approach scales to support larger user base of less technically inclined users? Since we are assigning colors by default with preconfigured Qubes VMS (and especially once we start to introduce recipes), why not standardize what colors mean? And course, allow technical users to still change colors from the CLI / in an advanced panel.

IMHO the DispVM should get a striped border (in the alternating original VM color and white)...

However, I do highly agree with Joanna here, that opening a document in a Disposable VM from another VM, that color should persist- but adding a striping, icon or other decoration is the right way to go!

[qjoo]

I'd love to finally see this (not inherited colors) or at least an option to opt-out.

[rootkovska]

@bnvk: it's generally difficult to come up with a meaningful one-fit-all standardization on colors. For different people, especially in different cultures, the same colors would mean completely different things. E.g. AFAIK, red is actually considered as peaceful, joyful by Chinese, while for western people it's naturally associated with danger or failure.

But, even if we wanted to come up with some standardization - e.g. for a given pre-configured Qubes edition (pre-configured via our Salt Mgmt stack), this all could, and should, be done by still keeping all the actual code (the "core stack") color-agnostic.

[bnvk]

@bnvk: it's generally difficult to come up with a meaningful one-fit-all standardization on colors...

Definitely. I've heard that about Chinese and red... yet, they also seem to make their stop signs red for some reason. That said, since we are using colors, we should at least use standardized presets that are culturally relevant.

But, even if we wanted to come up with some standardization - e.g. for a given pre-configured Qubes edition (pre-configured via our Salt Mgmt stack)

Yes, that's exactly what I mean by agreeing to standardize at least one interpretation and use of colors. Perhaps we could even have different presets that get picked depending on the locale a user chooses during setup?

[mfc]

So I agree having different color-presets for the user would be great, and for them to be able to choose the color of disposablevms. Those are great future-things.

For this ticket, it's about deciding how untrusted actions are currently communicated. Let's acknowledge the different use-cases for dispvms:

1. opening an untrusted email attachment in Thunderbird
2. open an untrusted file in Nautilus in order to edit it
3. open an untrusted file in Nautilus in order to view it
4. open an untrusted web browser from the KDE Start Menu in order to visit an untrusted website

For all of these cases, the user is interacting with untrusted files or websites. For workflow reasons I could appreciate 2. potentially not being the default-untrusted-color if that might be confusing. Otherwise I can't think of reasons for them not to be the default-untrusted-color, which in our current color preset is red. In all of our documentation, examples, screenshots, we use red as the color for untrusted actions.

Going into the future, it would be great for the user to be able to change the color of DispVMs to their favorite untrusted color (maybe as part of changing color-presets).

Also, it may be worth thinking about having a dedicated color for disposableVMs, that could not be assigned to other VM? Like nothing else can be red, only disposablevms. Then it would always be clear to the user that a window/app was a disposablevm, and not some qube the user had assigned the same color.

[marmarek]

In your list, points 1, 2 and 3 may not only mean that the document is untrusted (as "make contains some malicious code"), but at the same time may be confidential. In fact it may be majority of cases for some users

• otherwise you wouldn't use DispVM - if source VM doesn't contain sensitive data, there is no point in guarding it by opening files in DispVM.

That said, lets see what border colors are good for. I think the answer is to easily get window trust level, defined as how sensitive data I'm willing to share with this application. So if I get some password prompt with red label, I'd really careful entering anything there. But if the same password prompt is green, I'd spend probably much less time thinking about it.

Now, if I open a confidential document from "green" VM, probably I still don't want to share all the other data from that "green" VM with this document (especially passwords). This is why I open it in DispVM. This means that DispVM should have "less trusted" color than the source VM, to easily come up with that decision (what data is safe to enter where). If I want to share with that document anything that is stored in the source VM, I'd simply open that document directly, not in DispVM.

I think some more meaningful info would be source VM name (DispVM named "disp-work7", "disp-personal2", etc?). Because even if I have "green" DispVM (as its currently implemented), I still need to know which of my sensitive data is safe to share with such DispVM. Lets assume I have some confidential reports - two of them, from unrelated projects, stored in different VMs. Lets assume both of them are "green". Now I'd really like to not mix them up, when have both of them open at the same time...

Back to the topic: I'm for having DispVMs red by default. Until implementing some better mechanism (striped borders? more descriptive DispVM names?).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Let's acknowledge the different use-cases for dispvms [...] For all of these cases, the user is interacting with untrusted files or websites.

FWIW, a very common use for DispVMs (as frequently reported on the MLs and in my own experience using Qubes over the years) is actually to visit trusted websites (and, somewhat less frequently, to work with trusted files). This is because using a DispVM is often the best way to ensure that the user's environment isn't already compromised (e.g., from a previous browsing session). There are even some users (e.g., 7v5w7go9ub0o) who go as far as to never run any programs in persistent AppVMs, instead using those only for data storage and running all their programs in DispVMs. So, it seems inaccurate to say that all use-cases (or even most use-cases) involve untrusted files or websites.

[mfc]

I think some more meaningful info would be source VM name (DispVM named "disp-work7", "disp-personal2", etc?)

This is a good idea!

FWIW, a very common use for DispVMs (as frequently reported on the MLs and in my own experience using Qubes over the years) is actually to visit trusted websites

sorry I was imprecise with my words, how about "untrusted environment"? the use-case you cite has the user less trusting something about their environment (their browser in this case) leading them to use it in a DispVM.

In general however in the use-case you cite I think the preferred/recommended way is with appvms, not dispvms, e.g. always using one banking appvm for only connecting to your banking website. I don't think using a dispvm for this use-case should be recommended, since it cannot scale with given current dispvm limitations https://github.com/QubesOS/qubes-issues/issues/866. Also, in the use-case of connecting to a trusted website, if the vm gets compromised once, then your trusted website account is compromised, no? Bank account drained, etc. The threat of a persistent compromise is not very relevant in this use-case.

what are folks' thoughts on a dedicated dispvm-only color? is that a potential third way?

[andrewdavidwong]

sorry I was imprecise with my words, how about "untrusted environment"? the use-case you cite has the user less trusting something about their environment (their browser in this case) leading them to use it in a DispVM.

Exactly. In this scenario, the DispVM is chosen because it's more trusted than the other available environments, which is why it wouldn't make sense to label all DispVMs red (if red means "untrusted").

Also keep in mind that it may not be a matter of "more trusted vs. less trusted," but simply "differently trusted." The user may just want to keep separate accounts separate.

In general however in the use-case you cite I think the preferred/recommended way is with appvms, not dispvms, e.g. always using one banking appvm for only connecting to your banking website. I don't think using a dispvm for this use-case should be recommended, since it cannot scale with given current dispvm limitations #866.

I, personally, don't tend to use DispVMs that way, but I don't see why users shouldn't be entirely free to do so if they want to. A DispVM is just a blank slate. Why do we have to try to tell users how to use it, if their use is legitimate for their needs and desires? (And, sure, if they run up against the limitation of #866, then they run up against that limitation. But I'm not sure why we need to be overly paternalistic about it.)

Also, in the use-case of connecting to a trusted website, if the vm gets compromised once, then your trusted website account is compromised, no? Bank account drained, etc. The threat of a persistent compromise is not very relevant in this use-case.

This is getting a little off-topic, but yes, if the VM gets compromised once, then any intra-session activities should be assumed to be compromised. However, it doesn't follow that the threat of a persistent compromise is not relevant. It might still be relevant, depending on the threat model. (The fact that I will die if I am shot in the head even once doesn't mean that it's irrelevant whether I eat my daily vegetables.)

Besides, it might simply be that there's a website which you don't use frequently enough for it to merit a persistent VM, but it's still sensitive enough that you don't want to log in to it in a VM used for anything else. In that case, it would be natural to use a DispVM on those rare occasions when you need to log in to that site.

[marmarek]

Since we have multiple DispVMs (templates) support in Qubes 4.0, both ways are possible now! By default, there is one fedora-25-dvm, with red label. So, DispVMs have red label (instead of inherited from caller). But it is possible to create additional DispVM templates (AppVMs with template_for_dispvms=True) having different labels and then assign them to different source VMs (using default_dispvm property). So, you can have dispvm-blue, dispvm-green, etc. And thanks to LVM, this is fast and cheap.