Add seven new colors

[ghost]

Qubes OS version: R3.2

[grey-olli]

Could anyone point into source where changes to be impemented?

[jpouellet]

Unfortunately there are many places where the current labels are hard-coded, so this is not a trivial task.

I think the master list is intended to be the list in core-admin/core/qubes.py, but simply adding to that list would not be sufficient.

If you wish to work on this, I suggest you start by eliminating the other places in the codebase which hard-code labels. These can be found with e.g. grep -r purple qubes-src from a checked-out qubes-builder repo.

There have also been proposals to add different patterns instead of simply more colors, and I personally think that approach would be more useful for those of us with many VMs.

[unman]

I would defer to those who specialise in user interfaces. I don't. But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours. In Qubes the use of colour obviously has significant consequences.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so. An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour. Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

For these reasons I would argue against the proposal, but as I've said, I'm happy to defer to those who have expertise in this area. There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

[grey-olli]

On Sat, Feb 18, 2017 at 9:27 PM, unman notifications@github.com wrote:

I would defer to those who specialise in user interfaces. I don't. But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours. In Qubes the use of colour obviously has significant consequences.

Currently I can't separate two similar contexts for two different companies neither by desktop bindings nor by colors.

If desktop bindings will be implemented, when some activity cannot appear on same desktop w/ another activity separation will be easier. Though, I'd like to have more colors anyway and hope to have time to get this patched at least for myself . AFAIK I'm not the only person who wants more colors.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.

Agree. Though what are alternatives? When I've same colors for different activities that is not better than have a little different colors.

An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour.

And that "problem" I'd like to keep as a nice ability common for all window managers. :) Guess I'm not alone w/ this.

Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

Software developers can't make users "never misbehave". When you set green phone and can't see green

For these reasons I would argue against the proposal, but as I've said, I'm

happy to defer to those who have expertise in this area. There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/QubesOS/qubes-issues/issues/2523#issuecomment-280890830, or mute the thread https://github.com/notifications/unsubscribe-auth/ALHcA5RVgsg-ccBCOKV2lyNjq-S0tGhwks5rd6ijgaJpZM4LP65b .

-- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal. com/tag/

[grey-olli]

On Wed, Feb 22, 2017 at 8:40 AM, Oleg Artemiev grey.olli@gmail.com wrote:

Sorry - two ctrl-enter sent before I finalized my letter

Currently I can't separate two similar contexts for two different companies neither by desktop bindings nor by colors.

If desktop bindings will be implemented, when some activity cannot appear on same desktop w/ another activity separation will be easier. Though, I'd like to have more colors anyway and hope to have time to get this patched at least for myself . AFAIK I'm not the only person who wants more colors.

Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

When some popup razes on top of current application, most often it is not hovering background - it is hovering current VM window and foreign to Qubes application picture is not what we could control or should alter. Coloring is good to differ popup from some other VM to popup from current VM. There're two color separation context - one VM to another VM and two similar full screen or non-full screen programs opened on difrent desktops.

Software developers can't make users "never misbehave". When you set green

background and can't see green window captions that is not developer problem.

And this doesn't seem to be design problem - programmers allow users delete their data. If user misbehave and deletes his data - is this a developer problem? If developer made a confirmation note - no - this is exactly user misbehave.

For these reasons I would argue against the proposal, but as I've said,

I'm happy to defer to those who have expertise in this area

I'm not sure I'll make a patch, but I'm sure I need ability to separate more contexts than I'm able now. I'm not claiming that should go via coloring - binding VM activities to desktops is another alternative.

There is one change that I would like to see, which I think has been

mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

I guess beter ides is not a single color for those people, but a different "zebra/pedestrian" styles (i.e color blind people are okay w/ contrast and thus should be able to differ a set of black and white shades like "|||||" and " | | | | ",

Note that, by using different workspaces with colour coded backgrounds,

the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

We need strict bindings VM<->desktop from VM configuration in Qubes VM manger then.

Restricting background color for a desktop should be optional - full screen mode windows hide background at all (at least I usually do full screen).

-- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.c om/tag/

-- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[woju]

For R3.2 this probably will remain as is. For R4.0, the list of labels is in qubes.xml and only the initialisation is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/app.py#L852-L861. There is however neither tool nor API to change that, apart from directly editing XML. @andrewdavidwong Is there a reason to change that approach? If not, we can close this bug.

[grey-olli]

On Wed, Feb 22, 2017 at 9:05 PM, Wojtek Porczyk notifications@github.com wrote:

For R3.2 this probably will remain as is.

Means useless to try to make a patch within nearest 2-3 months?

For R4.0, the list of labels is in qubes.xml and only the initialisation is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3- devel/qubes/app.py#L852-L861. There is however neither tool nor API to change that, apart from directly editing XML. @andrewdavidwong https://github.com/andrewdavidwong Is there a reason to change that approach? If not, we can close this bug.

My +1cent: this should definitely be switched from "bug" to "feature request" for 4.0 and got documented. My idea is a standard-looking color picker . If it's too effort-costly to add it in Qubes VM manager - make VM color picker to be a separate dom0 tool + note it in documentation.

-- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

[woju]

On Wed, Feb 22, 2017 at 10:44:34AM -0800, grey-olli wrote:

On Wed, Feb 22, 2017 at 9:05 PM, Wojtek Porczyk notifications@github.com wrote:

For R3.2 this probably will remain as is.

Means useless to try to make a patch within nearest 2-3 months?

For R3.2, yes. This work is already done, so there is no need to duplicate that. And no-one would find that of much use anyway.

For R4.0, the list of labels is in qubes.xml and only the initialisation is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3- devel/qubes/app.py#L852-L861. There is however neither tool nor API to change that, apart from directly editing XML. @andrewdavidwong https://github.com/andrewdavidwong Is there a reason to change that approach? If not, we can close this bug.

My +1cent: this should definitely be switched from "bug" to "feature request" for 4.0 and got documented. My idea is a standard-looking color picker . If it's too effort-costly to add it in Qubes VM manager - make VM color picker to be a separate dom0 tool + note it in documentation.

Not at all. This is intentionally obscure for reasons extensively summed up by @unman. I'd label that "wontfix".

[andrewdavidwong]

We need to defer to the UX experts on this one. Since we don't have any to offer a firsthand analysis of this problem, I'm inclined to defer to @unman's report.

[andrewdavidwong]

For what it's worth, I want to acknowledge that the problem @grey-olli is experiencing is a legitimate one. With a large number of VMs, it becomes difficult to distinguish them, given a limited number of colors. However, it doesn't follow that adding more and more colors (or even building a tool that allows the user to do so) is the correct solution. For the reasons @unman points out, that's likely to backfire and ultimately harm the user instead. This calls for a more creative solution.

[andrewdavidwong]

I've created #2646 to encourage ideas for such a creative solution.

[andrewdavidwong]

Now that we have an actual UX expert around: @ninavizz, what do you think?

[fepitre]

From my point of view, these colors are nice :+1:

[marmarek]

I'd exclude gray and possibly white, to avoid problems like #3471

[fepitre]

Yes I agree. Also, as far as I can see in the components, it would be easy to implement these colors.

[marmarek]

@kschubitz thank you for working on this! If you want to play with it, the backend is already implemented. Adding new labels is already possible with Admin API directly. Adding:

echo -n 0xRRGGBB | qubesd-query dom0 admin.label.Create dom0 LABEL_NAME

(replace 0xRRGGBB and LABEL_NAME with actual values)

Removing:

qubesd-query -e dom0 admin.label.Remove dom0 LABEL_NAME

(replace LABEL_NAME with actual value)

As @jpouellet said, labels are hardcoded in many places. But since introduction of Admin API, we consider it a bug, not intended design anymore. So, it would be good to at least collect list of places that still use hardcoded labels.

Quick test of the above reveals some problems:

• [ ] appvm-LABEL.png and dispvm-LABEL.png icons (/usr/share/icons/hicolor/.../) needs to be created, otherwise:
  • domains and devices widget crashes
  • qube settings does not show icon in label drop down
• [ ] icons in the menu are not adjusted for the new color (not sure if related to missing icon, or something else)

[ffsec]

I already thought white would be a bit or a problem and needs some special handling but I still left it in there for discussion, maybe it could be useful in combination with black/dark themes/backgrounds.

Regarding icon colors:

Unfortunately the current coloring method is resticting the number of distinguishable colors, since each color is supporting a wide range of alpha levels. So a black VM is having grayscaled icons while a "Navy" and a "Blue" VM would have a very similar icon coloring. The question is: Is this really a problem?

When it comes to the menu (Alt+F1), I don't think the icons have to be colored at all. First of all the containing qube is selected on the left side and second the qube name is also part of the shortcut name (i.e. "work: Firefox"). Coloring them is okay but does not need to be very precise IMO.

The same goes for the Application Finder (Alt+F3).

As for the Application Switcher (Alt+Tab) the vm name is also displayed as title. As for coloring wouldn't it be possible to modify the switcher to show the corresponding VM color as a border or even the whole background of each box? Something like this:

I can't say much about the tray icons, is it even possible for VMs to add an icon there by themselves? So far I've only seen the red networking icon from sys-net. Also if hovering the icons, the showing tooltip window has the corresponding border color, would that be enough for identification when in doubt?

[marmarek]

As for coloring wouldn't it be possible to modify the switcher to show the corresponding VM color as a border or even the whole background of each box?

That may be a good idea. But also may be quite hard to maintain, specially if we'd like to have this in all the supported window managers. Application icon is something that each application switcher already support (so, no qubes-specific patching is needed), but custom background isn't.

[brendanhoar]

That's nice. Does qubes configure or does the window manager configure the color of the font in the window header?

[marmarek]

Does qubes configure or does the window manager configure the color of the font in the window header?

It's window manager - you can choose color scheme in window manager settings, but the same will be used regardless of border colors :/

[marmarek]

Is there an easy way to change the color of an existing label without having to remove and recreate it?

No, and this is intentional. To avoid confusion if you create VM with label X and then suddenly (without changing it's label property) it change its color.

Also, how do you read the current color value of an existing label?

admin.label.Get - see https://www.qubes-os.org/doc/admin-api/

"admin.label.GetColor" and "admin.label.SetColor" would have been useful here.

Another problem I ran into is that I can't remove the standard labels via admin api, even though they are not assigned anywhere: ValueError: invalid literal for int() with base 10: b''

Forbidding removing default labels is intentional at this stage - for similar reasons as the above (although we may consider allowing this). But error reporting is clearly wrong here.

Just finished implementing the new colors and they look really nice imo.

Indeed looks nice!

1. Icon/Shortcut colors

We've evaluated (back in 2013) different algorithms for painting those icons: For each color, from the left:

1. original icon
2. tint 50
3. tint 90
4. tint 100
5. HLS (L from the icon, HS from the label)
6. HSV (V the icon)

Currently he use number 5.

Alternative idea is to preserve original icon color, but add an overlay with colorful padlock in a corner.

2. Another issue is the themes

We already automatically generate color palete for KDE (since it supports setting color palete per-window, this is how colorful borders are achieved there). See https://github.com/QubesOS/qubes-desktop-linux-kde/blob/master/plasma-breeze-qubes/qubes-generate-color-palette XFCE is not that flexible, but we probably could convert those themes at build time.

3. New label icons (in Qubes Manager): Currently colored locks are used.

I'm not attached to padlock icon specifically, but IMO representing "being encrypted" (whatever that would mean) with a different icon is bad idea. Why this property specifically? And not for example "being network-less", or "being standalone/template-based"? If changing icons at all, I'd rather think letting the user choose custom icons would be a better idea.

4. It's not possible to delete the current standard labels using admin api, so I was unable to create a working "update" script which replaces the old labels with their counterpart. So the question is, how would the update process look like?

As I said, this is intentional, at least at this stage (API for defining new labels is rather PoC). Besides avoiding confusions like green label having name "red", this is also important for pre-defined configurations (salt-based or else) - to be able to assume existence of some basic labels. Otherwise each configuration, instead of for example creating yellow "personal" qube, would need to also possibly configure own labels - which may lead to big mess. It may be possible to lift this limitation in Qubes 4.1, but definitely not in 4.0.

5. Since the color of the window title is for every label the same, we could add a second color or at least an indicator for light/dark text color to each label. 

Alternatively window manage could have some detection for light/dark borders and automatically choose dark/light text. Not sure which one is better.

But that would be a new (open) issue.

Yes.

[marmarta]

I love the new colors, and the idea of getting rid of padlock as a VM icon and instead just using a rectangle. It would definitely be easier to distinguish in a menu for people with bigger resolutions and bag eyesight (like me: to be honest, telling apart blue, purple and black padlocks is... not easy). As far as themes go: they don't change very often or at all (from looking around XFCE repo, last changes were made around 2014). Editing their files is fine, and maybe this would be a good occasion to decide which themes are supported and which are not (this is always a problematic issue, because even some native xfce widgets don't really handle all default xfce themes that well).

[andrewdavidwong]

Also (imo) many of the standard themes look outdated, almost like a trip back in time. So while we could possibly provide fixes for all of the current standard themes, I'd rather only keep those which are working fine with the new windows coloring (plus a few manually fixed ones) and additionally create a few Qubes themes, which are intentionally designed with Qubes in mind. One of these could then be the default Qubes theme.

Maybe we could get a little poll or something going to see which themes are actually used?

You could make a poll using some website (e.g., doodle, straw) and announce the link on qubes-users. I'm not sure how representative the responses would be, but it'd be something. You could also try it the old fashioned way by recording replies, but that might be more cumbersome.

Personally, I value having a nice dark theme. I currently use "Adwaita-dark" for this, but any nice dark theme will do for me.

[ninavizz]

Hi team! I'd like to suggest a simple "cube" icon different from the Qube brand icon, to represent the VM. The lock semiotic implies unique security properties, so when EVERYTHING has it... it's confusing. Likewise, recognition of branded apps is made much more difficult when the app icons are colorized—which I feel negates the value in doing that.

This is a sketch I did a few weeks ago for the Qubes menu (that I'll open a separate Issue for) that shows what I feel would be appropriate "Cube" and "Template" icons (and a few others), given various cognitive limitations with parsing such small patches of information:

P.S.: I finally got my own Qubes machine, and would love to become more engaged with ux stuff for the project, overall. Icon design, especially, as that's very specialized... and I kinda feel the Gnome icons are far too complicated, often times symbolic mis-matches to intended mental models, and can be difficult to visually parse when so small in Qubes.

Only adding this comment to this thread, as I found the Issue when looking for something else... and I saw the convo topic delve into this.

[brendanhoar]

Hearty LOL at the purple VM.

[marmarta]

I love those qubes so much, and the whole menu arrangement is just magnificent! @ninavizz , if you the icons in .png for that I'll implement them immediately, it's just the best.

[ninavizz]

@marmarta Hooray!! I can get you these icons as PNGs, later in the week. I need to catch-up on SecureDrop stuff Monday & Tuesday so those guys don't start to resent introducing me to Qubes... cuz, hehe, I got a bit distracted with this stuff later last week. :)

[ninavizz]

To discuss in a Q1-2020 UX Meeting #5523

[ninavizz]

So: An honest question I have... WHY do users need such an excess of pre-configured VMs?!

I appreciate that Qubes is all about compartmentalization... which has great security value, etc.

I feel like a much bigger question than the menu or Qube manager design, is educating users about value vs self-imposed burdens, for simply having too many pre-configured VMs.

A follow-up question: if it could be made easier for a user to create a VM in-the-moment for a specific task, that is then never "saved" to be used later (so, the core functionality of a Disp-VM) could that address the hyper-proliferation of soooo many VM Domains, Templates, etc.?

@ffsec I appreciate how Linux systems traditionally offer users the ability to customize everything; unfortunately, that creates more usability problems than it solves for, much as each implementation solves for one problem that a few users agreed was a problem. Likewise, Qubes is a tiiny team—so minimizing dev effort on UI changes that pack the most bang for the effort invested, is really important.

Reading between the lines of your described problem, it sounds like a more globally applicable fix that could benefit all users, would be how to more smartly utilize space within an App menu. Secondarily, I'm questioning the use of interaction patterns and nesting options for exposing users to nested hierarchical items.

[brendanhoar]

Number of VMs (average and/or high-tide) really depends on the use case.

The general case is a person migrating to separation of their inherent persona into security domains to protect more sensitive data (financial/personal) from more “purposely public” (social media), tracked (search engines/ISPs/ad-networks) or extorted/leveraged (malware) issues. Probably doesn’t need a lot but you never know.

Other use cases may be:

1. an activist/operative who purposely builds and executed several personae that are not her. Some may be long term (not throw away). Some may be intentionally exposed to tracking. Requires quite a few VMs and possibly customized templates.
2. Malware researcher bisecting different VM setups against a strain to look for changes in behavior or resistance to attack. Same.

...

Anyway, since user-controlled grouping of VMs into sub-menus doesn’t seem to be in the cards with Qubes out of the box, I’d personally settle for putting all templates on one sub-menu and all dvm-templates in another submenu with everything else in the main menu with disposable VMs at the top and regular VMs following.

B

[marmarek]

So: An honest question I have... WHY do users need such an excess of pre-configured VMs?!

Preconfigured VMs are here to show some example, yet useful configuration. To teach how tools that Qubes gives can be used. In short:

1. sys-net, sys-usb, sys-firewall, sys-whonix - system domains, normally user don't need to interact with them in the menu (but in network applet, device applet etc)
2. templates - Debian + Fedora to satisfy both religions ;) and generally to show user is free to choose distribution they like(*), plus Whonix for those needing hardened Tor access; again, templates are mostly needed directly for installing software and updates, otherwise could be hidden
3. anon-whonix - default Whonix Workstation - the one VM user use to interact with Tor using Whonix
4. default DisposableVM - a starting point for DisposableVM
5. work, personal, vault, untrusted - actual example user domains

(*) we get really a lot of complains like "Qubes would be great for me if only it was using distribution X"

For some longer explanation, see this post: https://blog.invisiblethings.org/2011/03/13/partitioning-my-digital-life-into.html

[brendanhoar]

@marmarek / @ninavizz - it was unclear to me if “excess pre-configured VMs” meant to convey a) excess “out of the box” aka “default” VMs or, instead, b) excess non-disposable aka “customized” VMs.

[xaki23]

Compartmentalization does not necessarily mean that you have like 1-2 template VMs (which have tons of packages installed for all possible use cases) and a hand full of VMs to only separate the actual user data. From an IT-security point of view, it's great if you can limit the attack surface of each VM by creating templates with only the required packages and nothing more. It's basically having as little packages installed as possible for each use case. Counting work related and private templates and also their corresponding vms/qubes, the numbers increase quite fast.

actualy, even if you are not part of that "computers are more secure without a compiler installed" cult and just have one massive fedora-30 template, separating VMs can be a really good thing.

as in, split work into work-outer and work-inner (with access to internal networks) first. the work-o VMs can be few, like just a worko-browser and worko-ssh + worko-agent. but worki can be useful to split a lot more. so worki-access (which contains the vpn client or dot1x credentials needed for internal-net access), then a worki-firewall vm, then worki-appvms, with appvms split into browser (multiple for separating access to purely internal pages like HR, lunchsystem, monitoring, but a separate one for externals like vendor pages, depending on how work comms look a separate browser VM for chats), ssh-client + ssh-agent vms, and the usual 3-5 VMs needed for moderately secure email (mta (multiple depending on setup), mua (without network), gpg), plus vault vm(s) to keep the gpg/ssh key material. multiplied by platforms/divisions where needed.

thats the basic reasonable qubes-work setup in my usecase. before considering build vms, forensics, sniffing and other adhoc/disposable stuff. or the similar priv- and dev- hierarchies / vmchains.

otoh afaiac, the whole debian and whonix stuff is just clutter than can be removed from ISO and defaults, the few-and-far-between wingnuts who use stuff like that can just install it after base install, right? (hint: i am not suggesting to change any defaults, but considering four default/example VMs an "excess" is a rather amusing focus on a very limited usecase with a hint of trying to dumb down qubes in a futile attempt to make it more digestible for people who should get a mac instead. please lets not do that.)

now please back to the whole "coming up with a good set of colors" topic, because thats something really good and a lot harder than it seems at first. and i very much appreciate the work on that.

[ninavizz]

It seems like a core problem that needs to be solved in order for this Issue to find an elegant resolution, is: WHO are Qubes users, quantified. Not just "who actually uses Qubes, today" but from a product strategy POV the project leads need to make a clear decision around who to optimize the product for—and to base all decisions around that.

Digital forensics analysts, gov ops employees, our parents, FinTech workers, journalists, sex workers. Hackers. Who uses the product today, vs who does the team want to use the product, tomorrow? What will help make the project at least revenue-neutral?

When everyone's a priority, nobody's a priority. I feel this issue needs to be put on hold until some concrete decision-making happens around product strategy and well-defined, prioritized user personas.

[cheznewa]

I Created A Script For More Colors :::::::::::::::::::::::::::::: https://github.com/cheznewa/MyGist/blob/master/morecolorqubesos.bash

[ninavizz]

@ffsec shared:

A good example is: https://sashat.me/2017/01/11/list-of-20-simple-distinct-colors/

A number of folks are requesting more colors on the current app-menu survey. I honestly don't see the exploratory work around aesthetic devices to help distinguish security that could then result in a rich new custom window something for Qubes being developed, happening anytime soon. Re-considering this, now, and thinking that a number of the above colors could easily be adopted into 4.2. It'd be about 8hrs of me creating Qute Qube icons for the below, to get to @marmarta.

Off the cuff, all of the ones from the above list except for Brown, Beige, and Teal, seem good. Those colors I exclude, mostly because they are either too similar to other colors, or just ugly. That would yield 18 colors, total. Quite an upgrade, from today's 8. Or, a segment of those colors.

Thoughts?

It would also help accessibility and distinction of windows by color a lot, if a custom XFCE window theme for Qubes could be created and ship OEM, per #6414. Or with 4.2 just upgrade to a Gnome manager entirely. The new AppMenu will be getting done with GTK, I think.

[ninavizz]

Laughing with you, @ffsec. I appreciate the exploration, a lot—and doubly appreciate your sharing the 2y/o adventure, here, for others who might be keen to take this on (I'm not a developer).

I also did a similar exploration before opening #6414 ... and found that between the focus/background states that most of the XFCE themes impose upon their window styling, as well as overly busy control icons on most of them, and my own bias against the weird gradients and rounded corners on most windows in their themes, we really need a custom XFCE theme for Qubes.

Separate from the coloration stuff, is also the legibility of window texts. I love the idea of giving users control of their own colors, as that would also enable colorblind folks to work with their own unique impairment/ability. But that would require the window manager to then be able to recommend a high-contrast color for the text, that would work in both focus and disabled mode. I can think of many ways to "cheat" that with background gradients and blocks, but then those detract from the colored frames—and we're back to the same issues that exist with existing XFCE themes.

[andrewdavidwong]

Since @ninavizz has opened #6752 for adding three out of the desired 10 colors and is leaving this issue open to consider adding the remaining seven, I've updated the title accordingly. See https://github.com/QubesOS/qubes-issues/issues/6752#issuecomment-872694564.

[arkenoi]

Custom label names and icons would be nice to have in 4.2 as well!

[ninavizz]

It is on my to-do to make the icons and post them here (and on the other issue) as I'm able to. Unless someone wants to take on this issue now in which case I'll make all requisite assets pronto! The label names imho should match what is in the color chart (and reflected in the Figma). The master file for the Qute Qubes in Figma is here. Cutting the art will require a small amount of fine-tuning on my end, so as soon as someone is ready to take this on pls just let me know!

[cheznewa]

i hate a service required a sign up to all action access, @ninavizz you can upload your work ("Qute Qubes") to internet archive or openclipart (public domain) or in this platform? please.

[arkenoi]

Also, could anyone explain why our Red / Black usage is a reversal of the traditional Red / Black signal lines concept? For years before, "Red" was "classified sensitive" and "Black" was "clear to connect to transmitter because it is encrypted already".

[DemiMarie]

Also, could anyone explain why our Red / Black usage is a reversal of the traditional Red / Black signal lines concept? For years before, "Red" was "classified sensitive" and "Black" was "clear to connect to transmitter because it is encrypted already".

Qubes OS follows the Biba Integrity Model much more closely than it follows the multilevel security model. “Red” means “danger, do not trust” and “Black” means “safe, you can trust this”. Qubes OS does not attempt to prevent covert channels, as this is not practical on commodity hardware.

[andrewdavidwong]

Also, could anyone explain why our Red / Black usage is a reversal of the traditional Red / Black signal lines concept? For years before, "Red" was "classified sensitive" and "Black" was "clear to connect to transmitter because it is encrypted already".

Officially, Qubes takes no stance on what the colors mean:

https://www.qubes-os.org/doc/getting-started/#color--security

Most Qubes users associate red with what’s untrusted and dangerous (like a red light: stop! danger!), green with what’s safe and trusted, and yellow and orange with things in the middle. This color scheme also extends to include blue and black, which are usually interpreted as indicating progressively more trusted domains than green, with black being ultimately trusted. Color and associated meanings are ultimately up to you, however. The system itself does not treat the colors differently. If you create two identical qubes — black and red, say — they’ll be the same until you start using them differently. Feel free to use the colors in whatever way is most useful to you. For example, you might decide to use three or four qubes for work activities and give them all the same color — or all different colors. It’s entirely up to you.

[ninavizz]

A recent survey was done to understand how people use colors in Qubes, and it affirmed that indeed use of colors is all over the place. Some people follow the model Demi proposed above, but many also just use it to "theme" their qubes; like, cool colors are personal and warm colors are for work. Stuff like that. Hence, the addition of new colors needs to follow a model of adding colors more distinct from each other and other colors, ahead of anything else.

@cheznewa Are you interested in taking this work on? Yes, I will be cutting and sharing the final art files, here, in this issue—with no expectations that others create Figma accounts (you also don't need an account to access or work with the above file). I still have work to do on my end to finalize the artwork, and because that is many hours of work and I'm juggling many things, I've made the request that folks interested in taking this on let me know, here—which will hasten my attending to this matter. ALL of the qube colors will need to be updated, with updated art, when these new seven new colors go live—so it's not a small task. I'd be delighted if you'd want to take it on tho, and I thank you in advance!

[Willy-JL]

For anyone who wants to add their own colors while this is still a work in progress, I made my own script that lets you add custom colors and (unlike the other script floating around on the internet) also automatically generates the appropriate icons for all the different types of VMs, in all the needed sizes and even in svg. You can find it here