Hi Howard.

I forgot to mention that the reason I'm doing this is to allow untrusted 
foreign code to run in the same image as trusted code. Untrusted code 
must be carefully managed - it must not be able to consume large amounts 
of memory, CPU or disk space to which it is not entitled. Untrusted code 
/ objects must not prevent trusted code from operating well.

Oh, and Squeak is full of security holes, but there will be ways to 
patch them I'm sure.

Howard Stearns wrote:
> It seems to me that any attempt to put arbitrary, coarse-grained 
> restrictions on computer resources -- as opposed to problem-domain or 
> user-domain behaviors, is just doing a lot of work to shift the problem, 
> without actually solving it.  How will the programmer set these limits? 
> How will the poor user or "administrator" manage them?

The programmer, user or administrator will manage them "manually"; 
coarse-grained restrictions are course-grained, meaning that there 
aren't many of them.

Example: You find a foreign set of objects and classes in a domain 
called "SqueakSeti at home" and decide to grant that domain access to you 
local computer: it is granted low-priority CPU only, memory is bound to 
64MB, this domain may use 100MB of disk space and no more than 100MB of 
network bandwidth per day.

Meanwhile, another domain called "ImportantBusinessStuff" can use 
high-priority CPU, no more than 256MB memory (i.e. the size of physical 
memory), etc.

This all makes a lot more sense when working with a public distributed 
system where code and objects float from computer to computer. In this 
case, a group of distributed objects are all bound to a "Domain", and 
individual computers decide how much privilege that Domain has on each 
computer.

> Now, there are two issues:
> 
> 1. "But my customer wants to do it the broken way!" Fair enough. You 
> might consider, though, whether or not this approach fits with the real 
> advantages (to the customer, not to you) of using Squeak. If you turn 
> the application into something that works just like Java except that 
> it's in Squeak, you can bet the contract that in the end, the customer 
> will decide to re-implement it in Java (for social reasons, such as 
> covering their butts in deploying, hiring people to work on it, etc.)  
> Doing a broken, Java-like thing "better than Java" is just a special case.

Umm... I don't get your point. This is for my own project. No customers, 
no Java.

> 2. "OK, How SHOULD I do it?" Here you have to look at the actual 
> problems you're trying to avoid. For example, suppose you want to keep 
> mobile programs from writing files on a user's computer. The answer is 
> to arrange to only present a 'file open' interface that prompts the user 
> for the location. 

...like a capability.

> This is better than draconianly prohibiting all 'file 
> open' requests, because it still allows arbitrary programs to do useful 
> work as long as the user is made clearly aware of what the program is 
> doing. (In an imperfect-world nod to resource management, that user 
> dialog might specify the max size of the file.)  Now suppose you want to 
> have the system manage (e.g., remember) the fact that such-and-such an 
> object has requested a file-open, and that the user has granted it for 
> given name/size. The capabilities community (see e-rights) has a lot of 
> literature on how to do this securely. But as I see it, the capabilities 
> stuff is just an implementation detail for the higher-level issue of  
> choosing what (or where) to manage problem-specific behaviors. (See 
> end-to-end argument.)

That's what I intend to use domains for... they're a higher-level 
"management object" to manage problem-specific behaviours.

A reference to a File object would be a capability. The "Domain" 
aggregates objects together so that permissions can be granted in bulk. 
Objects that need access to that File object (which is a capability) 
would ask their Domain instance for it. If the Domain instance does not 
have it, access is obviously not possible.

Of course the implementation details might end up different, but the 
idea is that the local system grants Domains the rights to use system 
resources.

Michael.