ConfirmPassword

[Martin Schaffner]

Hi, I have two questions concerning agents such as ConfirmPassword and 
OpenFile/SaveFile:

* would it be possible to avoid the *requirement* that instantiators 
can not inspect instantiateds in the following way: If an application 
(A) wants to ask get a password-protected capability or a file system 
capability (which you suggest should be done with a trusted utility U 
such as ConfirmPassword), it has to contact a server S. So instead of 
giving A a capability to the constructor of U, we just give it a 
capability to S, which is trusted, and can't be inspected by A.

I do agree with the principle of least authority, but if violating it 
in this instance gives us some other great benefits, then we should not 
forget the fact that it might not be necessary.



Bas Wijnen wrote:
> After thinking about it a bit, I do see an other option, though.  We 
> could
> reserve some hardware for this purpose, and use that.  It would not be
> possible to simulate this, since the hardware can only be controlled 
> by a
> capability which they don't hold.  The hardware could for example be 
> the caps
> lock LED: When it's on, the screen is grabbed and whatever you type 
> goes only
> to the authentic password reading program.  When it it's off, don't 
> type in
> your password.

(This LED should sit right next to the DRM-owner-override button 
suggested by RMS :-)

Would it be a good idea to use the ctrl-alt-del-mechanisms of 
"IBM-compatible" PCs on these machines?


Thanks,
Martin