If I understand you correctly, my general feeling is that what you outline
below is roughly correct.  Much of it is similar to things I did in the past
for similar reasons.

In essence, it sounds like you want the distributed fragments to be able to
use a common infrastructure, but do not require them to be inter-operable
with each other.  Sort of a model of "Squeak as an intermediate OS",
supporting "applications" written within a well-defined problem domain.  I
think that will make some things much easier than the case where the
fragments ( or modules ) would be expected to work with and utilize each
other's components.

Much of what you write below seems oriented towards controlling access...
that is the approach I took as well.  You might also look at SmallScript,
where Dave Simmon's emphasis was not on controlling access but on
controlling "understanding".  In talking with Dave he once pointed out that
having a pointer to an object ( which is what most "sandboxes" focus on
controlling ) is not the issue in a message-based world- instead, control
the messages.  You can't interact with objects without sending them
messages.  In SmallScript I believe this is done by expanding the semantics
of message lookup to go beyond simple reciever/selector lookup, to a "best
fit" lookup based on a variety of inputs, including the sender and other
meta-data.  In this way, one can allow objects from your code fragments to
gain "access" to even critical objects in your base Squeak, yet have no
ability to interact with them.

Good luck!

- les



----- Original Message -----
From: "Paul Chapman" <paul at igblan.free-online.co.uk>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, April 24, 2003 8:37 AM
Subject: Smalltalk Source-Code Firewall?


I have more than 10 years of Smalltalk (/V), but I'm new to Squeak this
week.  And new to the list!  I'm running Wintel, BTW.

I am designing an app in which I wish to allow users to write and distribute
Smalltalk source-code "fragments" with limited semantics, to run on other
users' machines.  It is therefore essential that the implementation of these
semantics forbids fragments from accessing parts of the user's image (and
underlying platform) not specifically permitted in the app's problem domain.

I wish to know if anyone here agrees or disagrees whether the following
approach should work in principle.

(1) Define and build a set of wrapper classes to provide the domain
semantics.

(2) Compile all fragments in the context of the instance-side of a wrapper
class specifically designed for that purpose, using an adaptation of the
Squeak Smalltalk compiler altered as follows:

(2a) Compiler resolves global references (capped ids) through a
compiler-supplied Dictionary containing only the wrapper classes; or perhaps
even disallow all capped ids and require a message to self to, eg, obtain a
new instance of a wrapper class.

(2b) Compiler flags as a compilation error any message-send whose selector
does not appear in a compiler-supplied Set.

(2c) Where necessary, compiler compiles "constants" (numbers, blocks, {}s,
thisContext, etc) as instances of suitable wrapper classes instead of the
usual Kernel classes.

Might it additionally be useful/necessary to subclass some or all of the
wrapper classes from ProtoObject?

Note that my app will NOT prevent any user from using the full facilities of
Squeak: I have every wish that users who wish to exploit the full range of
Squeak facilities side-by-side with my app (Package) should be able to do
so.  It is ONLY the code fragments which are published by the users
themselves by submission to an unmoderated server library whose behaviour
must be coralled.

... Hmmm, I've just thought of another relevant question here...

I don't know much about internet client-side firewalls (or any other kind
;).  I do know that my firewall reports that "Squeak.exe" wishes to access
the net as a client when I do any client stuff, like using Scamper.

Is it possible from within a "standard" Squeak image (with a "standard" VM)
to present a network request through a firewall in the name of a particular
Squeak "subsystem" (in this case, my app), so that a nervous user can
instruct his/her firewall to permit my app to access the net, but not other
parts of the Squeak image?

Does my question make any sense? ;)

Cheers, Paul