ninavizz commented 3 years ago

The problem you're addressing (if any) From the issue #1917 it was concluded that changing the screenlocker from XScreenSaver to something else, would be hard. Perhaps not impossible, but more work than is immediately feasible. As such, I am creating this issue to resolve what from a user's perspective, is the primary issue with XScreenSaver: the flaming computer artwork is scary.

For users new to Qubes and users who are not themselves security or development experts, identifying "visual oddities" in a UI is one of the few resources they have, to question if a piece of software is malicious or safe. The flaming computer, while cute to XScreenSaver's creator, is likely to be scary to QubesOS users. I have unfortunately already exhausted the route of asking its creator to change the flaming computer to something more neutral. JWZ is not keen to budge.

Describe the solution you'd like Ugly UI is ok. Malicious-appearing UI, is not. That's it. :) If some special format, or SVG code for an image, would help—I can easily generate those, as I am a designer and not a developer. Just @ me in the comments. :)

Two screens will be most important to update:

The initial unlock screen
The follow-up "You failed too many times and are locked-out!" screen.

Eliminating the flaming computer throughout the UI, is the priority; not re-branding or re-designing the XScreenSaver app.

xscreen_better

Where is the value to a user, and who might that user be? Malware is scary. The screenlocker should not appear to lay/non-tech users, to potentially be malware.

Because my own objective with my contributions to QubesOS is to make it a more friendly OS to high-risk users who are not developers with a high-tolerance for questionable things (nor the means to investigate those), this feels like a priority to me.

Describe alternatives you've considered Grab a beer or a coffee and enjoy #1917

unman commented 3 years ago

On Wed, Feb 24, 2021 at 02:39:03PM -0800, Nina Eleanor Alter wrote:

The problem you're addressing (if any)

From the issue #1917 it was concluded that changing the screenlocker from XScreenSaver to something else, would be hard. Perhaps not impossible, but more work than is feasible. As such, I am creating this issue to resolve what from a user's perspective, is the primary issue with XScreenSaver: the flaming computer artwork is scary.

For users new to Qubes and users who are not themselves security or development experts, identifying "visual oddities" in a UI is one of the few resources they have, to question if a piece of software is malicious or safe. The flaming computer, while cute to XScreenSaver's creator, is likely to be scary to QubesOS users. I have unfortunately already exhausted the route of simply asking Jamie to update the icon to something less scary. He really likes his dumb flaming computer and will not. :(

Describe the solution you'd like Ugly UI is ok. Malicious-appearing UI, is not. That's it. :) If some special format, or SVG code for an image, would help???I can easily generate those, as I am a designer and not a developer. Just @ me in the comments. :)

Two screens will be most important to update:

The initial unlock screen

The follow-up "You failed too many times and are locked-out!" screen.

Eliminating the flaming computer throughout the UI, is the priority; not re-branding or re-designing the XScreenSaver app.

Where is the value to a user, and who might that user be? Malware is scary. The screenlocker should not appear to lay/non-tech users, to potentially be malware.

Describe alternatives you've considered Grab a beer or a coffee and enjoy #1917

I dont see any problem in doing this: we'll have to give jwz full credit, remove his email address, and rebrand, since almost certainly jwz has the name.

ninavizz commented 3 years ago

I dont see any problem in doing this: we'll have to give jwz full credit, remove his email address, and rebrand, since almost certainly jwz has the name.

I'd rather not "rebrand," as the tool itself is still the same. Co-branding and white-labeling are absolutely a thing. I did this as a quick-take on how to do, while also surfacing requisite 411 to meet the MIT licensing needs and reuse blab in the user manual. The below could also be what you meant by "rebrand." Thoughts?

Blab from the user manual:

Copyright © 1991-2021 by Jamie Zawinski. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.

AUTHOR Jamie Zawinski jwz@jwz.org. Written in late 1991; version 1.0 posted to comp.sources.x on 17-Aug-1992. Please let me know if you find any bugs or make any improvements.

unman commented 3 years ago

On Wed, Feb 24, 2021 at 05:10:48PM -0800, Nina Eleanor Alter wrote:

I'd rather not "rebrand," as the tool itself is still the same. Co-branding and white-labeling are absolutely a thing. I did this as a quick-take on how to do, while also surfacing requisite 411 to meet the MIT licensing needs and reuse blab in the user manual. The below could also be what you meant by "rebrand." Thoughts?

I dont see any problem in doing this: we'll have to give jwz full credit, remove his email address, and rebrand, since almost certainly jwz has the name.

Blab from the user manual:
Copyright ?? 1991-2021 by Jamie Zawinski. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 
AUTHOR Jamie Zawinski jwz@jwz.org. Written in late 1991; version 1.0 posted to comp.sources.x on 17-Aug-1992.
Please let me know if you find any bugs or make any improvements. 

I suspect that jwz would object to the software being used under the existing name without the flame logo. And while the copyright notice covers software and documentation, jwz has the name.

ninavizz commented 3 years ago

JWZ is indeed very difficult and stubborn. The flame is a cute pun that Western GenX and GenY people may get, but not many others.

Good point about the use of the name without the flame logo. I guess then in the release notes, credit him and XScreenSaver as the source code for the QubesOS screensaver—and then remove the line crediting it below "Qubes 4.1" on the above mockup? @marmarek, ideas for how to tread this one?

deeplow commented 3 years ago

If some special format, or SVG code for an image, would help—I can easily generate those, as I am a designer and not a developer. Just @ me in the comments. :)

Some years ago I took a stab at doing exactly this. I couldn't find the references, but by looking it up I found it's in some sort of special format that is embedded into the code. But I'm sure someone can codify the Qubes logo into that.

All I could do at the time was to customize the color scheme.

unman commented 3 years ago

It's straightforward to change the images - just a matter of dropping in replacements in utils/images. I'm running this now. Take a look here

This, of course, is just the start, if we do want to take this route. And since there's a new version in test, should we target that for inclusion in 4.1?

ninavizz commented 3 years ago

Aaaah! TY @unman! Possible to stuff into 4.1 @marmarek or @andrewdavidwong ??

Also: possible to replace the name "XScreenSaver X.YZ" with the name/version for Qubes—assuming it would be seen as objectionable to JWZ to use the name of his product with the Qubes Q as the image?

DemiMarie commented 3 years ago

Aaaah! TY @unman! Possible to stuff into 4.1 @marmarek or @andrewdavidwong ??

Also: possible to replace the name "XScreenSaver X.YZ" with the name/version for Qubes—assuming it would be seen as objectionable to JWZ to use the name of his product with the Qubes Q as the image?

What about “Based on XScreenSaver X.YZ by JWZ”?

ghost commented 3 years ago

/* If you are looking in here because you're trying to figure out how to
   change the logo that xscreensaver displays on the splash screen and
   password dialog, please don't.  The logo is xscreensaver's identity.
   You wouldn't alter the name or copyright notice on a program that
   you didn't write; please don't alter its logo either.
 */

utils/logo.c:15 (xscreensaver source)

While yes the code behind xscreensaver isn't the cleanest, its still one of (if not the) most secure screen locker available (as shown by the quotes below (see links for full context of quotes).

The problem is that XScreenSaver is the best of the available options - that's why it has lasted so long. I'm really not aware of any one who has ever been alarmed by the wall of fire, or has been freaked out. I do know people who have been thrown by some of the hacks. But if this is considered to be a real issue then why not just fork and replace the offending wall with some other (equally basic) image? The framework is great, and we should keep it. (I've started testing v6 which is significant rewrite, but the wall is still there.)

unman (link to discussion)

No, that's a discussion of the KDE screen locker, which (as you know) is different. The only thing about XScreenSaver in that thread is a link to a problem with suspend. XScreenSaver is actually one of the more secure screen lockers available (which perhaps isn't saying much). At any rate, it does sound like physlock would be better.

andrewdavidwong (link to discussion)

I agree that xscreensaver is ugly. But it is effective. And given a number of problems with other screenlockers (#888, #963), not sure if it wise to change it here. Requires a lot of testing. Actually it may be better to switch to something even uglier - physlock, in all desktop environments.

marmarek (link to discussion)

Proposed solution

JWZ has done a fantastic service to the entire community by making a screen locker that locks the screen effectively. Rather than explicitly going against his wishes by rebranding (although technically legal), how about we:

Change default xscreensaver screensavers to just be a slideshow of Qubes backgrounds (building trust with the user)
(possibly) add a disclaimer/explanation on the unlocking screen further solidifying it's legitimacy

th5 commented 3 years ago

XScreenSaver is MIT licensed. I suggest dropping the name and lightly changing the interface, while staying in sync with upstream. As per the license, attribution wouldn't go away.

"You wouldn't alter the name ... on a program that you didn't write" Actually, I would. If nothing was supposed to change, there are plenty of other licenses out there.

Another way to go could be leave as-is and focus on the desktop UI/theme.

th5 commented 3 years ago

Ugly UI is ok

Please make Qubes look nice. The whole thing can look nicer and be more usable. Please please please

Thank you

unman commented 3 years ago

On Wed, Mar 10, 2021 at 07:58:19PM -0800, Tom Hutchinson wrote:

XScreenSaver is MIT licensed. I suggest dropping the name and lightly changing the interface, while staying in sync with upstream. As per the license, attribution wouldn't go away.

"You wouldn't alter the name ... on a program that you didn't write" Actually, I would. If nothing was supposed to change, there are plenty of other licenses out there.

If it is agreed that we change the "scary image", then definitely we must change the name. I propose qscreensaver and derivates for the command line.

ninavizz commented 3 years ago

@th5 We tryin'! More funding would help mightily, though. :) My only "point" with that little bit, was that aesthetics is less the issue with xscreesaver, as is vulnerable user worries. I've made the case to JWZ. He just doesn't care, and also made it quite clear he was not keen to further persuasion.

@unman I like QScreenSaver a lot, great suggestion!

ninavizz commented 3 years ago

Should anyone be forking XScreenSaver to address allthethings with a fabulously renamed QScreenSaver, I have two other usability nits that just came from a security training with users last week...

When the user's password fails, the text on the returned screen is Authentication Failed!. "Authentication" is a bit of an overly technical word, and the exclamation point makes the phrase sound like an admonishment. I would recommend: Incorrect password without any punctuation. More technical and security-fluent folks, yes, are more likely to use passphrases but they'll get it, and that character count should fit the existing space provisions. If there's room, Incorrect password, try again would be my preference.
When CapsLock is depressed and the user's entered password bounces, the text shown in the returned screen is Authentication failed(CapsLock?) As is the case with the burning computer, it's cute and "does the job," but fails with users who are on-edge and not in that "Yay, I'm using software made by a friendly community person!" mood. Incorrect password: hint, CapsLock is on... would be my recommendation. A user in training outright could not get past this screen, they were so on edge about everything else. So, we gotta spell it out a bit better. :)

...yep, Qubes being an OS for at-risk users, matters of sensitivity matter more in our context than in the more general Linux context JWZ built XScreenSaver for.

andrewdavidwong commented 3 years ago

Nits on nits :slightly_smiling_face: :

If there's room, Incorrect password, try again would be my preference.

This comma splice could be avoided by using a semicolon instead, i.e., Incorrect password; try again.

Incorrect password: hint, CapsLock is on... would be my recommendation.

This punctuation strikes me as odd. I'd suggest something like Incorrect password (Hint: CapsLock is on).

If that's too long, I'd drop the is on part.

ninavizz commented 3 years ago

@andrewdavidwong I appreciate and welcome your nits, my friend! :)

Semicolons are just weird in UI messaging. Not for us nerds, but definitely for more pedestrian folks (whom, yes, it is my mission to get comfortable using Qubes). If anything, I'd prefer a second sentence for "Try Again." Sound ok? So: Incorrect password. Try again.

I really like Incorrect password: hint, Capslock is on... and would like that a lot if it can fit!

THAT SAID... There was a terrific comment just now, on the original XScreenSaver Issue. TL;DR, multi-lingual folks who may not know English are likely to struggle with this screen (and the entire UI).

I'm cool with Incorrect password. Try again. Treading into highly subjective territory, it sounds less punitive and admonishing, than Wrong password. Try again. I am very curious what non-native English speakers (or non-native English/Latin alphabet readers) may think of those two (or other?) options.

Which of course, could open-up a massive can of worms on whomever forks XScreenSaver thinking it's just a clean image swap. For which I apologize, and request just the basic updates before THAT SAID...

donob4n commented 3 years ago

h01ger commented 3 years ago

I like the wording improvements and would probably go with Incorrect password. Try again. (or Incorrect password. Please try again.) and Incorrect password. (CapsLock is on.) Try again

-- cheers, Holger

⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄

Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat.

brendanhoar commented 3 years ago

A technical gotcha: like most contemporary Linux authentication, xscreensaver uses PAM (Pluggable Authentication Modules)...so "Incorrect Password" is only true for most users when authentication fails...for some users it would be misleading.

unman commented 3 years ago

On Mon, Mar 15, 2021 at 02:16:11AM -0700, Nina Eleanor Alter wrote:

@andrewdavidwong I appreciate and welcome your nits, my friend! :)

Semicolons are just weird in UI messaging. Not for us nerds, but definitely for more pedestrian folks (whom, yes, it is my mission to get comfortable using Qubes). If anything, I'd prefer a second sentence for "Try Again." Sound ok? So: Incorrect password. Try again.

I really like Incorrect password: hint, Capslock is on... and would like that a lot if it can fit!

THAT SAID... There was a terrific comment just now, on the original XScreenSaver Issue. TL;DR, multi-lingual folks who may not know English are likely to struggle with this screen (and the entire UI).

I'm cool with Incorrect password. Try again. Treading into highly subjective territory, it sounds less punitive and admonishing, than Wrong password. Try again. I am very curious what non-native English speakers (or non-native English/Latin alphabet readers) may think of those two (or other?) options.

Which of course, could open-up a massive can of worms on whomever forks XScreenSaver thinking it's just a clean image swap. For which I apologize, and request just the

I have most of these addressed now - I think the end of your last sentence was cut off.." request just the..." - the suspense is killing me.

Are we doing this for sure?

andrewdavidwong commented 3 years ago

Are we doing this for sure?

That's up to @marmarek.

I share the concern that we may be building a bikeshed with a high risk of scope creep and, even if not, that it should perhaps be lower priority than many other things. However, I'm not a UX expert, so my concern may be misplaced.

mfc commented 3 years ago

hi folks, as i mention here check out the newer versions of XFCE which seem to ship newer version of xscreensaver that avoids all of this.

unman commented 3 years ago

On Sat, Mar 27, 2021 at 06:58:22AM -0700, Michael Carbone wrote:

hi folks, as i mention here check out the newer versions of XFCE which seem to ship newer version of xscreensaver that avoids all of this.

--

That's not a version of xscreensaver - it's a port of Mate screensaver, which is a port of GNOME screensaver - the latter has an unfortunate security history.

mfc commented 3 years ago

ah apologies :[

mfc commented 3 years ago

we doing this for 4.1? from the existing discussion it sounds like the plan would be:

fork and name qscreensaver
change computer-on-fire logo to Qubes logo
not change anything else for now (that is, for initial 4.1 release). can obviously improve wording, etc etc later

unman commented 3 years ago

On Tue, Jul 20, 2021 at 05:38:40AM -0700, Michael Carbone wrote:

we doing this for 4.1? from the existing discussion it sounds like the plan would be:

fork and name qscreensaver

change computer-on-fire logo to Qubes logo

not change anything else for now (that is, for initial 4.1 release). can obviously improve wording, etc etc later

The last stage was that I had done this, and asked if we were making this change at all.

fepitre commented 3 years ago

We already have a fork of xscreensaver. If it means to change only the picture well, that would be easy.

mfc commented 3 years ago

yep! unman already did it here if you want to check it out: https://github.com/unman/qscreensaver/

i see the fork we have here: https://github.com/QubesOS/qubes-xscreensaver

i guess we can keep the fork name qubes-xscreensaver since that's what we already have.

fepitre commented 3 years ago

@unman if you don't mind, you can PR our repo https://github.com/QubesOS/qubes-xscreensaver.

marmarek commented 2 years ago

I've merged the change by @unman for R4.1 (thanks!), but I don't think we should change this in R4.0, as it isn't really a bug fix but rather an enhancement.

mfc commented 2 years ago

awesome! since it's merged in R4.1 shall we close this issue?

mfc commented 2 years ago

for folks who upgrade from R4.0 to R4.1, is there an easy way to adopt this change?

or put another way, currently for folks who upgrade from R4.0 to R4.1 this change is not included even though i've updated dom0 since the upgrade.

deeplow commented 2 years ago

I have reinstalled the system and have also not gotten this.

mfc commented 2 years ago

i have added to R4.1 updates since no one else has :P

andrewdavidwong commented 2 years ago

i have added to R4.1 updates since no one else has :P

But it was supposedly already added in 4.1, so why does this new milestone make more sense than the old one?

mfc commented 2 years ago

i haven't heard of anyone encountering it as implemented, so i want to make sure it gets implemented as an update, such as in R4.1.1. please adjust if you think there is better way to manage it.

unman commented 2 years ago

[quote] But it was supposedly already added in 4.1, so why does this new milestone make more sense than the old one? [/quote] It's not in 4.1 though, is it.

andrewdavidwong commented 2 years ago

New features get added in major and minor releases, not patch releases, so "4.1 updates" likely wouldn't be an appropriate milestone for introducing this. Since no one seems to know what's going on with this feature, I'll set it to TBD.

mfc commented 2 years ago

well i would argue we are now at the stage where this is a bugfix of a poorly-implemented R4.1 feature, not the roll-out of a new feature.

unman commented 2 years ago

On Fri, Jul 15, 2022 at 05:31:29AM -0700, Michael Carbone wrote:

well i would argue we are now at the stage where this is a bugfix of a poorly-implemented R4.1 feature, not the roll-out of a new feature.

All the code is there. It's simply that no one has built an updated package yet. (Except me for testing!) Once that is done, the updated package will be available for testing, and download, and the issue can be closed. (The update to XScreenSaver 6 can be left until the issues with Qubes have been worked out.)

brendanhoar commented 2 years ago

From a new user perspective (which is what this is primarily about) it would be appropriate for this to target the final 4.1.1 iso before release.

B

andrewdavidwong commented 2 years ago

well i would argue we are now at the stage where this is a bugfix of a poorly-implemented R4.1 feature, not the roll-out of a new feature.

Expand

That's fine, but it's more of a philosophical distinction, by which I mean we're getting into "philosophy of software" questions like: If a feature hasn't been implemented yet, can there be a bug in that feature? Or can bugs only exist in features that have been implemented? But what exactly does it mean for a feature to be "implemented"? (If it's not in the build, but it was *intended* to be, does it count as implemented? What if there are references to it or inactive code for it? And so on.) While such questions are interesting and important, the issue tracker is destined for more mundane and pragmatic matters. You might have misinterpreted my previous comment as me trying to _decide_ the timing of when the feature or bug fix (depending on how you're conceiving of it) occurs, but that's not how this works. When I change the milestone on an issue, it's generally not _prescriptive_ of what I personally think ought to happen with that specific issue (usually, as here, I have no personal opinion). Rather, it's _descriptive_ of what our policies or best practices state, or what the devs are doing or say they plan to do. In this case, the devs have not definitively said when the feature will be (or is planned to be) implemented/fixed, so we simply don't know for certain which exact release we'll finally see it in. They have also not definitively said how they're conceiving of it (e.g., as not yet implemented or already implemented but bugged), so we also don't truly know for certain whether it should pushed to the next major or minor release, or whether there's just one tiny bug fix to include in the next patch release. (As a side note, when I advocate for a more disciplined adherence to the general best practice of [not including new features in patch releases](https://semver.org/#spec-item-6), it's not because I want to deprive people of useful features. It's because there's a reason it's a best practice. Injecting new features into environments that users are relying on to be stable is risky. It might feel good in the short run if everything goes according to plan this time, but forming bad habits tends to come back to bite you in the future. I'm just trying to promote the best interests of the project in the long term.) More importantly, issue states (labels, milestones, and open/closed status) are not permanent. While they're _important_ in the sense that we rely on them for the issue tracker to be useful, I get the impression that many people assign too much significance to each individual state _change_, when they should be conceived of as more fluid and temporary. For example, the _act_ of changing the milestone to "Release TBD" is, in itself, no big deal, since at any moment new information (e.g., a dev comment) could lead to changing it back to "Release 4.1 updates" or some other milestone entirely. The act of changing the milestone isn't the hard part; that's just clicking a few buttons. (Ideally, issue states are constantly changing as new information comes in.) The hard part is actually deciding what to do and doing it (i.e., the devs' job). The reason issue states are important at all is that they track what the devs are doing or plan to do, which allows us to do useful things. (For example, it allows devs to see what still needs to be done before a release, and it allows users to see which bugs are known and being worked on, among many other things.) That's why state accuracy is important, while state change actions themselves are not. Issue states merely reflect our best understanding at the time, so states *should* rapidly change. (If they don't, it means we're not learning or doing anything.) When I change a milestone to TBD, I fully expect to change it again to something more concrete (the sooner, the better!).

From a new user perspective (which is what this is primarily about) it would be appropriate for this to target the final 4.1.1 iso before release.

Expand

Well, sure, from a user perspective (whether new or not), the ideal thing would be for all desirable features to be implemented ASAP, as long as they work correctly and don't interfere with any existing functionality. That's stating the obvious. The problem is that software development is _hard_, because ensuring "they work correctly and don't interfere with any existing functionality" is _very_ hard in a complex system. It's a bit like saying, "From a motorist's perspective, it would be best if all speed limits were removed. That way everyone could get to their destinations much faster." Well, technically, yes. But there's a reason we have those limits. Removing them would not be a costless gain. They're an attempt to balance people getting to their destinations more quickly with getting to their destinations _at all_. Only if no one made any mistakes would everyone actually get to their destinations faster. In practice, many would instead end up dead. Likewise, removing everything that "slows down" the process of putting new features into the hands of users would not be a costless gain. There are always trade-offs. While "move fast and break things" might be an appropriate motto for some types of work, it's not universally applicable. In particular, I personally don't think it applies to releases that are supposed to be the most stable possible increments of a security-oriented operating system. ![xkcd-1428](https://imgs.xkcd.com/comics/move_fast_and_break_things.png) Even though devs try their best to catch bugs and not break existing things, sometimes bugs crop up and existing functionality gets broken. For example, when making changes to the screen locker, it's conceivable that there could be unintended bugs, such as some users suddenly being unable to unlock their screens in certain situations. That would be a bad thing to introduce in a patch release, which is supposed to contain only bug fixes that don't interfere with any existing functionality. If users learn that they can't rely on patch releases to preserve stability, then the entire version scheme becomes meaningless, and those users will either not trust it (e.g., by refusing routine updates because they can't trust those updates not to break their systems), or, more likely, simply abandon Qubes for more reliable software. That's why best practices like "don't introduce new features in patch releases" exist. It's not because I want to deprive new users of a useful feature or because I enjoy mindless rule-following for its own sake. It's because I'm trying to learn from the hard-worn experience of smarter people who came before me in this field who have found, in the long run, across many releases over the span of years, that such practices tend to result in better aggregate outcomes. (Note: As discussed above, the specific best practice of not implementing new features in patch releases may or may not apply to this particular issue, depending on whether you think this is a feature that has already been implemented in a buggy way or one that hasn't been implemented yet.)

unman commented 1 year ago

On Thu, Jul 14, 2022 at 10:40:48PM -0700, Andrew David Wong wrote:

New features get added in major and minor releases, not patch releases, so "4.1 updates" likely wouldn't be an appropriate milestone for introducing this. Since no one seems to know what's going on with this feature, I'll set it to TBD.

I provided patches for the current Qubes version, and an update to the latest Xscreensaver version 6. The PR for the current version was merged to master in October.

Marek has been trying to resolve issues upstream with v6, but has not yet been able to do so. So we are stuck with the current Qubes version. I don't know why the "fixed" version isn't available in 4.1 - I'll look to see what the issue might be.

DemiMarie commented 1 year ago

This is now fixed (available in current-testing), closing.

mfc commented 1 year ago

this makes me so happy, thanks again!!

deeplow commented 1 year ago

XKCD 1172 confirmation on the forum:

Can I go back to the original Xscreensaver login that doesn’t shout: “Hey, i’m using qubes over here!”. I liked the flame of the old screensaver login.

QubesOS / qubes-issues

Swap-out scary image on XScreenSaver with QubesOS "Q" #6425

Proposed solution