RFC: Moving KWallet Password dialog into Plasma

[David Edmundson]

On Fri, Jul 20, 2012 at 7:46 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Friday 20 July 2012 18:25:15 David Edmundson wrote:
>> On Fri, Jul 20, 2012 at 4:58 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
>> > Hi all,
>> >
>> > the problems around review request #105628 and getting KWallet's Password
>> > dialog properly raised above the window it is asking the password for just
>> > triggered a thought process.
>> >
>> > The main problem here is that $service ask for a password through
>> > $otherservice. This utterly fails because the $service is not linked
>> > directly to a window which the window manager would need to properly
>> > stack the window.
>> >
>> > Now if we think about it in most cases $service is actually a "system"
>> > service which can be considered belonging to the workspace. E.g. checking
>> > for mail, logging into your telepathy account and so on.
>> >
>> > Providing a password safe and asking for the master password is also a
>> > "system" service and should belong into the workspace.
>> >
>> > So here my idea: let's move the password dialog into the desktop shell.
>> > Have it as a so-called "persistent" notification popping out of the panel
>> > and be shown on top of all other windows till the user either dismisses
>> > it or enters the password.
>> >
>> > I think this would solve most of our current issues. There would be one
>> > place where the dialog is shown to ask for the password, it is visually
>> > clear that it's a system service which asks for the password and not some
>> > random malware and if several applications want to open the wallet this
>> > problem is also nicely solved by e.g. saying "Mail Dispatcher Agent and
>> > Telepathy need to unlock the wallet".
>> >
>> > So what do you think?
>>
>> This problem also applies to Authkit/Polkit prompts as well as
>> Telepathy windows (from personal experience) and anything else
>> dbus-activated.
> For polkit and telepathy it should be possible to set the correct transient
> window, so that the window manager knows they belong to a different
> application.

For the vast majority of KWallet cases there's also a parent window.
Changing these is just (IMHO) wrong. With my usability hat on, if I'm
using an app, like a browser, and KWallet wants my password I still
want to be using this app so the password dialog needs to be in my
face so I can type my password and continue what I'm doing, like a
smooth connected process not changing a taskbar somewhere completely
different.

So it's services without windows which are a problem:
With Akonadi - there's always a window, and they have a solution.
Telepathy(-auth-handler) is a prime example of a service which is
doing it horribly wrong, (I can slag it off as it's mostly my fault)
and it does randomly put up KWallet prompts with no context and
potentially randomly above what a user is doing. I agree it's a
problem.

We had planned to fix it, and almost exactly as you suggested, with a
status notifier  - saying to the user "I need your help with
something" and when clicked, it would then show the wallet dialog or
our password prompt(s).

Whilst making Plasma handle the wallet would look like it solves the
issue, it doesn't really if the password inside the wallet is wrong I
need to show my own password prompt, and then we have exactly the same
issue. In fact it would be worse as I'd have to prompt the user twice,
in what will be probably visually disconnected ways.

What other services are there that are opening wallets without
windows? I strongly feel it needs to be up to them to fix it, even
though it means I have to do more work.

Dave

>
> For polkit I would even be fine with adding a special mode in KWin, if we
> would want to have something like nag screens as in UAC in windows.
>> Dbus-activated apps being launched are (probably) going to be even
>> more common in the future, and we'll see this problem in many more
>> places.
>>
>> "Fixing" kwallet by moving it into a different place will fix it in
>> this one instance, but it's simply avoiding the problem that will come
>> back again.
> Each of these problems have to be fixed independently and best is to design
> the API with having this usecase in mind (e.g. add the window ID for the
> dialog window). But there cannot be a generic solution to all different use
> cases. The only solution is to disable focus stealing prevention. You can do
> that, but don't complain if your password ends up in #kde-devel of your IRC
> client ;-)
>
> Cheers
> Martin