Re: Islands in the Net
tcmay@netcom.com (Timothy C. May) writes:
What's the common theme? Agents. Chunks of code which also have local processing power (brains, knowledge).
Someone sent me private e-mail on this "Islands in the Net" topic, and talked about "payloads of data carrying their own instructions," in reference to the Telescript model of agents. (I wish he'd post his comments here!) This approach, also typified in some object-oriented approaches, seems to be the direction to go.
<note: this message was originally the one Tim references in the above, but I have edited and added much to it after letting it percolate in my brain for a day or so...> Naked data is dumb and computers aren't much smarter. Computers need instructions from humans to act on that data, and when you separate the data from the instructions that act on it you have problems. If a hunk of data arrives on your machine and you don't have any code to make sense of it, you are SOL. Likewise if the code that interprets that data isn't "correct" for that data you run into problems. By making the instructions that act on data an integral part of that data, you can avoid problems. This is just the object-oriented programming concept of encapsulation of course. Of course, encapsulation (or OOP for that matter) is no silver bullet for solving this problem at least in the way we are approaching it. It takes a lot of code and a lot of agreement among people. I think it's the human error (including shortcuts) and the lack of communication among humans that contributes the most to software fragility and lack of robustness. What's more is the distinction between data and code is very well entrenched in modern computing. The executable code is nearly always a separate entity from the data it acts on. Not only does the hardware and OS make the distinction between code and data, most programmers do as well. Even though C++ seems like the de facto standard for new software these days, few applications written with it practice strict encapsulation. There is a blurb in last month's Wired (the one with "Rocket Science" on the cover) where they touch on this subject a bit (I don't have it handy), but the author there draws the same conclusion as I: it will take a very radical and fundamental change in computing before this becomes reality. No amount of committee meeting (CORBA) or application level software sugar (OpenDoc, OLE, whatever) is going to change this, or at least make it work. At the core every machine makes the distinction between data and code. Operating systems make distinctions between applications and data files. Until the hardware and the OS start believing that data and code are one as well as the programming languages and APIs, we won't get anywhere. Heck, computers have been around for 40+ years and the primary data interchange format between systems is still just a dumb stream of bit encoded characters. Maybe.... Agents like TeleScript really intrigue me... and I think the are closer to what we need to do this than any of the myriad suggestions coming out of the OOP community (like CORBA, OLE, OpenDoc, etc...). Intelligent agents carrying their payload of data through the network. However, the agents have to be able to run their code on any machine and without having the capability to do 'damage' (most institutions _prefer_ to be islands on the net because of fear of 'hackers'). In addition, the agents, as a collection of code and data, have to mutatable is some way to be able to process the data in new ways. What if remailers were implemented using 'agents'? Instead of me sending a dumb message to a smart remailer, what if I could send smart remailer, with an encrypted message embedded in it, to a friendly machine offering agents access to SMTP (i.e. a machine that allowed any authorized agent to arrive and initiate an outgoing tcp stream to the SMTP port of any other machine). Now I can make my remailer system as convoluted as I want, simply by programming this agent to cruise around machines that answer when it knocks. Once it has moved between enough hosts, it moves to a host that offers outgoing SMTP connections and delivers it's payload. No longer am I limited by the time and effort of the remailer operators to implement fancy new features. Any machine that gives access to my agent becomes another hop in my remailer chain (or whatever purpose I want). All my remailer agent needs to operate is one host, the final destination, that will let it make an outgoing SMTP connection, which could be provided by the hosts currently running remailers. What if this e-mail message you are reading was really an agent instead of just data? A basic e-mail message protocol would be needed for your mail-reading software to interact with it. I'm using protocol here in the sense that NeXT uses it in their version of the Objective-C language. Protocols there are a formal interface definition for an object that isn't tied to a class. If my mail message object (or agent) conformed to the mail protocol, it would have to implement all of the methods defined in the protocol (maybe methods like "giveMeTheMessageContents", "deliverThisReply:", "forwardToThisAddress:", etc...). Wow, now I have a smart e-mail message. I could recode the "deliverThisReply" method to go through anonymous remailer systems or basically anything it wanted. Now instead of praying that the recipient is savvy enough to handle using an encrypted remailer reply block, the recipient just replies as normal and their mail-reader hands the reply to my agent which goes off and does it's magic. I know very little of TeleScript (i.e. I haven't gotten my grubby little hands on it), but I do know that it implements some crypto features for authentication and the like. This type of system won't work unless people are absolutely sure it's secure. By secure I mean people should be confident that when they open their hosts to agents there is no way for agents to access services not explicitly granted to them... I think this is the future of distributed network computing... servers on the network provide basic services (by basic I mean CPU time, network connections, disk storage, etc...) to be utilized by smart agents, as well as smart agents carrying payloads and interacting with 'normal' software (like in my mail message example). There is pretty much no chance that a fundamental paradigm shift in the relationship between code and data will occur at all levels, at least not all at once, there's just too much stuff out there already. But it seems to me that a well-engineered agent system could be a decent compromise, or a move towards the end of code/data duality, that has a good chance of gaining widespread acceptance. enough, andrew
Andrew Lowenstern <andrew_loewenstern@il.us.swissbank.com> writes:
What if remailers were implemented using 'agents'? Instead of me sending a dumb message to a smart remailer, what if I could send smart remailer, with an encrypted message embedded in it, to a friendly machine offering agents access to SMTP (i.e. a machine that allowed any authorized agent to arrive and initiate an outgoing tcp stream to the SMTP port of any other machine). Now I can make my remailer system as convoluted as I want, simply by programming this agent to cruise around machines that answer when it knocks. Once it has moved between enough hosts, it moves to a host that offers outgoing SMTP connections and delivers it's payload. No longer am I limited by the time and effort of the remailer operators to implement fancy new features. Any machine that gives access to my agent becomes another hop in my remailer chain (or whatever purpose I want). All my remailer agent needs to operate is one host, the final destination, that will let it make an outgoing SMTP connection, which could be provided by the hosts currently running remailers.
Yes, I think as Tim mentioned that safe-tcl is a possible way to go here. You could really do a lot of what Telescript promises with safe-tcl, and it is completely open and non-proprietary so anybody could run a server. Basically, safe-tcl is a limited subset of the tcl scripting language designed to allow "active mail", which can contain programs to run either at the time the mail is put into your mailbox or at the time you read it. Most of their interest is in the latter, because since tcl is married to the X scripting package tk, you can actually have an incoming mail message which puts up its own X dialog boxes, etc. Somebody wrote a sample mail-based tictactoe game, where you click in a box and it automatically sends an appropriate program to the other player which will put up the game board and let him click, etc. Imagine this for crypto protocols. But, back to the remailers, as Andrew says this agent-based or "active" mail provides a whole new paradigm for viewing remailers. Rather than being this anarchic threat to the net as they are often pasted, they are simply one of a wide class of servers. If we can move to a model in which semi-autonomous agents do surf the net, then remailers become just a small part of a much bigger picture. I may allow incoming agents to use various resources on my machine, including the mail facilities. A remailer is then just a server which does not enforce a lot of state information on outgoing messages to record their incoming path. I suppose the thing to watch for here will be efforts on the part of net.control freaks to force agents to be carefully authenticated, regulated, ordered and tracked. Just as the mail specs (RFC822) emphasize the importance of a human owner of every piece of mail so you have someone to complain to, similar motivations may play a part in future specs for active mail and similar extensions. This is going to be a continual battle which we will have to be ready for. Hal
participants (2)
-
Andrew Lowenstern -
Hal