After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 308974 - Wording of keyring access dialog could be improved
Wording of keyring access dialog could be improved
Product: gnome-keyring
Classification: Core
Component: prompting
git master
Other Linux
: Normal normal
: 2.28
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Reported: 2005-06-24 21:44 UTC by Sebastien Bacher
Modified: 2021-06-18 10:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

screenshot from Ubuntu 8.10 (26.74 KB, image/png)
2008-11-27 16:19 UTC, Matthew Paul Thomas (mpt)

Description Sebastien Bacher 2005-06-24 21:44:48 UTC
This bug has been opened here:

"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.
Mockup for comparison

Mockup showing the current version of the dialog, and a version with the
suggested changes.
Corrected patch

Corrected patch, should work now."
Comment 1 Reed Hedges 2006-03-01 22:31:30 UTC
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.
Comment 2 Alexander Larsson 2006-04-19 13:30:11 UTC
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.
Comment 3 Claudio Saavedra 2006-04-20 08:23:11 UTC
What about a "More Info" expander with the name of the application on it?
Comment 4 Claudio Saavedra 2006-04-20 08:23:52 UTC
Sorry, I obviously mean the pathname and not the app name.
Comment 5 James Bennett 2006-05-03 20:31:08 UTC
(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?
Comment 6 Reed Hedges 2006-05-03 20:34:21 UTC
James, by the same token I could name a malicious program "Gnome_File_Manager"...
Comment 7 Joachim Noreiko 2007-01-30 12:17:08 UTC
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.
Comment 8 Stef Walter 2007-05-10 21:54:55 UTC
Those patch links go to unrelated stuff.
Comment 9 Sebastien Bacher 2007-05-13 09:33:18 UTC
Launchpad bug on
Comment 10 Stef Walter 2007-06-27 16:57:12 UTC
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?
Comment 11 Joachim Noreiko 2007-06-27 18:07:10 UTC
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'.
Comment 12 Matthew Paul Thomas (mpt) 2008-11-27 16:19:10 UTC
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."

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?
Comment 13 Stef Walter 2008-12-11 20:25:59 UTC
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. 

Comment 14 André Klapper 2021-06-18 10:39:42 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
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
and create a new ticket at

Thank you for your understanding and your help.