"Scruffies" vs. "Neats"

PREFACE

I haven't written many essays lately...something about having several
hundred or more of them on this list over the past three and a half years
makes writing another one less urgent for me.

But I've been thinking a lot about the interesting discussion we are having
over the Java security issues and basic security model for running applets,
and note some similarities with similar approaches in AI (artificial
intelligence).

I think it important that people here not "firmly commit" to positions they
may have to change, as this leads to a "sticking coefficient" that retards
changes (note that I am not commenting on which positions may need to
change!).

No one language is the end-all and be-all of programming, nor is any one
approach the inevitable winner. But it certainly behooves us to think about
likely future (and current) computing platforms. (We've done this many
times, as with discussions a few years ago about which environments to put
effort into...we had advocates of Emacs, Eudora, Perl, TCL, Safe-TCL, the
clipboard of Mac and Windows systems, pure text only, and so on. In fact,
an extensive poll was taken--by Eric Hughes, I believe--in November 1992,
with the conclusion that at least a dozen major choices were popular, with
none having a share over 10%.)

So, it is a mistake to assume that I am making a "primate display" of
supporting Java. At this point, and with having seen many fads come and go,
my strong hunch is that "Web plus browsers plus applets plus Java" is
likely to become the main choice of many people. (I am hardly alone in this
judgment, natch. Any look at the trade press, the stock market, the shelves
of new books, etc., will confirm this. But just because something is
popular does not mean it is not in fact the likely future.)

And I am sure that even the critics of various aspects of this
model--including the studies of Java security--see this same scenario
unfolding. I view their criticisms as being necessary and helpful, though I
tend to dismiss the conclusions of some that the model is so deeply flawed
that it should be discarded completely and a new model and/or language
should be awaited....this just ain't gonna happen anytime soon. (The thrust
of this essay is not how and why new computing paradigms spread, so I won't
get into my views on this. Suffice it to say that historically the world
has gotten a major new model (paradigm) no more than twice a decade, and
usually only once per decade. Left as an exercise is what those have been.)


SCRUFFIES AND NEATS

On to "scruffies" and "neats."

The AI world had two main camps, according to a popular view. The
"scruffies" and the "neats."

The scruffies believed intelligent behavior in a program would likely only
come from gobs and gobs of code. They believed in cobbling together apps as
quickly as possibly, racing out into the new landscape of computing and
rigging something up to work. Loosely speaking, they favored hacking Lisp
until something worked...a checkers program (a la ur-hacker Greenblatt), a
vision system, a robot, etc. Scruffies like messy desks, because they like
to be blasted with lots of random inputs, lots of unrelated ideas and
concepts, and "inspiration."

More recently, the scruffies have embraced neural nets, emergent
computation, stochastic computing, genetic algorithms, and similar
buzzwords. The recent work on "subsumption architectures" (a la Brooks) and
agent architectures is consistent with viewpoint (though elements of logic
are of course involved).

(These are all gross overgeneralizations, caricatures, to clearly show what
the polar viewpoints are.)

The neats, on the other hand, believed that logic rules. Epitomized by
Newell and Simon, and by the early Winograd, they believed intelligent
behavior would come when the logical principles of thought could be found
and implemented in a programming language. Much of the work on theorem
proving and logic programming came out of this camp.

According to the caricature (and caricatures can be useful, even if
overstated), the neats have neat desks, work in neat languages, and favor
mathematical rigor.

(Of course, not all neats are neat. Some are scruffy, as Ted Kaczynski shows!)


SCRUFFIES AND NEATS IN SECURITY

The "security neat" believes in applying rigor to security. Machines and
languages should be "provably secure." (Better yet, machines should be
"provably correct," a la Viper, and operating systems and languages should
produce provably correct code.)

The "security scruffy" believes things are moving too quickly to insist his
machine must be Orange Book top-rated, or that his OS must be fully
secure....in fact, he doubts that such definitions have real meaning.

[Aside: This polar caricature overstates things, as I said earlier. For
example, even the "security scruffies" are not in favor of bad
cryptographic code, of seriously-flawed PGP implementations, or of Java
applets that can reach into user files and read or corrupt them. And even
the security neats use machines hooked up to networks rather than running
programs in some secure kernel on a machine locked in a secure room....]

The scruffies believe that it may ultimately produce more overall security
(not to mention producing interesting other results!) to race out into the
new terrain, to establish outposts and colonies....

Boycott "Big Brother Inside" software!
We got computers, we're tapping phone lines, we know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

There are two philosophies in opposition here, the optimistic
model versus the realistic model.

1) "We are smart, so we simply build something that feels good and
   provided we can't find a way to break it we declare it secure."
   This is the Java model. Java isn't "scruffy". Its a very elegant
   and cleanly built system, far more elegant than most. I contend
   that it is flawed, but not because it is "scruffy". I contend that
   the flaw is that its security depends on all its parts working
   flawlessly, and that we can't build flawless systems. Such systems
   are made on the liberal assumption that humans can design something
   perfect in all its parts. To trust a system built on such an
   assumption, you ultimately need a proof of its security from top to
   bottom. The very reason I think such a system is impractical is
   that I agree with the notion that such proofs are not possible or
   if they are made are often as buggy as the code was, proofs merely
   being a formalism in a different language. This is the wrong
   paradigm, from the start.

2) "We are ignorant, so we build something that does as little as we
can get away with, makes the assumption at every stage that every
component of the system might be broken, and put seventeen layers
of armor around it on the assumption that we still have probably
made a mistake or two in designing the system." This is the model
   that modern firewalls built by the likes of me take -- systems that
   are designed to be tolerant of multiple engineering failures. Such
   systems are built on the assumption that humans are fallible. Such
   systems, unlike Java, do not depend on flawless operation of all
   their components for their security. Such systems are built on the
   conservative assumption that humans are going to make mistakes and
   that you have to take account of your own fallibility when
   designing secure systems. In such a system, one can have breeches
   of the security of four major subsystems and the fifth still keeps
   you alive. The "belt and suspenders" model doesn't require
   mathematical proofs of security because it was engineered, from the
   start, to be robust.

Tim misunderstands, thinking this is a case of some foolish
perfectionists getting mad at the guys who throw things together and
hope that they work. Not at all. Our problem with Java is the security
model, which inherently requires perfect design and operation. We
build our own systems to be robust enough to survive our own mistakes.
Java is built such that any mistake is fatal.

Essentially, this is the optimists versus the realists.

Perry

PS BTW, Tim, Java is great for the theorem prover fetishizers -- look no
further than Java's bytecode verifier. I have never built a system
that required an "active defense" like that. They fill me with the
same sort of dread I would get from a skyscraper design that required
a constant flow of electricity to the building lest it collapse. Sure,
its cool. Maybe it even saves some money. However, can you sleep at
night inside it?

PM:

>2) "We are ignorant, so we build something that does as little as we
>   can get away with, makes the assumption at every stage that every
>   component of the system might be broken, and put seventeen layers
>   of armor around it on the assumption that we still have probably
>   made a mistake or two in designing the system." This is the model
>   that modern firewalls built by the likes of me take -- systems that
>   are designed to be tolerant of multiple engineering failures. Such
>   systems are built on the assumption that humans are fallible. Such
>   systems, unlike Java, do not depend on flawless operation of all
>   their components for their security. Such systems are built on the
>   conservative assumption that humans are going to make mistakes and
>   that you have to take account of your own fallibility when
>   designing secure systems. In such a system, one can have breeches
>   of the security of four major subsystems and the fifth still keeps
>   you alive. The "belt and suspenders" model doesn't require
>   mathematical proofs of security because it was engineered, from the
>   start, to be robust.

well, are you saying it would be impossible to do such a thing in
a distributed programming language? why does Java not fit this 
description? it seems to have the internal equivalent of "firewalls"
(a "sandbox" is a similar concept).

furthermore, you are imposing a virtual military-level degree of
security to something that does not seem to require it. if
a virus gets loose on someone's computer because of Java, what's
the harm? you are designing systems that when broken cost bazillions
of dollars, potentially. what does Java cost when it breaks? who
is saying that one should use Java for extremely mission 
critical situations such as funds transfer?

yes, there are different kinds of security, and it would be 
foolish for anyone to assume or think that the security offered
by Java is the same security referred to by people such as PM
writing financial applications, or people inside the NSA, etc--
you know PM, you often write as if you are an authority on security,
but I'll wager that people inside NSA think you are "playing in
the sandbox" so to speak.

let us agree that no matter how secure something is, there is someone
that demands more security, and actually pays for it. sort of like
no matter how much you make in salary, there is someone who makes
more than you do. or no matter how much you know about subject
[x], someone else knows more.

PM, you go on the defensive against TCM, but he was not really 
stating that either the "scruffies" or the "neaties" have an
inherent advantage. it's a feedback loop in security as much
as it is in AI as he described. neither view is incorrect. they
both have their applications.

>Tim misunderstands, thinking this is a case of some foolish
>perfectionists getting mad at the guys who throw things together and
>hope that they work. Not at all. Our problem with Java is the security
>model, which inherently requires perfect design and operation.

again, no one said that you have to use Java for mission critical
applications. please don't criticize it for using the term "secure"
when in fact that is appropriate for its environment. has it
ever claimed to do something it doesn't? have the java designers
ever said, "our code is bug free"? 

 We
>build our own systems to be robust enough to survive our own mistakes.
>Java is built such that any mistake is fatal.

y'know, it may be possible to create an *implementation* for java
that fulfills your demands. you seem to be talking a lot more about
hardware than software. you are free to create any kind of environment
you want for the Java interpreter, including a paranoid system with
multiple firewalls that assumes Java may not do what it claims it does.

>Essentially, this is the optimists versus the realists.

I've noticed how there are two types of thinking: dualistic and
unified. people that are stuck in dualistic thinking always think
that because someone disagrees with them, they are putting them
down. they can't conceive of multiple alternative views on the
same subject, all with relative merits. they may paint their
supposed adversaries as "optimists" and themselves as the 
"realists". a silly game that can go on ad infinitum. I've noticed
that women (well, the ones that are feminine, anyway)
don't seem to get into this kind of debate much,
even when they are present. it's a real man kind of thing.

>PS BTW, Tim, Java is great for the theorem prover fetishizers -- look no
>further than Java's bytecode verifier. I have never built a system
>that required an "active defense" like that. They fill me with the
>same sort of dread I would get from a skyscraper design that required
>a constant flow of electricity to the building lest it collapse. Sure,
>its cool. Maybe it even saves some money. However, can you sleep at
>night inside it?

again, I reiterate: no one asked you to use Java, PM. it has a very
useful place where it was designed for: on the desktop of computer
geeks who get a kick out of mandelbrot generators or remailers or
whatever. you are a businessman in a mission critical situation.
why are you ramming your standards down the throat of a place where
it is inappropriate? 

did the creators of Java say that it is going
to be used in the banking industry? why do you write all your attacks
on it as if they have? do you realize it was intended at first to
be put into *home*appliances*? are you going to die if you occasionally
have to reboot your toaster because a bug? hee, hee, maybe I should 
bite my tongue. maybe you have a "firewall protected toaster arrangement."

"L. Detweiler" writes:
> well, are you saying it would be impossible to do such a thing
> [produce a safe execution environment] in a distributed programming
> language?

It is difficult. The way Java does this, with the protection relying
solely on the correctness of the runtime (the interpreter isn't
emasculated so flaws in the runtime can cause unexpected behavior) it
is nearly impossible. Humans aren't good enough at designing systems
this century.

> furthermore, you are imposing a virtual military-level degree of
> security to something that does not seem to require it. if
> a virus gets loose on someone's computer because of Java, what's
> the harm?

The Web is the universal marketplace these days. Being unable to use
the web is the equivalent of being unable to use the phone. I have
research analysts at large trading houses begging for
Netscape. Unfortunately, these people have a need for top notch
security, because vast amounts of money are at stake.

So, yes, if you are going to create a product that everyone on earth
has to be able to use, it had damn well not explode in your face every
once in a while. Imagine if all the world's refrigerators had a 1 in
10,000 chance of blowing up on you. "Whats the harm" you say. Well,
most people don't expect that sort of behavior in a friendly consumer
appliance that nice people from Sun and Netscape guarantee is
absolutely positively safe except for all the bugs.

> you are designing systems that when broken cost bazillions
> of dollars, potentially. what does Java cost when it breaks?

It costs all the same things the the firewalls are protecting.

> who is saying that one should use Java for extremely mission
> critical situations such as funds transfer?

No one. Unfortunately, when the same machine runs Netscape so the
trader can read the UUNet/MFS merger press release and also has the
big shiny red "trade!" button on some application, you get nervous.

As I said, the traders don't expect that their phone will explode when
they pick it up, or that every piece of literature they get in the
mail may be coated with contact poison. Well, Java is a silent
killer. It soon is going to be sitting on every desktop at every
company in America and its being sold as the new paper or phone. Its
also sitting on all those PCs running "Quicken" that helpfully now can
do direct electronic funds transfer from your account, etc. If you
don't care about the security of your bank account, well, sure, you
have nothing to worry about.

In short, my clients need security today. Your home computer probably
needs it soon if not now, and if you think your business can survive a
few days without its computers, please, by all means, run without
security.

> again, no one said that you have to use Java for mission critical
> applications.

Its not Java crashing that I worry about. Its everything else on the
computer and the network it is attached to that needs protection.

> did the creators of Java say that it is going
> to be used in the banking industry?

Well, sorry, you try to keep it off the desks in the banking industry
if you can.

> do you realize it was intended at first to be put into
> *home*appliances*? are you going to die if you occasionally have to
> reboot your toaster because a bug?

No, but you could die if someone gets your toaster to catch fire, or
gets your microwave oven to do something the hardware wasn't supposed
to. It might also be very annoying if your home security system
stopped working, or if your smoke detectors didn't detect smoke, or even
if your fridge decided that it didn't like a string overflow in the
interpreter and decided to stop refrigerating.

Life critical applications or important financial applications are all
around us. You just don't seem to notice.

Perry

PM:
>> well, are you saying it would be impossible to do such a thing
>> [produce a safe execution environment] in a distributed programming
>> language?
>
>It is difficult. The way Java does this, with the protection relying
>solely on the correctness of the runtime (the interpreter isn't
>emasculated so flaws in the runtime can cause unexpected behavior) it
>is nearly impossible. Humans aren't good enough at designing systems
>this century.

I agree that designers should start from the assumption that their
software will have bugs, not the converse (in fact have been having
a long running argument with an academic on this list on this subject,
he claims that RCS will not be necessary with good OO programming
because OO programming gets rid of virtually all bugs that require
re-releases). however, again my main point is that the assumptions
Java makes are suitable for its environment. you can't realistically
make demands on the language it was not meant to support.

>The Web is the universal marketplace these days. Being unable to use
>the web is the equivalent of being unable to use the phone.

of course others will call you on this. and ideally a future infrastructure
for your country would not have the insecurity the internet does.
everyone is slowly working toward this goal. but it is an incremental
process. Java is an inherent part of that incremental process. no
one today can take java and say, "at last!! the net is secure!!". 
anyone who does this I agree is misguided.

> I have
>research analysts at large trading houses begging for
>Netscape. Unfortunately, these people have a need for top notch
>security, because vast amounts of money are at stake.

yes, I know that there are banks that don't understand that when
something is "secure", it still may not be sufficient for their needs,
which may require a whole higher order of security not available.
but any consultant worth his salt such as yourself will be able to
make a good judgement about the software and hardware they plug
in and guide the client. the point is that no one who wrote Java
is misleading the public, as you sometimes seem to imply.

however there are ways to use Netscape and java that make the
insecurity of the internet irrelevant. suppose that you put Java
inside an intranet inside a company. you already have a degree
of trust over employees. if you can demonstrate that your intranet
does not make any additional trust requirements than those you
already rely on, then sure, go ahead and use Netscape and Java in
an intranet, a semi-secure environment.

>So, yes, if you are going to create a product that everyone on earth
>has to be able to use, it had damn well not explode in your face every
>once in a while. Imagine if all the world's refrigerators had a 1 in
>10,000 chance of blowing up on you. "Whats the harm" you say. Well,
>most people don't expect that sort of behavior in a friendly consumer
>appliance that nice people from Sun and Netscape guarantee is
>absolutely positively safe except for all the bugs.

people will always put products to use in ways they were not designed.
the designers can try to anticipate this as much as possible but should
not be responsible for it ultimately.

>As I said, the traders don't expect that their phone will explode when
>they pick it up, or that every piece of literature they get in the
>mail may be coated with contact poison. Well, Java is a silent
>killer. It soon is going to be sitting on every desktop at every
>company in America and its being sold as the new paper or phone. Its
>also sitting on all those PCs running "Quicken" that helpfully now can
>do direct electronic funds transfer from your account, etc. If you
>don't care about the security of your bank account, well, sure, you
>have nothing to worry about.

I trust that those who implement bank security, such as yourself, will
not use a widget where a gadget is actually called for. really, humanity
is not *totally* stupid. there are two classes of people for our purposes:
those that build the systems, and those that use them. stupidity on the
part of the latter is not a problem if you have good designers; their
mistakes are protected against and are not made fatal. 

stupidity on the part of the former-- well, what can you possibly do
to avoid ramifications of bad design? it seems to me if your designers
are bad, you can't rely on anything whatsoever. a good designer is
not going to use Java in an inappropriate environment. are you complaining
that "there are a lot of bonehead designers that create bad systems"?
agreed, but what can Java do about it? a tool cannot necessarily 
prevent its own misuse. in fact Java goes to great lengths to avoid
the problems that arise in regular programming languages, such as
memory leaks.

>In short, my clients need security today. Your home computer probably
>needs it soon if not now, and if you think your business can survive a
>few days without its computers, please, by all means, run without
>security.

but Java did not claim to be your savior for security. maybe someone
will augment it to the point that you are happy. in the meantime why
are you criticizing it for being unable to handle something it was not
designed to handle?

>Its not Java crashing that I worry about. Its everything else on the
>computer and the network it is attached to that needs protection.

I see. so Java designers need to solve every security problem on the
planet for you not to criticize that language. look, security problems
exist and are all over the place, I agree. the internet is insecure.
people rely on this insecurity. but again, why are you ranting at
Java designers for all these other problems? Java is a step in the
right direction. it is a new attitude change. when we do have secure
networks in the future, I think people will look back on Java as
a milestone, not a trip-up.

>Well, sorry, you try to keep it off the desks in the banking industry
>if you can.

again, if a bonehead designer uses something in the way it was not
intended, are you going to blame the person who made the hammer?

>Life critical applications or important financial applications are all
>around us. You just don't seem to notice.

I agree they are all around us. but again, why are you ranting at Java
because you don't have tools to make your job a piece of cake? that's
what a good designer does-- takes pieces that in themselves may insufficient
to accomplish his job, and puts them together in a way that they do.

> It is difficult. The way Java does this, with the protection relying
> solely on the correctness of the runtime (the interpreter isn't
> emasculated so flaws in the runtime can cause unexpected behavior) it
> is nearly impossible. Humans aren't good enough at designing systems
> this century.

One thing that I'm sort of fuzzy on is whether or not you feel that this 
is a problem specific to this one group of products (java) or if it's a 
problem with the general idea of grabbing and running applets 
indiscriminently in a protective environment.

As some recent posts here have shown, when people start working with java
applets, subtle problems (like not being able to put your hands on enough
entropy) emerge.  It may turn out that after a year or two the list of
complaints will be long enough that a demand for a successor to java will
emerge.  I would have to think that after a bit of practical experience, 
it will be possible to build a better java.

Right now, as near as I can tell, we have two major security complaints
with java's design.  The first is Perry's point (which I might be
munging), that there isn't enough redundancy in the security to protect us
if and when human error creeps in.  The second is that a rigorous formal
analysis of the language hasn't been performed, and that the language as
it is currently constituted doesn't lend itself to such an analysis. 

Can these problems be solved, at least in theory, in a new language?  
Are there other changes that ought to be considered?  Etc.

Alex Strasheim writes:
> One thing that I'm sort of fuzzy on is whether or not you feel that this 
> is a problem specific to this one group of products (java) or if it's a 
> problem with the general idea of grabbing and running applets 
> indiscriminently in a protective environment.

I believe that it is possible to design environments in which you can
safely run applet like things. However, 1) I am not sure that such an
environment is needed for most of what Java does in the Netscape
environment, so given the dangers I'm not sure the price is worth
paying, 2) Java does not possess the characteristics such an
environment needs, and 3) It is pretty clear that much of what the
Java designers want to do could not be done in such an environment.

> Right now, as near as I can tell, we have two major security complaints
> with java's design.  The first is Perry's point (which I might be
> munging), that there isn't enough redundancy in the security to protect us
> if and when human error creeps in.  The second is that a rigorous formal
> analysis of the language hasn't been performed, and that the language as
> it is currently constituted doesn't lend itself to such an analysis. 

I would very much prefer a language who's security did not require
such analysis. Java, sadly, does require such an analysis because it
requires perfect implementation for its security model to work. In a
restricted execution environment that was designed with defense in
depth in mind, such an analysis would be a bonus, but not strictly
required.

Perry

Perry, perhaps you might be interested in outlining how 
Java designers might incorporate the concept of "defense in 
depth" that allows for even buggy implementations to have
security.

again, your criticisms of it sound like they might potentially
be ameliorated by a secure implementation of Java. remember,
Java is a language, not necessarily an implentation. designers
have some way in the way they actually implement the language.
an implementation with the zillions of firewalls or whatever
you are advocating for the financial industry might actually
emerge. 

but again, the Java designers never claimed that
"Perry Metzger will be able to use Java in his mission critical
funds transfer application". your ranting against it has decreased
noticably in intensity but I don't think it was ever justified
in the first place.

"L.Detweiler" writes:
> but again, the Java designers never claimed that
> "Perry Metzger will be able to use Java in his mission critical
> funds transfer application".

And, Detweiler, I keep saying that I don't care about not being able
to use it there -- the problem is even having a copy of Netscape with
Java enabled on the same machine as a trading system. One instance of
Netscape running Java can endanger an entire trading floor.

.pm

>> but again, the Java designers never claimed that
>> "Perry Metzger will be able to use Java in his mission critical
>> funds transfer application".
>
>I keep saying that I don't care about not being able
>to use it there -- the problem is even having a copy of Netscape with
>Java enabled on the same machine as a trading system. One instance of
>Netscape running Java can endanger an entire trading floor.

right. substitute "unapproved software" wherever you use the
term "Java" and you will see that at the heart of it
you don't really have a real case against Java in particular.

what is your point? that someone suitably paranoid would never
come close to running Java on their machine? I fully agree with
you there.

oh, I should think that a suitably paranoid sysadmin will be sure
to create an oppressive, straightjacket
environment in which "unapproved software" would be squelched or would 
never have a chance to run in the first place. it seems
to me if you have to worry about it happening, you've already
lost.

in fact the NSA thrives on solving these kinds of problems. I 
once worked with a guy that emanated out of that black hole, and
I found him highly capable of squelching any possible 
incongruous or creative thought that crossed his path, in the
same way that state-of-the-art software is routinely denied
employees of companies out of security paranoia.

if you want to live in the world, you will always face some kind
of insecurity. freedom and restriction are mutually exclusive.
if you are against freedom in software choice by end users in 
an environment you control, well, what does Java have to do with that? 
its just another insignificant program on the long list of software
you don't allow. although, I suppose, a
particularly scary one at that--one that denies
the whole paradigm of control by a central authority over software
to obtain security, offering a contrary solution that may be
workable in the long run, and might even flourish.

On Tue, 30 Apr 1996, Perry E. Metzger wrote:
> The Web is the universal marketplace these days. Being unable to use
> the web is the equivalent of being unable to use the phone. I have

	I'm sorry, I don't buy this. Last time I saw any stats, less than
5% of AMERICANS have access to the internet in any form. Even if it has
doubled in the last 3 months, that is still only 10%, Now yes, someday
what you say may be true, but most people have never seen the web, execpt
_maybe_ on TV. My father runs a relatively sucessful business, which he
started last year, and he has almost never used a computer more
sophisticated than a calculator (I gave him a zenith supersport (8088)
laptop that he has turned on ONCE)--he dosen't even believe in Cash
Stations). To claim that that being unable to use the web is the 
equivalent of being unable to use the phone is silly, and to an extent 
myopic. 

> research analysts at large trading houses begging for
> Netscape. Unfortunately, these people have a need for top notch
> security, because vast amounts of money are at stake.

	There is a simple, but expensive way around this. 

	The rest cut because I am not qualified to comment


Petro, Christopher C.
petro@suba.com <prefered for any non-list stuff>
snow@crash.suba.com