On Wed, 8 Mar 1995, David - Morris wrote:
>
> I for one will not tolerate generic code being loaded in my machine
> from anywhere based on clicking of links. The security implications
> are mind-boggling. Popup warnings are not sufficient for those unprepared
> to evaluate the implications.
>
> Well before we need to re-invent X I suggest we should:
[ ... ]
>
> Beyond this, the question at this point needs to be the capabilities of
> browser scriptability not the language or implementation. Tcl, perl, rexx,
> a new vm, VBasic, Citrix remote NT protcols, X client / server protocols,
> etc. are all possible ways to represent remote control over the user's
> interface but I think discussions about the implementation(s) now before
> we have a careful set of objectives is putting the cart before horse.
>
> The capability matrix might factor in trustworthyness of the source of
> the 'code' -- if there is a need for function which might compromise
> the security of the user's environment.
>
Although I have been doing some work on Python as a distributed agent
language ( and have looked at Oblique, safe-tcl, TeleScript, et. al. )
I have to say that I share (some of) David Morris views.
To make *any* remote execution system safe, the functions and capabilities
have to be standardized on a higher level. ( This has been discussed on
the safe-tcl mailing list, and elsewhere as the "client trying to open
soctet connection to nn.nn.nn.nn.port - allow ?" vs. "client requests SMTP
connection to <president@whitehouse.gov> with message text: "Die commie Pig!" "
styles of request verification. :-)
If we had a requirements analysis of these higher level functions, then
it wouldn't make much difference what particular language syntax was
used - in fact, the higher level you go, the less it needs to be
considered as or implemented as procedural language.
Nathaniel Borenstein has argued for a procedural language (safe-tcl)
because he's not quite sure what *exactly* he wants to do. (That is also
why I'm experimenting with Python agents. ) However, it is just that open
endedness and lack of standard higher-level functions that makes it
not, in general, practically safe. Given a standardization of the
necessary set of higher level access functions for the Web ( the ones
that ensure you get messages like the second one above and not the first.
Try installing system code on a Mac with Virus Protection turned on if
you want to see another example of the wrong type/level of messages. )
I'm not *sure* that you need to wrap them in a procedural language.
There *are* reasons why I think this is an important research area - but
despite the eagerness of folks to jump into commercial "agentware", I
think it's still largely research, and not ready for commercial prime
time OR standardization. ( Of course, things change very quickly in our
world. :-)
On Sat, 10 Dec 1994, Dave Crocker wrote:
( Some time ago, on the safe-tcl list, which I never got around to
completely responding to at the time. )
> At 10:38 AM 12/7/94, Steven D. Majewski wrote:
> >"Safe-Python" the provisional working name for a project to add
> >safe remote-programming & agent capabilities to the Python language.
>
> a small plea:
>
> The Python work causes me some concern. It has nothing to do with issues
> of technical quality...
>
> I suspect that there is going to be a 'winner' in the mobile agent game.
> The essence of that game is interoperability and having multiple languages
> defeats that goal.
>
> There is one, significant commercial offering. It is entirely proprietary
> and the specs aren't public, yet. I fear that any major competition in the
> open systems agent market is going to serve to strengthen the proprietary
> offering's position.
>
> At base, this issue has to do with market window and not with technology.
> Telescript has created the market and it is proceeding to fill it, via
> large numbers of strategic relationships with major consumer product
> suppliers. If its competitors from the open systems realm spend their
> energy distracting folks among multiple choices, Telescript wins. Period.
>
> So, my plea is for the open systems mobile agent constituency to try to
> find some way to work on a SINGLE package, with the primary goal of
> attaining maximum penetration. Get as many people as possible building and
> running this stuff.
>
> d/
>
> --------------------
> Dave Crocker
> Brandenburg Consulting Phone: +1 408 246 8253
> 675 Spruce Dr. Fax: +1 408 249 6205
> Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu
>
I think this is a plea for "premature standardization".
( Nobody knows enough about what they are doing in this area. If even
GeneralMagic knows, they sure aren't telling in their white papers -
at least not in sufficient detail to evaluate it. )
I'm not sure that a language is the appropriate thing to be standardized,
and I'm sure any attempt to do so would be contentious. ( If Dave Crocker
thinks he's seen some flamage about RPC's for example, on the ietf mailing
list lately, I suggest he go back and read the "Why you should not use Tcl"
News thread, and a couple of dozen similar usenet debates. )
I may be wrong about the above, but in the meantime, there are more
fruitful things to standardize. ( David Morris listed some above, and
I have suggested some other directions - particularly distributed
object technology like OSA, ILU, CORBA, SOM/DSOM, OpenDoc, that makes it
easier for different languages and programs to interoperate. ( And else
where, I have argued that even in a single agent-language enviromment,
we will require a protocol for the interaction of agents programs with
each other and with their environment. Well - this may not be required
for WWW client-side agents, but it will be required on the server side
where one of the significant things about agents is their ability to
negotiate. As for client side agents, I'm not sure that what is wanted
isn't really X - or a lighter weight equivalent. ( Bring back NeWs ?? ) )
One more sobering point of view from Gordon Irlam:
<http://www.base.com/gordoni/web/distribution.html>
| Agents
|
| Again, don't believe the hype! We need to turn the net into a distributed
| computational engine, not email little bits of code around and having
| them execute on different machines. At the language level we want location
| transparancy, we don't want to have to be constantly specifying location.
| At odds with this is the idea of agents which seems to put an emphasis
| on location dependence. Location should only make a difference at the
| implementation level.
|
A sentiment I also agree with ( though I don't think it's necessary to
make physical location visible in the language. ).
But before anyone gets the impression I'm against "agentware" - I'm not:
I'm just not sure what the requirements are and where it's appropriate
technology, and I thing one thing that attracts people about the idea
is that they can avoid thinking about those requirements or other design
details till tomorrow -- let me mention one area where I do think it's
appropriate:
There was some discussion on the OpenDoc mailing list on what needs to
be done for a document to support some level of functionality in the
case where there is no part editor or (free) viewer available on the
machine. Note that this is similar to not having the required helper-app
while browsing on the Web - except that if you are net connected, then
you have several possible ways to deal with that event - several different
places to draw the boxes. Downloading agent script is one alternative, but
so it punting to a different protocol ( X for example ). For a stand-alone,
not necessarily net-connected document, there are fewer alternatives.
One is to fall back on a lowest common denominator representation ( also
a technique used on the Web ), either text or snapshot picture. ( One
current problem with OpenDoc - there is no cross platform standard for
the picture format - it's going to be PICT on the Mac, and probably
something else on other platforms. ) This is where it would be useful
to embed viewing methods ( in some "safe" scripting language ) in the
document itself.
In fact, where I first started thinking about safe/restricted
programming languages was not in the area of distributed programming,
for scientific databases. We had begun an effort to standardize some
of our data ( written in dozens of different and mostly ad hoc data
formats ) into NCSA HDF format, and I was unhappily discovering that
that standardization did not solve all of our problems - that HDF still
suffered, in practice, from a form of the TIFF disease - it was too
extensible for it's own good. I realized that what was necessary was
an object oriented language & file format where methods needed to
interpret the data could be encapsulated with the data itself.
( I didn't do much further at the time except to start to learn O-O
programming and look at and evaluate some little languages - but I
ran into the same realization that the significant step was not picking
a language syntax, but choosing the base classes and methods and
primitive functions that one could build on. )
In short, I think a standard scripting language without a standard object
model is pretty useless, so lets propose a standard object model(s)
first, and then decide if we need a common syntax.
Again, I would suggest looking at Apples Open Scripting Architecture
as an attempt to standardize the Object model, and standard sets of
methods on those objects, while leaving the particular scripting
language undefined.
<http://minsky.med.virginia.edu/sdm7g/Projects/Python/OSA/>
Other links and references start at:
<http://minsky.med.virginia.edu/sdm7g/Projects/Python/SafePython.html>
---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---