[E-Lang] Rights Amplification: The Next Layer Up
Thu, 7 Sep 2000 11:41:05 +0100
> Ok. What should I read first? From briefly looking again
> at the Waterken
> site, it seems the relevant thing is Acid rather than
> Droplets? Is this
> correct? Should I be looking at the version on the site,
> or is there a more
> recent one I should read instead?
There's a 2.0 version of pretty much everything that is coming. Some
of it is more ready than others. For Acid, I still need to upgrade
some of the containers. Still, there's enough done to have this
I've posted a 2.0 pre-Beta version of Acid at:
> I take that your above point is specific to the
> serialization question,
> rather than an objection to the getOptMeta rights
> amplification protocol?
> Even without serialization, we still need such a protocol to enable
> user-written auditors.
In Markm's first post:
> * equality: sameness testing & hashing
> * verifying an object instantiates an audited expression
> and therefore has the properties that auditor ensures
> * equivalent of Java's package-scope pattern of rights amplification
> * debugging (obviously requires rights amplification)
> * application-specific needs for rights amplification, as
> in the MintMaker's
> purses. (It's really ugly for normally clients to see
> that there's a
> getDecr method, but be unable to use it.)
I think *3 and *5 are not good points.
For *3, I think E should encourage the use of sealer/unsealer pairs as
a better alternative.
*5 doesn't make sense. You are essentially saying that it's less ugly
to add a rights amplification method to all classes rather than to
just the ones that need it.
For the others, I was happy with letting the TCB have a privileged
interface. The TCB *has* access to the meta information, why should it
need to ask permission?
I am not sure I understand *2 fully. Could you elaborate?
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com