[Squeak-e] Comments on Anthony's "...Shared Smalltalk"
Dean Tribble
tribble at e-dean.com
Sat Feb 8 13:19:06 CET 2003
This is a response to some comments about the importance of openness to
Smalltalk.
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
and malleability.
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
angry! :-)
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.
Malleability:
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 environment.
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.
Comments?
More information about the Squeak-e
mailing list