In terms of User Experience I've grown to love the mac style sheet dialog
[1] for password prompts.  It's not often that I'll recommend a dialog, or a
modal dialog for user interactions.  However sheets seem to have most of the
properties you want when a password is required from an application.

If an application requires a password it's one of the few times an
application absolutely cannot continue; however it can be problematic, if
not dangerous, if that password dialog is floating around away from the
application that requires it.  Sheets keep the dialog pinned to the parent
application that called them and so increases a persons awareness of what is
requiring a password.

Of course there are other issues in OS environment that means you need more
than a sheet dialog.  For example notification icons could require a
password.  I think it would make sense to look into designing "notification
sheets" for this problem.  It still strikes me as weird when I logging into
my Desktop that "something" requires my keyring password, that "something"
being NetworkManager,

I don't really think the darkening of the screen dialog modality is really a
good path towards a usability / security balance.  If anything this takes
away from your ability to understand what is requiring a password.  The
windows Vista UAC dialogs are great examples of how the application
information needs to be duplicated by showing it's name and icon inside the
dialog because the person can't see the application that called the dialog.

I'm sure that answer isn't too helpful as I'm aware we don't currently have
sheets, but you know how we designers love to ask for the moon. :)

~ Bryan

[1] http://en.wikipedia.org/wiki/Sheet_dialog_box

On Mon, Sep 22, 2008 at 12:03 PM, Brian Cameron <[EMAIL PROTECTED]>wrote:

>
> Note that the Windows solution to use Ctrl+Alt+Del as a Secure Attention
> Key is just one way to implement Trusted Path.  There is no reason that
> the GNOME or UNIX community couldn't come up with a different and novel
> way to meet the same requirements.  The Secure Attention Key should be
> viewed as just an example of how Trusted Path requirements can be solved
> and the solution as used by Windows (along with Kerberos).
>
> Debating about whether we should use the same sort of solution, or a
> different solution makes for good discussion, but I don't think it
> makes sense to suggest that just because this particular solution has
> usability issues means that Trusted Path requirements are somehow
> invalid or inappropriate for UNIX environments.
>
> Even though some might suggest that security is "good enough" on
> Linux without meeting these requirements, it still is a good idea to
> consider how to make GNOME and UNIX more secure.  Whatever solution
> might be decided upon will likely require enough infrastructure
> enhancements that we will have time to be thoughtful about the best way
> to provide the feature.
>
> Brian
>
>
>
>  But I'm no security expert; I might be missing something.
>>>>
>>> I believe the goal is to use some uncatchable keyboard sequence a'la
>>> Windows' secure auth (Ctrl+Alt+Del).
>>>
>>
>> This works on Windows (on a domain) because the goal in those situations
>> is to have perfect and total single sign on. This has been watered down
>> in more recent (less coherent) Windows releases, but the goal was always
>> to prompt the user once and never prompt them again for any application
>> because the system uses kerberos.
>>
>> In our mix of applications and protocols passwords abound, and it's less
>> likely that a Ctrl-Alt-Del style solution would be sufficiently usable.
>>
>> Cheers,
>>
>> Stef Walter
>>
>>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to