Thoughts on droplets -- users vs. programs
Wed, 3 Nov 1999 01:24:56 -0800 (PST)
> It is clear from context (your subsequent use of the pronoun "she" in
> reference to the creator) that by "creator" you mean a principal rather
> than a program. Your statement is therefore contrafactual for partitioned
> capability systems, and at best half true for encrypted capability systems
> (in that programs also receive the capability, and for that matter receive
> it before the principal does).
In response to a question this evening: the word Jonathan
intended to use was not "contrafactual" but "counterfactual",
which indeed means "contrary to fact".
On Tue, 2 Nov 1999, Tyler Close wrote:
> Are you making a deliberate attempt to confuse the
> If the object creator is software running on a site not
> controlled by the principal/user, then my arguments apply
> equally well when thinking about the software as creator as
> when thinking about the principal/user as creator.
No, i don't think that Jonathan is trying to confuse the
discussion. I suspect that one reason for the conflict
in thinking going on here is that in Droplets there are
few ways for the users of the system to define kinds of
sharing other than giving away capabilities wholesale.
Given that situation, it is much like having principals
give away complete authority, and then Jonathan's concern
about partitioning may make more sense to you.
This is not to say that Droplets cannot have this
constructive power added to the system. However, as it
currently stands, you have taken away what appears to be
a useful access control mechanism to most people and not
yet replaced it with the tools that will enable users to
experience the flexibility and power of capabilities
(cf. the objection of the person who wrote the message
forwarded by Lucky Green).
Beach Sex is an unfortunate example because giving someone
sexual consent in the real world does not give them the
power to forward your sexual consent to someone else.
Sexual consent in real life is very much based on
ascertaining a true, individual identity. It is also
unfortunate because the example attempts to represent
people as objects within the system, leading to confusion
between the "person" which is the human user and the
"person" which is the person object when you're trying
to explain the concepts. (Remember how the procreation
mechanism had to be redesigned because of precisely this
confusion.) Don't fall into the trap of assuming that
only "people" can hold capabilities -- that way lies the
madness of principals.
> The creator of an object receives the only capability for
> that object. If the object creator wishes to share this
> object with another user, then it is necessary for the
> creator to completely define what she means by 'share'.
Yup, and until there is a way for a user of Droplets to
make this definition, the system isn't really complete.
One of the primary flaws of an ACL-type system -- a key
flaw that capabilities aim to eradicate -- is the lack
of sufficient granularity when specifying permissions:
the "all-or-nothing" problem. Once there is a way to
talk about specific arrangements that lie between all
and nothing, Droplets will become much more interesting.
> If the creator wishes to implement a more restrictive form
> of sharing, then she must create a protection proxy object
> that defines this sharing policy. Only the capability for
> this protection proxy should be given to the other user.
Please don't call them "protection proxies". "Facet" is a
perfectly good, concise, expressive term. Also, using the
word "proxy" may confuse issues at the security level with
proxies at the comm level.
"The biggest cause of trouble in the world today is that the stupid people
are so sure about things and the intelligent folk are so full of doubts."
-- Bertrand Russell