GNOME Bugzilla – Bug 308974
Wording of keyring access dialog could be improved
Last modified: 2021-06-18 10:39:42 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/12107 "The dialog which asks whether an application should be granted access to the keyring could be improved with a couple of minor changes: 1. The button which is currently labeled 'Deny' should be relabeled 'Don't Allow'. The dominant verb in this dialog is 'Allow', and 'Allow' appears in the labels of both of the other buttons, so for consistency's sake it should appear here as well. 2. Currently the full path of the application which is requesting access is displayed in the dialog text, e.g., "The application 'File Manager' (/usr/bin/nautilus) wants to access..." This is unnecessary and may prove confusing to users who will, at most, only be interested in the name of the application which is attempting to access the keyring. So the path should not be displayed in this dialog. ... https://bugzilla.ubuntu.com/attachment.cgi?id=2822 Mockup for comparison Mockup showing the current version of the dialog, and a version with the suggested changes. ... https://bugzilla.ubuntu.com/attachment.cgi?id=2825 Corrected patch Corrected patch, should work now."
Where does the full program path come from? It is useful information to have, especially if it's being determined by the keyring rather than simply supplied by the application. Maybe it could be seperated from the main text, making it easier to ignore until that information is needed.
The pathname is something you can trust, whereas the name is whatever the app sent, so if we drop the pathname there is zero security.
What about a "More Info" expander with the name of the application on it?
Sorry, I obviously mean the pathname and not the app name.
(In reply to comment #2) > The pathname is something you can trust, whereas the name is whatever the app > sent, so if we drop the pathname there is zero security. That's true, but there is a counterpoint to that -- the "application names" used by many GNOME apps don't match up with the names of the actual executables. For example, in the mockup the "application name" is "File Manager" but the path points to an executable file called "nautilus". If I didn't know that the "real" application is called Nautilus, my first instinct would be to think that this "nautilus" program is trying to trick me, and so I'd disallow the keyring access. So I can see an argument going either way on this point; any chance of getting a usability person to take a look at this and weigh in?
James, by the same token I could name a malicious program "Gnome_File_Manager"...
Even the application name can be confusing. I have an FTP location bookmarked in Nautilus. I went to open it from the Places menu. The keyring dialog said 'gnome-panel'. Huh? Most users won't know what that is.
Those bugzilla.ubuntu.com patch links go to unrelated stuff.
Launchpad bug on https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/18384
I'm not sure I understand the 'Don't Allow' thing. Isn't 'Deny' the opposite of 'Allow'? A HIG link perhaps to back this up?
Using 'Don't allow' makes it easier and quicker to correctly grasp the meaning of the three buttons -- the user sees the common verb 'allow' and that the three buttons are 'don't', 'once', and 'always'.
Created attachment 123558 [details] screenshot from Ubuntu 8.10 Text of this alert: "Allow application access to keyring? The application 'Application' (/usr/lib/telepathy/mission-control) wants to access the password for 'Password for account gtalk1' in the default keyring." Problems: 1. "keyring" is neither familiar nor explained 2. "Application" isn't an application (Empathy's fault, or gnome-keyring's?) 3. "usr" is neither familiar nor explained 4. "lib" is neither familiar nor explained 5. "telepathy" is neither familiar nor explained 6. "mission-control" is neither familiar nor explained 7. "access" is surprisingly vague (I've only just created this account, so gnome-keyring should be able to tell me that there is no such password in the keyring yet) 8. "password for 'Password" doesn't make sense (Empathy's fault) 9. "gtalk1" isn't a familiar term (Empathy's fault). I'll be happy to redesign this, but first could someone give me a quick explanation of why this alert exists at all? Are all applications that use the keyring supposed to have fallback password storage in case the user doesn't want to use the keyring?
This happens when a different program that stored the password, then tries to read it out of the keyring. It's debatable whether this prompt should exist at all. It's a good example of passing the buck to the user, for no real security gain. It's on the list of problems to 'solve' in gnome-keyring and every once in a while becomes a topic of debate.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/ Thank you for your understanding and your help.