[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Mark S. Miller]

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.

If "Bob" is an individual object, this breaks subcontracting among objects, 
and leads to a system that's very hard to program. If Bob is a large 
aggregate of objects, then we have other problems. In either case, this 
allowing or disallowing based on the alleged identity of the sender is the 
ACL paradigm. This way madness lies. Please read Capability Myths Demolished.

>  "Smart" is bad term.  Also, hopefully this kind of
>capability isn't needed in a well designed system.

So let's design the system well enough that we don't need it.

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.

(The above argument is also bit of a preview of my upcoming "What's Wrong 
with Dynamic Scoping?")

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.


>I threw it in as an
>alternative to information flow security.

I don't know anything about information flow security.

>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.


>> 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.


>> 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
>conflict.

Doesn't this require selectors in the source always to be written in the 
qualified form?


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM