black-box re-use? (was: Re: [E-Lang] MintMaker with ACLs)
Wed, 31 Jan 2001 13:20:34 -0800
I want to thank Hal and Tyler for the stimulating discussion.
I have one question:
> > > For other features Tyler mentioned like giving my accountant the ability
> > > to read my account history, a similar mechanism would be used: introduce
> > > a new UIDlist for the required permission and check that the user ID of
> > > the requestor is in that list.
> It seems to me that some of the same problems arise with capability
> systems, but you don't count them the same way.
> So I can solve this by creating a new object, a "publicPurse", which
> holds a pointer (capability) to my purse but which only exports a single
> function, getBalance(). I give a pointer to this object to my accountant.
> ... this code is just as security-critical as the code in the Mint. If
> you make a mistake, you could be giving too much power to your accountant.
> If you give this capability to the wrong person by accident, you are
> giving away power you didn't mean to give. Adding the new capability
> increases the amount of security-critical code and it increases the
> overall complexity in terms of managing capabilities properly.
Is it the case that adding the "see-balance-only" feature to HalMint
would require changing the existing code, whereas adding that feature
to MintMaker requires only the addition of new code but no change to
For example if there are other users, or other programmers, currently
using the basic mint code, without the "see-balance-only" feature, is
it the case that adding the feature to MintMaker will be less likely to
disrupt them than adding the same feature to HalMint?
I am very interested, from a software engineering perspective, in
"black box" code re-use.
Is this difference a necessary consequence of the security models, or a
design decision on the part of language designers, or a design decision
on the part of the programmers, MarkM(?) and Hal?
Zooko, Journeyman Hacker