Do you mean in the new app menu?
I don’t know if you can bookmark whole appvm’s but I can right click on programs in the app menu and an option to bookmark appears
2 Likes
Some quality of life improvements:
- when something breaks and you get a notification, provide a link (in the notification) to where you can see the crash log (or at least allow you to copy the location where the crash report is so you can paste it someplace to access it later). Currently the notification disappears before I can open the terminal and find where it is.
- Incremental backups.
- (this could be me being blind) but better documentation on how to set up power-efficient settings to conserve battery life. I’d be fine with decreased performance during times when I just need to write a document and don’t need to do anything fancy. Especially useful when traveling/not connected to power supply.
- saw this above but completely agree with a reboot all qubes option in qubes manager
In an ideal world:
- ability to hide Xen from guest OS for applications that are not virtualization friendly (like Solidworks)
4 Likes
Some more color options to choose from for Qubes would be great, maybe even having the ability to combine colors in a striped pattern.
5 Likes
5 Likes
Thank you, I see someone was even nice enough to create a script, I am hoping the QubesOS team will implement it themselves in a future release so users don’t have to mess with dom0.
2 Likes
Yep.
It turns out what I wanted to do is handled by adding Nina’s lime and cyan. (I only wanted a couple more colors.)
It’s pretty robust, too; the KDE menu manager software can see the icons; they seem well integrated; the only glitch (and it’s very minor) is that lime and cyan end up at the bottom of the dropdown in Settings and Qube creation GUIs, instead of between yellow and green, and green and blue, respectively. [I also added magenta for completeness though I haven’t got a use for it.]
In those issues, though, Nina actually changed some of the values of the other colors. I might just tinker with those scripts to figure out how to modify an existing color without having to delete it first.
The scripts, by the way, copy the existing orange icons, then pull out the fill from the orange pixmaps, which are slightly different shades of orange, and convert those to HSV. They convert the color value you supplied to HSV as well, and use the saturation and value from the fills to modify the color you passed in to get the fill colors that match the color you’re creating. It then converts that set of HSV values back to RGB and uses them as fills on the icons. Pretty interesting. I have no idea if that’s how Qubes developers actually created the original icons though–nor do I know if that’s what Nina did with her samples.
2 Likes
The “I want more colors” I see multiple times, resulting in various further discussions (with all the pro and against opinions, leading pretty much nowhere), needs an in-depth approach, i.e. it should not be solved by merely satisfying the desire/preference of a group, even that group may be a majority at a certain time.
What I mean is:
Qubes OS is security focused OS. It is not satisfaction focused (Otherwise we would first have GPU acceleration, shiny modern design trends and all that dopamine related business). So, that is the order of priorities, IMO.
That’s why the approach should rather be:
- How to relate the UI to the security concept of Qubes OS. (security first)
- How to improve the UI solving existing issues (main one being, as it seems, the organization of different/many qubes)
Currently the user has 8 colors to choose from + the freedom to select a color and full name. This means the following scenario is possible:
Have a qube named “offline-private” aimed to be used for personal files without network connection. Additionally, one may decide to take extra measures for not allowing copying from/to other qubes. One would probably use green color for that, as green is normally associated with safety.
Now, suppose this qube is changed to have unlimited network and Internet connection and one runs a browser in it. Name and color remain the same but is it still offline and private? Is it as safe as before? Will a tint of green (difficult to distinguish visually) help to improve such situation? Does all this work for or against the whole concept of Qubes OS? Does it satisfy the goal of the user who created the qube with that name and color?
Yes, it is impossible to completely safeguard a user from working unsafely. However, the above situation may be result of a problem (bug/attack), not necessarily of the user being negligent.
That said, I think clear visual cues are necessary to protect the user from his own mistakes and from acting unsafely in a potentially dangerous situation (security compromise). Organizing/structuring one’s work is good, however, if that organization is merely visually pleasing, it works for satisfaction first, not for security. That’s why we need visual ques hard linked to the actual and essential qube properties (e.g. network/offline and others). Those can be icons, borders, colors etc. Everything else (structural and functional organization, labels/tags, naming, etc) which is user editable should be a separate thing. So, two groups of visual ques:
- actual qube properties
- user intent
How to do this, what is appropriate etc. is subject to a longer discussion which does not belong in this thread.
P.S.
The book “Designing with the Mind in Mind” is a good start-up reading.
4 Likes
There are those that want every single one of their VMs to have its own distinct color. And that’s to help avoid doing the wrong thing in the wrong qube. That would be very impractical for me, though, as I have a couple of dozen VMs just at the “user” level (let alone service qubes, etc.)
I actually color my VMs based on “what they touch” so I’m probably not far off from what you want…except I get the impression that you want the Qubes team to make the choice as to what signifies what (if I read you wrong, my mistake and my apologies). E.g., red means qubes that touch wifi (which on my system is the internet). Orange: Usb drives, printers, bluray drives, etc. USB is only slightly more trustworthy than the internet. Yellow: Ethernet (my NAS). I won’t bore you with any more of the list; I think you probably get the idea.
Others will want to organize by what part of their life is involved…this is the way the default installation is set up. Work = one color; Personal = another color. But that seems to run at cross purposes with the service qubes that are colored according to levels of trust.
I’d really be against an imposed solution (if that’s what you’re pushing for; again I am not sure what you are advocating). For one thing, some people are colorblind, and what makes it worse is that there are different forms of colorblindness. [I don’t happen to be, but I have a boss who rightly never lets me forget he is; I have to consider colorblindness in my designs for work.] And OBTW the most common form of colorblindness makes green and red hard to distinguish; the very two colors you’d most want to be able to distinguish if red=danger and green=safe.
On the other hand, you’re absolutely right in thinking esthetics alone shouldn’t be the driver.
4 Likes
There are those that want every single one of their VMs to have its own distinct color.
What one wants is not necessarily what one needs.
Example: One may have a soar throat and want to eat ice cream. Rarely the ice cream would help though.
That’s why I say the approach to this should be in-depth, not superficial.
And that’s to help avoid doing the wrong thing in the wrong qube.
That may be the intent but not necessarily the result (as demonstrated in my previous post).
Your “what they touch” is very close to what I was talking about, not identical though. My idea is more general, rather than focused on specific devices. Think attack vectors. The more “open” the VM to them, the stronger the visual cue warning the user should be. And vice versa.
Example: Based on NetVM setting a qube may have different visual cues (e.g. an extra small overlay icon or other symbol noting that):
- qubes with ‘sys-whonix’ - one cue
- qubes with ‘firewall’ - another cue (stronger warning for the user)
- qubes with ‘none’ - another (safer) cue
etc.
Translated in today’s color labels, that may be:
- red = clearnet
- purple = sys-whonix
- yellow = LAN
- green = none
- black = template
I’d really be against an imposed solution
I am not pushing for anything. I am suggesting something for consideration and discussion in the context of the threat title, and I am providing the basis for that suggestion.
The only suggestion which may be considered imposed (in the sense - limited) is that the set of security-related visual cues must be linked to actual qube settings, not to one’s desire. I.e. it should be impossible to the user to set a “safe cue” (as in a network disconnected qube) to a qube which has a NetVM, and vice versa. What the exact cue would be may be configurable (even theme-able).
And, the second set of cues (organizational), should be just as freely configurable as the colors today.
What would you say?
2 Likes
The cue cold be an icon on the window title bar, then, sort of like the padlock you see visiting https sites as opposed to http.
I could see that working–provided it’s colorful enough to stand out. (These days, of course everything is in black and white outline–it’s this year’s idiot fashion, apparently–and so nothing stands out. In fact the padlock icon I just mentioned is a dippy little line drawing now, easily overlooked especially when absent. Of course, I am making another assumption; that a window will even have a title bar. Given the current fetish for getting rid of window borders, I find that assumption questionable; it’s only a matter of time before someone upstream ditches title bars in such a way that you have to make an effort to get them back.
(Honestly some Linux people are becoming as arrogant about pushing their way, as Micro$haft gets criticized for being.)
Anyhow, I could see such a thing working from the user end…but I can also see it’s probably very hard to accomplish given the way windowing works. Developers are deliberately not given a lot of access to “window decorations” because the theme is supposed to take care of that. Another difficulty of course would be deciding what distinctions to make.
I, for instance, don’t just have a sys-net. I have a sys-net-wifi and a sys-net-ether, and the latter is far more secure than the former; I wouldn’t want the same cue to appear in both places. If the iconography were set up based on the default configuration, the same cue would appear in both places and I’d still have to use color (red=wifi, yellow=ethernet) to distinguish the two. I couldn’t expect the Qubes developers to make the distinction especially when it’s not part of the installed configuration; this configuration is something I had to customize. (I had it going within about 2 hours of the first install.) [There IS a description of this use case by Joanne Rutkowska herself, but it’s not the Qubes default to have separate sys-nets for different networks.]
1 Like
Tbh it never occurred to me that people would switch the purpose of an already existing Qube, just create a new one would seem more secure imo and assign a separate internet tunnel, settings, etc…, but that’s just me and my model.
I really was thinking of a scenario where one is mainly using QubesOS for multiple web browsing sessions for example, which are separated not just on the OS level but also in their own workspace. Say they have 8+ workspaces currently and increasing. Currently 3 or 4 colors are strictly reserved, say which where already used for templates, disposable vm, firewall, usb, net, untrusted and etc… Qubes. that leaves 4 or 5 colors that can be used every time to create a new Qube.
You mentioned the color + full name combination, however the way that I use QubesOS, is by looking at the application window color in a workspace to know what Qube to switch to. On some occasions there may be 3+ of same colored Qube in adjacent workspaces, which then complicates things, even if one were to use all 8 colors, it is not enough.
Not asking for the bells and whistles here, not interested in GPU acceleration, shiny modern design, etc… as I’ve learnt to use QubesOS as it is and I am strictly only interested in improving upon what I am currently, very happy using.
The devs could just add a bunch more colors if it’s not a major task and then figure out in the meantime how to optimize the thought and design, as this feature has been requested since 2016 and still is being requested, and although its very nice that people are making scripts (without QubesOS teams’ blessing it would seem) to achieve this, I feel that is a security problem having users messing with dom0.
I do understand your reasoning and the psychology behind ui/design is for sure important. Using your example on your later post, all clearnet would use a base of red (or any color one chooses) and then for all Qubes based on the clearnet criteria you could add add a secondary colors, I was thinking red stripes with a smaller striped secondary color.
2 Likes
I’ve been following this discussion about colors with great interest, but I fear that it mixes two rather independent items:
-
The colors offered to classify VMs are just a tool to express certain aspects of significance. Offering more than the current 8 colors would somehow sharpen this tool, allowing it to differentiate between more aspects. So, adding some more colors to the palette would just improve the - already very good - UX, and so I am much in favor of this change.
-
On the second level, there is the question of how these colors should be used. There are very good arguments for doing it one way or the other, e.g. in order to differentiate between security levels or levels of connectivity, e.g. types of networks like WiFi or LAN or none at all. Selecting one of these color schemes depends on one’s usage or threat model, or other. Qubes places no restrictions on this usage, and this is a good thing, in line with the freedom of configuration allowed in other respects. There may be even silly usage patterns, but, in Qubes, you are always free to shoot yourself in the foot - or to create a system structure which does fit your needs in a way no one else has thought of. This is just an aspect of the flexibility allowed by this system, making it far superior to rigidly structured systems like Windows.
So, in my opinion, it would be helpful to provide a few more colors but to leave their usage completely in the user’s hands.
7 Likes
The cue cold be an icon on the window title bar
But if it is on the title bar (i.e. seen only after the qube has started), how would that prevent the user from starting a qube with potentially undesired properties? Suppose you expect the qube to be without netvm, you start it and suddenly you find out (through the title bar icon) that it is actually connected to the Internet. That contradicts the whole idea of having qube features tied to (first group of) visual cues. If you had the proper cue before having to start the qube, that would help you not to make a mistake.
I am rather thinking about overlay icons. Imagine the icon of Firefox with a smaller one on top of it (say, bottom left) noting a property (e.g. a green dot, associated with netvm=none; red dot, meaning unrestricted networking etc.) A second dot (e.g. bottom right) might indicate whether the qube is disposable. And so on.
Alternately, it is possible to develop (configurable) visual code, e.g. like a small thick color line under the desktop icons with 3 colors:
- for netvm
- for type (app, disp, …)
- sth else
Then the user will be able to configure one’s own colors (e.g. red=network, green=offline) but the actual display of the color bar will be controlled by the actual properties of the qube.
I, for instance, don’t just have a sys-net. I have a sys-net-wifi and a sys-net-ether, and the latter is far more secure than the former;
In what way? Do you have a thread where I can learn more about this setup?
1 Like
The devs could just add a bunch more colors
Let’s say for a moment you have that. Suppose you even have full control (24-bit color palette), so you can pick your own bunch.
-
How many colors can you actually distinguish?
-
Is light/dark/medium red good enough to separate qubes with different security settings?
-
How good is your monitor? Is it calibrated? If yes - how exactly, using what hardware and software? How stable is the color? (Not everyone uses high end EIZO CG series)
-
What is your room color? Do you move your laptop from one room to another with different ambient color temperature?
-
What if you change/switch monitors or use more than one simultaneously?
-
What is “red”? (No, it is not RGB=#FF0000. Color is defined in Lab color space, because RGB=#FF0000 will be purple-tinted on one monitor (one Lab color) and orange-ish (another Lab color) on another. On some monitors it may be difficult to distinguish cyan from green)
Color is a very complex matter. Security is even more complex.
I was thinking red stripes with a smaller striped secondary color.
Yes. Simple color codes.
It is also possible to have striped (and or solid) icon backgrounds and monochrome icons.
2 Likes
Regarding the colors:
Haven’t read the whole thing, but all the colors/borders thing is way too much to enforce and very distracting for daily use.
A theme without colored borders should be available.
2 Likes
It really should be the users choice at the end of the day on how they wish to use their system imo, they already know QubesOS offers OS level isolation, if someone is into logically securing their system further and has a threat model in place then they will know what to do or know where to look/ask to find provided documentation/information by the team/community. The providing documentation in conjunction with QubesOS to teach users would be a good and useful option for security.
I can’t see how adding a few extra colors could really affect security, unless you already think the setup by QubesOS is bad. If the distinguishing between different colors is a problem then maybe have an option for users to use basic colors currently provided or the advanced palette if the the user can distinguish between colors.
2 Likes
Oh, I suspect I am misunderstood here (and it’s my fault). The qube isn’t more secure, the ethernet network, being otherwise airgapped, is.
[If instead you’re asking about how to set up two different sys-nets, it’s a matter of assigning one device to one qube, and the other device to the other qube on the devices tab. But I figured that’s not what you meant.]
I clearly didn’t understand what kind of cue you were thinking of. But I think the central point is you want some kind of cue that isn’t something the user just sets (like color is in the current system). I was thinking of a title bar thing, but really that’s a detail. The concept still has issues.
My main concern still stands: whoever designs such a system can’t anticipate all use cases. I absolutely want to distinguish which network (if any) I am connected to; if there’s just one cue for “connected to a network” it doesn’t meet my situation. And imagine someone with, say, two different ethernet networks and wifi. They can’t possibly anticiapte all of these situaitons so more than likely there will just be a “connected to some network” cue, because, after all, that’s the default installation: all network access goes through one qube.
2 Likes
My main concern still stands: whoever designs such a system can’t anticipate all use cases.
Now that you say it, I think it is not necessary either. If we just have the functionality to associate properties with visual cues, then each one of us can decide which property is significant for oneself (based on particular threat model), and create relevant visual code. Then you can have your code based on wifi/eth, another may have another based on others.
Example (3-colors code):
(Icon)
[1] [2] [3]
(qube: app)Imagine [1], [2] and [3] are simple color boxes (█) which placed next to each other create a fat color flag between the desktop icon and its descriptive text.
The user associates:
1 - network (e.g. red=sys-wifi, blue=sys-eth, green=none)
2 - type (yellow=app, purple=disp, template=black)
3 - sth else (you still have 3 more colors available)
As you see, even with the current 9 colors we can have many combinations without creating confusion like “light red” vs “red”.
Another user associates:
1 - type, 2 - network, 3 - template
etc.
Nothing is imposed. Even the usage of these color codes can be optional for those who think it is too much and the standard colors are enough.
2 Likes
I can’t see how adding a few extra colors could really affect security, unless you already think the setup by QubesOS is bad.
I explained how. Current setup is not bad, it is limited. That’s why it creates this confusion which many think they can solve by “just having more colors”. Complex systems (consisting of many elements) need to be organized through simplification (e.g. grouping, clear associative visual logic). If you try to fix them by adding “freedom” (which “many colors” is not), you are allowing many ways for security mistakes and that is bad as it is against the whole concept of a secure OS.
If the distinguishing between different colors is a problem then maybe have an option for users to use basic colors currently provided or the advanced palette if the the user can distinguish between colors.
As someone who has done color work for decades, I can assure you distinguishing colors is a problem for many. Not because people are color blind (some are but that’s beside the point) but because human attention blinks, all the time. The good design is the simple one, not the rich one. Remember we don’t have just color. We also have shape, text, texture… So it is much better to combine tools, rather than use just one super heavy tool (color).
4 Likes
shutdown when closing lid option in the settings manager > power manager gui
5 Likes