I have a question about this. Part of the philosophy which motivated the creation of Squeak (as I understand it) is to be an "open" system. That is users/researchers can get at any part of the system. So my question is, would you want to violate this philosophy by changing Squeak to "control" access to parts of the system?

Or would capabilities be something that you implement between "images", that is, different instantiations of the image run-time?

Are capabilities something that becomes important for inter-host communication over a network? Or for intra-host (on the same host) user process cooperation?

I'm not sure what these questions mean in terms of "normal" Smalltalk operation and security measures. Has anyone on this list dealt with Smalltalk security issues before, without relying upon host operating system services?

Shane

On 1 Feb 2003 at 17:02, Robert Withers wrote:

Hi Allen,

This is very interesting news. I don't know how important eventual sending is in providing a system supporting capabilities. There is a really rough implementation I did, on the swiki ( http://minnow.cc.gatech.edu/squeak/2410 ), but it is broken in several places (self sending through an inspector on an eventual reference). In looking at the ANSI spec, there was a discussion of the computational model and it is a immediate call/return model of execution, which I have pasted below. Additionally, the protocol specifications define a return value, which may not support a promise model of execution.

What are your thoughts about changing the computational model of squeak in this way?

I suppose the broader question is do we need to do this to support capabilities?

cheers,

rob

"from the ANSI speciffication"

<fontfamily><param>Arial</param><smaller>A <italic>message send</italic> causes execution of the currently active method to be temporarily suspended and for program execution to continue starting with the first expression of another method. A message send directs a message to an object. The object is called the <italic>receiver</italic> of the message. A <italic>message </italic>consists of a method selector and a set of arguments. Each argument is a reference to an object. When an object receives a message, the method selector of the message is used to select the method from the object's behavior that corresponds to the selector. The method becomes the new locus of execution. Special processing takes place if the receiver's behavior does not include a method corresponding to the message's method selector.

A <italic>return</italic> terminates execution of a method and causes execution to resume within the method that executed the message send that activated the method containing the return. Execution continues immediately following the message send expression. The return provides a value (an object reference) that becomes the value of the message send.

</smaller></fontfamily>

On Friday, January 31, 2003, at 07:59 PM, Allen Wirfs-Brock wrote:

<excerpt>I just want to mention that when I read Lex's "Object as Capabilities in Squeak" I was struck by the number of similarities between it and much of what is in the ANSI Smalltalk specification. Just as one example, in ANSI Smalltalk a reference to OrderedCollection doesn't necessarily bind to a "class object". It is simply a "named object" (a constant global binding) to an object that is required to conform to the protocol <<OrderedCollection factory> and this protocol only includes a few instantiation messages.

In developing the ANSI Smalltalk specification we were trying to define the core user language and protocols that is most commonly used in application programs, rather than in tools or the reflective implementation of a Smalltalk environment. To do so, we needed to strip away all the meta-level and implement artifact messages that clutter all conventional Smalltalk implementation. This sounds very similar to what you need to do to define a secure dialect of Smalltalk.

If you haven't read the ANSI spec. for awhile (or ever) you might find that this perspective offers some clues to the perennial question "what were your guys smoking when you wrote that spec?".

If you don't have a copy of the ANSI Smalltalk Standard a near final draft is still available at:

ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.doc

or

ftp://ftp.smalltalksystems.com/sts-pub/x3j20/standard_v1_9.rtf

Allen_Wirfs-Brock@instantiations.com

---

Squeak-e mailing list

Squeak-e@lists.squeakfoundation.org

http://lists.squeakfoundation.org/listinfo/squeak-e

</excerpt>

On Saturday, February 1, 2003, at 06:38 PM, Robert Withers wrote:

...

I'm not sure what these questions mean in terms of "normal" Smalltalk operation and security measures. Has anyone on this list dealt with Smalltalk security issues before, without relying upon host operating system services?

this is a big reason that I presume we felt it was pertinent to form another list. the host OS is only there to give us a launching point and allow squeak access to display, sockets, files, sound, time, and that kind of thing.

I didn't answer your question, did I?

I meant to say that we are considering changes to the Squeak language, although we may be able to keep it ANSI compliant, surprisingly. _this_ is why I think we thought we should form another list, plus we were being very noisy.

I think it possible that some squeakers have written security to the host, but it would be for a specific host and that breaks the cross-platform nature of squeak. There is a fair bit of security features already in squeak, including message signing and other bits. There is a security plugin which can sandbox the image (no file access, etc..). I think we are looking at finer grain techniques for securing live objects.

sorry about that, rob

On Saturday, February 1, 2003, at 07:56 PM, Mark S. Miller wrote:

I know that E's model of concurrency does work well with capabilities, and can be added to sequential Squeak as Rob has been doing.

Mark,

I started down the path toward E due to an interest in building a concurrency model in squeak. I was initially looking at ConcurrentSmalltalk and had coded a Secretary class for that purpose. In ConcurrentSmalltalk, they introduce a mechanism in the control flow, like many other concurrent languages I believe, where the receiver explicitly receives the message sent, and the sender would explicitly receive the return value. This suddenly started looking like the use of concurrency would cause all kinds of explicit handshaking to propagate into the image proper.

There were many aspects of your concurrency model that attracted me, but I suppose the biggest was the promise. The promise in E is more than a promise of a value to be returned, it was the promise of an object being returned. With this slightest of shifts, you had decided that a program could send messages to the promise. The contract of the promise is 1) it will resolve to an object, which may be broken and 2) all messages sent to the promise will be forwarded to the resolved object.

After reading more about the concurrency model and the distribution model, it became clear that this model goes further. When messages are sent to a promise for a previous message send, that happened to be to a receiver that was remote, then those subsequent message sends would be sent to the remote location of the original receiver. If the resolved object for the promise is co-located with the original receiver, then you could immediately send the subsequent messages to that object in the remote image. If the resolved object for the promise is located in yet a second remote image, then the messages would be sent from the first remote image, directly to the new receiver's image. This is quite remarkable.

To make all of this work in partially-order fashion - I think that was the reason - you introduced the event-loop concurrency model. This is very similar to an UI thread event loop, so it makes a lot of sense in squeak. This sealed my fate and here we are. :)

As I recall, PPS2.5 had a similar model, but less preemptive. (Where is Squeak's model documented?)

I searched and searched and couldn't find any write up on this. Here is a handful of links: http://minnow.cc.gatech.edu/squeak/1602 , http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html . Of course the source code is there, but it doesn't really have any comments. I think the right way to describe it is preemptive multitasking, where a higher priority process may preempt a lower priority process. It has Semaphores for coordination. I worked on a LindaTalk implementation, for awhile.

I know that David Reed has proposed an interesting concurrency and distributed computing model for Croquet. I'd love to see a description of it. I don't yet know enough to comment.

I would also very much like to hear about his work. Is there someone who could invite him to join us, perhaps?

Finally, Smalltalk isn't just a system. It stand for a philosophy named "object-oriented programming".

Actually, Alan Kay is attributed with saying something along the lines of wishing he had termed it message-oriented programming, since the focus should be on the communication rather than the things. The power is in the interactions themselves, rather than in the agents interacting.

From my sense of what this philosophy is, capabilities could be termed "object-oriented security". (This coinage by Dean Tribble.) The virtues of capabilities are an extension of the virtues of oo. Likewise, I believe E's event-loop concurrency control model is the extension of the oo philosophy into the concurrency realm, which we try to make clear especially at http://erights.org/elib/concurrency/event-loop.html and http://erights.org/elib/concurrency/turns.html . In these three cases -- objects, security, concurrency -- the issues can be seen in the terms the economist F.A. Hayek explained: How do plans come to be coordinated with each other (message passing) without disrupting each other (encapsulation)? For an object-oriented view of Hayekian economics, see http://www.erights.org/talks/categories/index.html .

This is a great paper. It is difficult to read and there is a lot of new terminology to digest, but the thesis is unique and powerful. The economics of development, or rather the development of economics. Well, we have a another store front, here. :)

So I hope we make Squeak-E a system that not only works, but one that's also a purer expression of the philosophy that Smalltalk has always stood for.

I sure we will spend a good part of our time ensuring that this is indeed the case. :)

cheers, rob