GNOME Bugzilla – Bug 709430
Password dialog is unclear: who asks and what service the password is for?
Last modified: 2015-07-14 22:52:35 UTC
Created attachment 256475 [details] confusing password dialog I upgraded from Fedora 19 to Fedora 20 (GNOME 3.10) and this was the first thing I saw (see screenshot). The dialog says "Please insert your password for account "kparal@redhat.com"." When I saw this, I was very much confused in two major areas: 1) What service I'm asked about? - Is this my email password? - Is this my Jabber password? - Is this my Google password? - Is this my Facebook password? - Is this my Microsoft Exchange password? (Add any other services that use email-style login name) I use different passwords for different services, so obviously, the service type matters. In the end, this turned out to be a request for the Google password, probably, but I'm still not fully clear about it. 2) What application asks? With my general user hat on, I felt very uneasy with providing password to a random dialog, that a) I haven't triggered b) hasn't been attached to any known application (nor the description mentioned any). I can just _guess_ that it was related to Online Accounts, but maybe it was something else, some application running in the background, like Evolution, Empathy or <name your third party app you installed in the past>. I want to know who I'm giving my password to. I think there is an easy solution for this problem - don't pop up password dialogs without an explicit user action. If my Email/Google/Facebook/whatever account expires, show a popup bubble from the notification area. Clicking the popup will open Online Accounts/Empathy/something where I see that my user credentials expired and I can click "Log in". When I click the button, show me the password dialog. Immediately, everything is clear - I know who's asking and I know which online service this password belongs to. Of course, adding more information to the dialog itself is beneficial too (e.g. "Please enter your password for your Google account with login name "kparal@redhat.com"." and "Requester: Online Accounts"). That would be awesome. But as a general approach with user security in mind, I think that password dialogs should not appear out of the blue, but should always be triggered by a user action instead. Otherwise we make users accustomed to bad habits - filling in passwords into unknown and unrequested dialogs. gnome-shell-3.10.0.1-1.fc20.x86_64 control-center-3.10.0-1.fc20.x86_64
(In reply to comment #0) > Of course, adding more information to the dialog itself is beneficial too (e.g. > "Please enter your password for your Google account with login name > "kparal@redhat.com"." and "Requester: Online Accounts"). That would be awesome. > But as a general approach with user security in mind, I think that password > dialogs should not appear out of the blue, but should always be triggered by a > user action instead. Otherwise we make users accustomed to bad habits - filling > in passwords into unknown and unrequested dialogs. Yes, but unfortunately Evolution does not behave that way right now, and we have absolutely no way to enforce this behavior. We could do it with Wayland, though.
Yeah, the problem of password prompts appearing without user action is an application bug. It's been reported in bug 677541, which is about the fact that unrequested password prompts are both annoying and confusing/dangerous. *** This bug has been marked as a duplicate of bug 660293 ***
If there is already a bug report covering the security/usability concerns, could this bug report be re-assigned to online-accounts? It should be easy for them to at least better specify the requested service type (see my concern 1 in the description), if they control the text that appears in that dialog. Or are there some technical difficulties in this?
(In reply to comment #3) > If there is already a bug report covering the security/usability concerns, > could this bug report be re-assigned to online-accounts? It should be easy for > them to at least better specify the requested service type (see my concern 1 in > the description), if they control the text that appears in that dialog. Or are > there some technical difficulties in this? This type of dialog should basically never happen. If you lose your connection, the app should direct you to the online accounts panel - which indicates the state of the account.
Makes sense to make this bug the part about GOA indeed.
(In reply to comment #5) > Makes sense to make this bug the part about GOA indeed. For now. It is still desirable to enforce the correct behavior instead of relying on apps/services behaving well. Pieces like app-cgroups, kdbus, wayland are steadily moving into place ...
(In reply to comment #0) > Created an attachment (id=256475) [details] > confusing password dialog > > I upgraded from Fedora 19 to Fedora 20 (GNOME 3.10) and this was the first > thing I saw (see screenshot). The dialog says "Please insert your password for > account "kparal@redhat.com"." > > When I saw this, I was very much confused in two major areas: > > 1) What service I'm asked about? > - Is this my email password? > - Is this my Jabber password? > - Is this my Google password? > - Is this my Facebook password? > - Is this my Microsoft Exchange password? > (Add any other services that use email-style login name) > > I use different passwords for different services, so obviously, the service > type matters. > > In the end, this turned out to be a request for the Google password, probably, > but I'm still not fully clear about it. Looks like bug 708730 GOA never shows any black shell modal dialog [*]. If an account's credentials are invalid then they are marked as such in the Online Accounts panel in Settings. [*] It is not entirely true because we show a modal when you are adding a Kerberos account, which doesn't seem to be the case here.
Oh, actually I have "kparal@redhat.com" Kerberos account configured as well, but I disabled it in F19. It looked disabled in F20 as well, but it might have been the source of those dialogs. After I investigated this a bit and played with the settings a bit, I no longer see the password dialog, so I probably can't provide any further details.
(In reply to comment #8) > Oh, actually I have "kparal@redhat.com" Kerberos account configured as well, > but I disabled it in F19. It looked disabled in F20 as well, but it might have > been the source of those dialogs. The Kerberos provider is not known to throw those black modals unless you are in the middle of creating the account. I don't like that either, but in that situation it is quite obvious what is going on. :-) I still think that this is bug 708730 You can either wait for 3.10.1 to come out, or I can build a F20 package for you with that patch.
I guess I'll wait, I haven't seen the dialog in a few days, and I can't reliably reproduce it anyway. Thanks.
I am closing this as a duplicate of bug 708730 Please feel free to reopen if you have reason to believe otherwise. However, unless you think it is related to Kerberos, my money would be on evolution-data-server being the culprit. *** This bug has been marked as a duplicate of bug 708730 ***
If I understand correctly, bug 708730 is about not showing these dialogs when not needed, while this bug is about telling users who requests the password in the dialogs. Or am I wrong?
(In reply to comment #12) > If I understand correctly, bug 708730 is about not showing these dialogs when > not needed, while this bug is about telling users who requests the password in > the dialogs. Or am I wrong? We should never show those dialogs in the first place. There is no point in telling the users who wants the passwords, because that is already taken care of by the Online Accounts panel.
Created attachment 292874 [details] anonymous password prompt in 3.14 The problem is back in 3.14. I left my computer for a few minutes and when I returned, this is what I saw - an anonymous password request. I guess this should either be related to GOA or Evolution, because I don't think I have configured my email address elsewhere, but *I don't know*. I have canceled the dialog and then inspected GOA and Evolution - both seemed to work without a glitch, reported no problems, and Evolution downloaded my latest emails. gnome-shell-3.14.2-1.fc21.x86_64 gnome-online-accounts-3.14.2-2.fc21.x86_64 evolution-data-server-3.12.9-2.fc21.x86_64 evolution-3.12.9-1.fc21.x86_64
Debarshi (and others), what do you think about adding some kind of "requester" identifier in the dialog after all? I know the dialog is a bug, but it's a long standing and recurring bug. Having some requester identification would make debugging and fixing it much easier. It could be similar to admin permissions dialog, there is also an identification of the process which requests it. Maybe you could report even application name instead of a process, and it could be hidden behind some "Details" expander or such, if needed. I know you said you can't force the processes to identify themselves at the moment, there's not enough security plumbing yet. But this isn't about security, but about finding ill-behaving apps. If you provide the option for the application to identify itself in the password dialog, and then implement this in core gnome apps, it will be much easier to see which application has gone haywire and fix it in the future. If it's a bad idea, please close again. Please note though, that some people rather disable GOA, uninstall Evolution etc than to experience those random dialog every now and then, which is quite unfortunate. I had to do it myself in Fedora 20, now I tried re-enabling it again in Fedora 21.
PS: I have created bug 741632 against Evolution data server.
This dialog comes from evolution-data-server. I don't know what we can do in gnome-online-accounts for that even though it looks related because you created the account in Settings -> Online Accounts. I don't know exactly how the shell modals work, but I would suspect that gnome-shell is involved at some point. So maybe it could offer some debugging information as you are suggesting? But, yeah, I agree that this is a very annoying issue and has been around for some time. You can turn off the Google calendaring from the Online Accounts panel as a work around because this is basically a bug in the calendaring component of e-d-s. *** This bug has been marked as a duplicate of bug 728496 ***
> So maybe it could offer some debugging information as you are suggesting? When I reopened this bug report, I assumed it would serve exactly as such a request. I haven't realized it's reported against gnome-online-accounts, which can't do much about it. Reassigning as a RFE to gnome-shell.
(In reply to comment #18) > > So maybe it could offer some debugging information as you are suggesting? > > When I reopened this bug report, I assumed it would serve exactly as such a > request. We can only present information we have - we already display everything gnome-keyring gives us, so if we want additional information, it needs to be added to gnome-keyring/gcr first. (If we get an (unreliable) application field, I'd rather use it to suppress "wrong" popups rather than adding "advanced" information, but that's a discussion to have iff we actually have something like that)
I don't care who/where/why it is. This bug has really started to annoy me too. If we require it to be fixed in another component, open another bug in that component. Don't keep shifting blame around.
(In reply to comment #20) > If we require it to be fixed in another component, open another bug in that > component. Don't keep shifting blame around. If you think you can fix this in gnome-shell without any additional information from gnome-keyring, be my guest. I don't see any information we are not already using, so as-is I would not know how to fix this. (And yes, I'm annoyed by this as well, so if you can think of a gnome-shell-only fix, I'll be happy to review it)
(In reply to comment #20) > I don't care who/where/why it is. This bug has really started to annoy me too. > > If we require it to be fixed in another component, open another bug in that > component. Don't keep shifting blame around. This bug seems rather unclear to me. What do you intend to implement? What problem is it intended to solve? There aren't many cases where an application should be triggering a system modal password dialog, and the plan is to move the platform in a direction where applications simply aren't able to do this. Currently, the primary example of system password dialogs not having a clear origin is bug 728496, and in that case we know the source of the problem, and pressure is being put on the relevant developers to get it fixed. Are there other examples? Furthermore, in the case of bug 728496, it's not actually a user-facing application that is calling the dialog. If we did display "Evolution Data Server" in the password dialog, it wouldn't mean much to most people, and would actually make the situation more confusing rather than less. ("What is this Evolution Data Server thing? Is it a virus? Have I been hacked?")
(In reply to comment #22) > If we did display "Evolution Data > Server" in the password dialog, it wouldn't mean much to most people, and would > actually make the situation more confusing rather than less. ("What is this > Evolution Data Server thing? Is it a virus? Have I been hacked?") I think you exaggerate a bit. Do you think people don't have these concerns when a completely anonymous password dialog appears, with no origin identification? I find that more disheartening. But as I said, I'm not sure it's actually possible to completely trust that field (with our current desktop security model, one rogue app can do almost anything it wants anyway). But it would serve as a help for finger-pointing -> "that's the app that's spamming my desktop, either I report a bug against it, or I uninstall it". Provided it is technically possible to add that information, at least optionally. I have no idea how the code looks like, but I naively imagined something like: import gnome_shell_integration as gsi result = gsi.ask_password(account="your@email.com", source="Evolution") where the 'source' is an optionally provided keyval. > This bug seems rather unclear to me. What do you intend to implement? > What problem is it intended to solve? For me, it was the finger-pointing part. And also having a bit more trust in whom I'm actually giving my password to (assuming my desktop is not hacked and spawning password dialogs with fake identity).
*** This bug has been marked as a duplicate of bug 688351 ***