Excerpts from www-talk: 3-Oct-94 Re: How about a Safe Virtua.. "Daniel
W. Connolly"@hal (2738)
> It is not at all clear to me that Safe-Tcl provides access to
> interfaces to modules. How does one introduce an interface into the
> Safe-Tcl system? By adding to the Safe-Tcl implementations on each
> host where my computations will run, I gather. What if my program
> uses two independently-developed extension interfaces? How do I build
> a Safe-Tcl interpreter with _both_ extensions built in?
Safe-Tcl has a distributed library feature that allows a user or a site
to decide to trust a library of extensions on the Internet. Adding a
"module" to such a library effectively extends the functionality of
Safe-Tcl for ALL sites that trust that library.
The big remaining problem with this scheme is of course scope of naming.
It is my personal hope that some way to limit the scope of names to
module boundaries will be added to Tcl eventually.
> I also suspect that very soon we will discover that these little agent
> programs need to conduct dialogs with multiple parties at the same
> time: they need to talk not just with the user, but also with other
> agents and network entities. Hence suspect that threads will be an
> invaluable part of the runtime system for distributed agents.
Do you really want a language that will only work on machines that
support threads?
> But I also believe that building useful Internet services involves
> significant complexity management, and that complexity management is a
> particular weakness of Tcl. Sure, the implementation of Safe-Tcl is
> clean and somewhat simple, but at the cost of complexity of programs
> built on that platform.
I think you may have missed a key point that Dave made. We undoubtedly
want very complex CSCW applications on the network. But the part of
such systems that has to be executed in a safe language is VERY limited.
In particular, you only need to use Safe-Tcl for what I call "RPC to
human beings". Most of your work can go on inside trusted servers on
the net, programmed in any language you like. The role of Safe-*
languages is much more limited -- it needs to be able to go off and
interact with the user on his/her platform, but it needn't contain the
whole application. I think you overestimate the need for very large
programs in the safe language. However, I also agree that Tcl needs
better support for modules.
Excerpts from www-talk: 4-Oct-94 Re: How about a Safe Virtua.. Jim
Davis@DRI.cornell.ed (655)
> Safety, by the way, should not require reading the source code.
> Two reasons for this.
> 1) I want to protect the privacy of my agents. They may embody
> private or proprietary material. For example, my negotiating
> position. Imagine walking into the bargaining room where the
> other side has been allowed to xray your briefcase.
> 2) Security should not be require that you understand the code to be
> executed ("Even though it does contain a call to rm ** it's in
> a branch that can never be reached...") because you can be wrong.
> Does safe-tcl (or any alternative) have either of these properties? I
> suspect not, for the first, and yes for the second.
You're exactly right -- no to 1, yes to 2. I have not thought of any
good way to accomplish #1, and would be interested in suggestions. I'm
skeptical about the possibility of a solution using encryption,
however. One possibility would be to add a primitive for real-time
communication with the trusted server, but this is a tricky thing to
make safe AND it limits the application to IP-connected recipients.
Excerpts from www-talk: 4-Oct-94 Re: How about a Safe Virtua.. "Steven
D. Majewski"@vir (3077*)
> (3) That extensional capability is the loophole: how can you
> ensure that the higher-order access functions are used, and not
> some lower level disguised approach. ( Not disguised to the
> safe-tcl mechanism, but disguised to the user - i.e. will they
> understand the warning. )
This is actually precisely the point I was trying to make in my "note to
potential implementors". The warning code needs to be implemented
*inside* the primitives, at a level of abstraction where the requested
action can be explained at a user-comprehensible level. Users
understand questions like "Can this program send mail to
president@whitehouse.gov" or "Can this program print 30 pages", and
that's the kind of level where the question has to be asked.
> (4) safe-tcl can be incrementally extended to provide new higher-
> level facilities, while restricting low level access, but this
> leads to a versioning problem.
It does indeed lead to a versioning problem IF the extensions are done
in the core language interpreter, but NOT if the above-mentioned
distributed library facilities are used, which is my preferred method
for extending the system.
> These problems may not be fatal. But think the security requirements
> for enabled-mail, server-agents, and client-executed browser code
> are all rather different, so a fatal flaw in one realm may be only
> a minor annoyance in another.
While I can certainly imagine that this might prove to be the case, I
have not yet seen any evidence for it. I've been watching fairly
carefully, and will certainly continue to do so.
> In some of the distributed programming safety features I want
> to get into Python, for example, I have a looser requirement.
> That the program not do things it "claims" not to do: If it
> imports no I/O capable module, then it doesn't do any I/O. If
> it requires to communicate over a socket to another program,
> then I can hand it an already opened socket, or an object
> that represents a potential socket or inactive "future".
Well, I'm not sure this is a useful level of abstraction for user
confirmations, etc. -- the same problem you just alluded to. There are
plenty of programs I might let open up a socket to a telnet port, but
not necessarily to the sendmail port at whitehouse.gov.
> Nathaniel has incorporated a number of email-centric functions
> into safe-tcl. I don't think we've identified a similar set
> for Web applications and agents.
Actually, there aren't as many email-centric functions as it appears at
first glance, but some of them are (I now think) poorly named. There
are a lot of MIME-related functions, but of course these are useful in
some non-mail contexts (including the Web). There are some
mail-specific primitives for parsing headers and for sending mail. The
latter is essential, the former is really just a speedup (over doing all
the parsing in Tcl; remember that the Tcl philosophy is generally to put
compute-intensive functions inside primitives written in C).
My guess is that there will be a few such functions that are
particularly desirable for the Web -- possibly doing some HTML
construction/deconstruction, reading HTML into a Tk text widget, opening
an HTTP connection, that sort of thing. I agree that this is a vital
area for Web-related discussions about safe environments -- probably a
lot more vital than the issue of choosing a language syntax! --
Nathaniel