with the Whonix logo and then maybe in the bottom right corner something like “Whonix Workstation persistent” and respectivley for live mode and the gateway.
Checking if we run live or on the gateway or workstation is not the problem. I’ll take a closer look at the other points.
If we can check if the current wallpaper uses another image than the one we officially would use we could prevent changing it back in case the user has set a custom one. Maybe a similar check could be made e.g. check if we run on 13 and just don’t install the package. However, this would also mean you can’t easily distinguish between live and persistent mode. During some (or all?) of my tests upgrading 13 to 14 the background changed anyways. As far as I can remember also during some normal non-whonix upgrades between debian versions. So it is something which could be expected.
Not easy to have such exceptions and consistent packages as well as carrying this around for further versions. The package always being installed on Non-Qubes-Whonix makes most sense. Non-issue however, as per below.
Alright so for major upgrades changing the desktop wallpaper is acceptable. However, we should make sure that package upgrades later on won’t change any custom wallpaper away. The ischroot method should provide for this perfectly. That would fit perfect into whonix-gw-kde-desktop-conf.
grub-live package (since optional in Whonix 14) can have independently its mechanism to change desktop background. The above mechanisms would still be sane to have. Would somehow conflict with users changing their desktop wallpaper and setting to turn this on/off does not seem ideal either. Not sure how users could best be notified about running in what mode… Perhaps ask in grub-live thread or new forum thread?
Regarding the threat, how relevant would that be if we use our own wallpaper? The user has to trust the Whonix, Debian, Linux Kernel … devs anyways.
Tails once had the option to make it look somewhat like Windows though it was abandoned because (afaik) no one wanted to maintain it and I’d argue if this would have been a pressing issue this would not have happened.
Tails, Whonix and the average linux distro don’t look like Windows anyways. If you think using Whonix would raise some eyebrows you could say the same about the torbrowser. Not sure if Tails changed the look of the browser back then.
That’s a valid point. Now its a question of maintaining an extra package which we can avoid by just using one from the default selection which is quite aesthetically tolerable.
For example with some KDE problem, the KVM VM does not occupy the fullscreen. It will be a while before fixes come to Debian stable. A custom wallpaper will probably need to be tested to make sure it works for both resolutions (the normal one and the reduced one). Doable but up to you.
As for the shoulder surfing threat - we already have a Whonix logo in Tor Browser. So it already applies I think.
Changing the wallpaper for live mode would imho make only sense when if we use custom images since otherwise we would still maybe run into the issues mentioned by HulaHoop but only for the grub-live package.
If we use upstream images I’d go at first for some icon on the taskbar which would always be present and if this is not easily scriptable for something with notify-send which the user needs to click away.
notify-send however is easily overlooked. (Would still be acceptable though.) Tray icon sounds so much better.
Perhaps this could even be integrated into sdwdate-gui (but then renamed of course). Wondering anyhow if Tor status (and things such as live mode) should get a separate systray icon (probably not liked by Qubes) or if sdwdate-gui could be removed and serve as Whonix systray.
On the other hand too many things in one application can also be weird. grub-live is a Whonix-independent package.
Is it really necessary to use this during the build process? You could also just put a script in the KDE autostart folder which checks if it is running on the workstation, gateway, live …
This draft does what it should do. Path to the images should probably be changed.
Edit: I also have a version of this lying around which checks if a custom wallpaper is set and then does nothing. Will post tomorrow.
Version 2 of the script is here .
BUT it does not work in a reliable way! KDE is buggy. Not sure if it is the one mentioned here: https://docs.kde.org/trunk5/en/kde-workspace/kcontrol/autostart/ and there is some kind of race condition. It only works when the VM has a high amount of RAM and multiple CPUs assigned. Otherwise it fails consistently for me. Executing the script always works when the desktop has finished loading but of course it makes no sense to do this manually.
True. Alternative would be some extrapackage which gets installed during the updates. Or add it to an existing one like usability-misc?
It does not exist on a new VM not sure if it is created by KDE or Whonix on the first boot.