Fwd: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
Mark S. Miller
markm at caplet.com
Sun Feb 9 18:56:11 CET 2003
I just realized that Dean's message may not have been accepted by the
mailing list. Apologies if you see this twice.
>X-Sender: agorics at postoffice.pacbell.net
>X-Mailer: QUALCOMM Windows Eudora Version 22.214.171.124
>Date: Sat, 08 Feb 2003 13:19:06 -0800
>To: "Mark S. Miller" <markm at caplet.com>
>From: Dean Tribble <tribble at e-dean.com>
>Subject: RE: [Squeak-e] Comments on Anthony's "...Shared Smalltalk"
>Cc: Squeak-E - a capability-secure Squeak <squeak-e at lists.squeakfoundation.org>
>This is a response to some comments about the importance of openness to
>One of the reasons I have not spent more time working on squeak and porting
>older Smalltalk libraries and tools to Squeak is a confusion about openness
>One of the most wonderful things about a Smalltalk environment is that it is
>open to inspection, modification, and extension by the developer. This
>might be the single most important thing about Smalltalk.
>But it is *not* at odds with security. What is at odds with security is
>confounding open-to-the-developer and
>open-to-any-program-that-happens-to-be-nearby. I would like a Smalltalk
>system that is open to *me* when it is running on my machine, but in which
>the programs are not exposed to *each other*. (Indeed systems that try to
>prevent me from seeing or manipulating things on *my* machine make me very
>As MarkM says, getting back to the sense of *the developer* being able to
>change anything while still preserving capability security could be
>challenging. But it's a lot easier to get to a place where programs must
>follow rules with each other, but development tools can get the access they
>need easily. The general pattern is to replace primitives for getting
>inappropriate access (e.g., instVarAt) with "closely-held" capabilities:
>capabilities that are available only to a few programs, which ensure that
>their use does not violate capability discipline or system integrity.
>Let's look at instVarAt: for example. It is primarily there to support
>meta-level tools like inspecting and debugging. These are almost always
>tools for developers, not programs. Replace instVarAt primitives with a
>primitive capability that is closely held by the development tools. The
>developer's tools then use that capability to look inside any object.
>Normal programs don't have access to the capability, and so they cannot
>violate arbitrary object encapsulation. The developer can decide to make a
>new service that has that capability (e.g., an object serializer for
>rewriting the Smalltalk image in a different format), but again that doesn't
>mean the authority is available to the Web server.
>Another important facet of Smalltalk's openness is malleability, the fact
>that a programmer can change anything in the environment. Too often, people
>confuse this with increasing flexibility in arbitrary dimensions, and
>removing all barriers and modularity. As a result, it often seems at odds
>with security. First, I'll give some examples of what I consider bogus
>malleability in Smalltalk; the basic theme is that Juntas are a symptom,
>not a solution.
>- When I'm refactoring the Browser, I don't want the browser I'm currently
>using to break. I want to create a new version of the Browser, then try it.
>- I might want to (and have!) develop an entirely new user-interface
>framework, possibly starting from the current one, without breaking my
>development environment as I go.
>- At a non-gui level, I've changed the way that numbers decide on coercions,
>without breaking the system.
>Doing that as Juntas just seems pointless and silly; I should be able to
>produce a new system without breaking the old version. I want complete
>control, without having my entire environment feel like it is made of mud
>because it keeps changing out from under me (and yes, I'm exaggerating a
>little for effect).
>I guess my point here is that one can have a system that is entirely
>malleable to the developer, with the ability to add structured hooks
>(closely held) to apply that malleability to new tools or techniques,
>without having arbitrary malleability be a common element in the programming
>So the final claim is that Squeak-E could have the familiarity with
>Smalltalk, with the differences only showing up for people that "open up the
>hood", but those people will just open the hood in a slightly different but
>still easy to understand place, and have all the power they could want.
>This seems like a useful intermediate target (in the spectrum of security
>targets) that would also be comfortable to the Smalltalk community.
Text by me above is hereby placed in the public domain
More information about the Squeak-e