[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Usability: Desktop icons that use Kwallet

I'd like to have some input on this issue from debian-kde.

When you have desktop icons which are links to password protected sessions 
such as fish:/ which has the password stored in kwalled, and you have already 
typed in the kwallet password somewhere else in KDE then a dialogue is 
displayed with four options (KDE 3.4.1):

- Allow once
- Allow always
- Deny once
- Deny always

I think this is a rather strange behaviour. Seems to me like the reason for 
this is that noone has been able to decide what the best thing to do here is 
and then just left it as configurable as possible.

My take on this is that a simple warning message, with a check box for turning 
off the warning in the future would suffice. The warning would read something 
like: "The application you have started will look up authorization 
information in kwallet.". 

If the application is allowed access to kwallet it usually presents you with 
the authorization information in a login style prompt so you actually have 
two layers you have to pass before you are logged in.

The main point is, why would anyone want to deny the desktop access to the 
kwallet when it is already open? I can understand that if kwallet is not open 
you have to supply the password to open it, but when it is already open it 
doesn't make sence to ask the user if he wants to use information in it. If 
you left your console without logging out, an evil person could just say yes 
when the desktop prompts the user to get access. And she would already have 
access to much more sensitive information. Another argument would be if 
someone were to somehow spoof an icon so that is accesses the wallet without 
you knowing it, but in that case I'd say you already have bigger problems on 
your hand.

If nobody can come up with good counter argument, I will file a wishlist bug 
about this.

What say you?

Anders E. Andersen

 - Debian/Unstable - KDE 3.4.1 - KMail 1.8.1 -

Reply to: