Created attachment 186078 [details] Discover - update process-default SUMMARY When the update process in Discover requires a password being entered, details should be displayed by default STEPS TO REPRODUCE 1. Update with discover something that requires a password 2. Check password input screen OBSERVED RESULT The windows for requesting the password is displayed, but the details are hidden by default EXPECTED RESULT The part of the update that requires the password is displayed by default ADDITIONAL INFORMATION When I updated to Plasma v6.5 I got a Window that asked for my password. I was very suspicious because I didn't expect it to require a password, because it usually does not. I wanted to know what the process was that the update would request. IMHO it's much more open and trustworthy when the update process tells you why it or what process needs your password. After all it could be some kind of maleware on the system that somehow snuck into the update or installation process and uses this point in time (when you might expect to enter your password anyway) to get it to install more malicious software (No idea if this could really work this way on KDE/Linux). The contrary position would of course be to keep it simple for new users who might be intimidated if they are told a long list of applications that request their password of which they don't know a single one. However, judging by other error messages I currently get, maximum level of not-scaring-new-users is not the main focal point anyway. SOFTWARE/OS VERSIONS Operating System: KDE neon User Edition KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.14.0-33-generic (64-bit) Graphics Platform: Wayland
Created attachment 186079 [details] Discover - update process-details This is the view I suggest as default. On the first glance I can see that Snapcraft needs the password and not some ransomware process named totally-not-encrypting-your-data.
There's no feature for the app to request that the password dialog shows all details by default. The dialog itself would need to make that decision, and it would have to be done universally, for everything.
(In reply to Nate Graham from comment #2) > There's no feature for the app to request that the password dialog shows all > details by default. The dialog itself would need to make that decision, and > it would have to be done universally, for everything. If such information is passed to the password dialog, it could may decide based on the app that requires authentication. So eg. it would do it for Discover, but not for eg. Firefox. As I have no idea how the password request works internally, I have no idea if it would actually work to hand over more information including the type of process that requests the update (eg. systemupdate) so the password dialog has something to work with.
The password dialog can't receive hints of that type from the app. The only way we could do this is having the password dialog hardcode a list of apps to do it for, which doesn't scale and could backfire, since the actual authentication prompts themselves are configurably on or off at the distro level. Our only practical option is to have the password dialog *always* show more information. It might be feasible. I can think of a sensible design for it. I might work on this sometime soon.
Created attachment 186317 [details] Password request - GParted (In reply to Nate Graham from comment #4) > The password dialog can't receive hints of that type from the app. The only > way we could do this is having the password dialog hardcode a list of apps > to do it for, which doesn't scale and could backfire, since the actual > authentication prompts themselves are configurably on or off at the distro > level. > > Our only practical option is to have the password dialog *always* show more > information. > > It might be feasible. I can think of a sensible design for it. I might work > on this sometime soon. I can imagine that hardcoding always leaves out new apps and requires constant maintenance, so I can imagine that this would not work all that well. "which doesn't scale" - I guess you mean that including new apps would be a hassle for the developer as including it would not be the work of the developer of the new app, but rather work for the person who maintains the password dialog app (which could also be nobody if said person decides to no longer develop the app) "*always* show more information" - considering that I did not come across a password Window where the extra information was confusing or may even misleading, this is a very good Option IMO