"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."
Timothy C. May writes:
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.)
Don't take this the wrong way, Tim, but you have totally misinterpreted the position many of us who dislike Java take. You completely mischaracterize our attitude. 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
participants (5)
-
Alex Strasheim -
Perry E. Metzger -
snow -
tcmay＠got.net -
Vladimir Z. Nuri