[cap-talk] getting authorization from the user and the great insight

[James A. Donald]

Jed wrote:
 >>> Whether it's a good idea to "harvest" knowledge from
 >>> user actions depends on what you mean by "harvest".
 >>> In Jed's example, the action of drawing a line seems
 >>> arbitrary and unrelated to authorization.
 >> Exactly.  Let me mention a few more.  All the typing
 >> of text in this message that I'm typing.

Karp, Alan H wrote:
 > Actually, typing in the window containing the text
 > could be a good way to denote that you want to grant
 > write authority to a file previously opened read only.
 > That presumes, of course, that we know it's the user
 > doing the typing and not some script.

Less trusted software should not be permitted to open
windows or access user input.  Instead, more highly
trusted software responds to user input by opening a
window for the less highly trusted software, with a
caption bar determined and controlled by the more highly
trusted software.  Thus all windows are opened along a
trusted path, and less trusted software can never create
a window with the caption "E-Trade", and we know it is
not some script doing the typing, because the more
trusted software has final authority over the window.

When less trusted software receives user keystrokes and
mouse clicks, more highly trusted software cannot
decipher what the clicks mean, so has very limited
capability to interpret such user actions as granting
authority.  An authority granting user interface gadget,
for example a menu item that opens a dialog box, has to
be drawn and keystrokes to it interpreted by more
trusted software.  Typically the less trusted software
would give the more trusted software a resource
describing the menu, and the more trusted software would
then give the less trusted software the user selection,
together with necessary authority to do what the user
has requested - such as immediately pop up a modal
dialog box.  However the authority to pop up the dialog
box would necessarily be extremely transient - we would
not want the less trusted software to be able to pop up
the dialog box later in what to the user would be a
different context.

As I have posted previously on this list, capabilities
should always be transient in some sense, and the more
transient the better.  A durable communicable permission
is asking for trouble.  Any event that provides evidence
that the lifetime of a capability should be over needs
to be utilized.

This creates a problem with applications such as Gimp
that have several top level windows.  Having several top
level windows is generally a bad idea, since it confuses
the user even if the programmer has the best intentions,
and if the programmer has the worst intentions ....

One solution is that if a program wants to bring up
several top level windows on startup, they are always
docked at startup, and if the user so chooses he can
undock them, through trusted path UI.  A single user
action should never be able to pop up multiple seemingly
independent and seemingly unrelated windows.  Further,
the install script would have to request the installer
to give it durable authority to bring up multiple
(docked) windows at launch, so that most programs would
not bring up multiple windows at all, and those that
can, could be identified.