[Squeak-e] Comments on Anthony's "...Shared Smalltalk"
ajh18 at cornell.edu
Fri Feb 7 13:47:40 CET 2003
"Mark S. Miller" <markm at caplet.com> wrote:
> At 09:47 PM 2/6/2003 Thursday, Anthony Hannan wrote:
> >Sorry this was not written more clearly. A "smart capability" is a
> >revocable capability that is automatically revoked if used by someone
> >other than the designated client (sender).
> I'm still confused. How would it tell who it is being used by? Earlier I wrote:
> >> [...] What do you mean by "confirm the sender"? What
> >> information would you examine, and what notion of sender would you compare
> >> it against? [...]
> Likewise, above you write "designated sender". Designated how? What would be
> designated? Do you imagine designating the individual object that may send
> to a given capability? Why would this be useful?
> > If Alice gives Bob a "smart"
> >capability to Carol. That capability will only forward messages to
> >Carol if the message is from Bob. If Bob gives the capability to anyone
> >else it won't work.
I've have just realized my "smart" capabilities scheme is useless.
Even if it prevents Bob from giving the capability directly to others
it does not prevent him from acting on other's behalf. He could act
like a forwarder for others thus giving out the capability indirectly.
So please ignore my "smart" capabilities. I will remove if from my
paper. Thanks for catching me on this.
> Please read Capability Myths Demolished.
I did. Very good paper!
> The bigger issue is that with proper capability foundations, this kind of
> behavior isn't possible. It would violate the encapsulation of the sender
> for the receiver to know anything about the sender other than:
> * What the sender decided to send to the receiver as arguments.
> * That the sender therefore must have had capabilities to these arguments
> and to this receiver.
> Nothing else is the receiver's business. This information hiding allows
> senders to reorganize freely the nature of the computation from which these
> messages are emitted, since this change of organization can't be sensed by
> the receivers. This is good modularity just as much as it is good security.
Good point. I agree.
> (The above argument is also bit of a preview of my upcoming "What's Wrong
> with Dynamic Scoping?")
I agree dynamic scoping is bad (my "smart" capabilities would have
relied on it). The only tricky thing is how to handle exceptions.
> As of ParcPlace 2.5, ignoring thisContext, the above properties were also
> true of regular Smalltalk programming. Violating them takes us away from the
> object paradigm and the capability paradigm.
Yes, we will have to eliminate thisContext from Squeak-E. It should be
enough to just have the following, implemented as primitives:
[^ ...] (block remote return)
> >I threw it in as an alternative to information flow security.
> I don't know anything about information flow security.
Please check out: Andrei Sabelfeld and Andrew C. Myers. Language-Base
Information-Flow Security. IEEE Journal on Selected Areas in
Communications, special issue on Design and Analysis Techniques for
Security Assurance, 21(1), January 2003.
It is interesting work and seems to be an active area of research. It
relies on static typechecking of programs whose variable types have been
annotated with security labels. It provides end-to-end security;
information can never flow from higher to lower security, even derived
> >Yes, common classes are common across the universe and replicated on
> >users' machines that use them. But they still may need to be evolved,
> >so some trusted "Squeak Central" users may have authority to change
> >them. Their changes would be propogated to all machines that have
> >replicas of them.
> Once I make the decision to install a security kernel of some sort, whether
> a secure OS or language kernel, everything else I do on it is then fully
> vulnerable to the misbehavior of that kernel. I'm trusting it with a lot. I
> don't make that decision casually, and I make it based on my sense of the
> scrutiny given to that code by an open community.
> When I make that installation decision, I make it with regard to a
> particular version of the code. Granted, once I've done so, I probably
> regularly decide to upgrade to the later version published by the same
> organization without adequate further thought. But (at least for me),
> I *must* make that decision manually each time. Otherwise, I make myself
> vulnerable to the organization itself, rather than just to each individual
> version of their (hopefully widely reviewed) code.
Your right, I'm giving too much authority to Kernel creators. So instead
I propose that once a creator "releases" his class he can no longer
change it. If he wants to make revisions he has to create a new
subclass. Others may decide to use his new subclass or not. They may
migrate existing instances to the new class and/or use the new class for
> >> 3.2:
> >> Are you proposing that each pool dictionary be replicated across all users?
> >Yes, replicated to all users that are using them. Remember, I envision
> >all users working on the same object graph (same Smalltalk image).
> >Parts of the graph that a user is accessing are replicated or proxied to
> >his machine.
> >> If so, then these must contain no authority as you've heard me harp on.
> >That is where read-only classes come in (section 3.3). Each pool only
> >contains read-only cabilities to classes. Additionally, each pool
> >cannot be changed (elements cannot be added, removed, changed) unless
> >someone has a capability to do so (like "Squeak Central" authority to
> >change common classes above).
> Same problem then. I think these can't be automatically replicated, because
> there is no one authority everyone would mutually trust. At least I hope there
> won't be. A world in which there's some one authority everyone is willing to
> make themselves fully vulnerable to is a world ripe for dictatorship.
Yes, like above I will change this so no one has authority once the
pool is "released". However, I will still allow the creator to add new
classes to a pool. This is where he could add his new subclass versions.
Adding to a pool is benign.
> >> 3.4:
> >> Really really cool. But, since you wish to prevent the class extension from
> >> overriding the common class it's extending, what happens if the common class
> >> later defines a method for one of the messages defined by some extension?
> >They would essentially be different selectors (messages).
> >Typed-selectors (section 3.6 below) provides separate selector
> >namespaces for each class and class extension, so there would be no
> >conflict. A class may only be polymorphic with another class if they
> >both inherit from the same abstract superclass (interface) that
> >introduces the polymorphic selector. Classes and their class extensions
> >do not inherit common selectors so they can't be polymorphic or
> Doesn't this require selectors in the source always to be written in the
> qualified form?
Not if the selector by itself is unique among all possible selectors
visible in the method class's pool. Remember, a method can only send
selectors of abstract classes/extensions found in the method's class
pool. Ie. all classes of possible collaborators must reside in the
method class's pool. Internally, all selectors will be qualified (in
case the pool changes) but when displayed only ambiguous selectors will
need to be qualified. Of course, the user may set a preference to
qualify all selectors when displayed.
More information about the Squeak-e