16-Jul-86 21:42:29-PDT,12450;000000000000 Mail-From: NEUMANN created at 16-Jul-86 21:40:34 Date: Wed 16 Jul 86 21:40:34-PDT From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-3.21 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Tuesday, 15 July 1986 Volume 3 : Issue 21 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Responsibility (Willis Ware) Programming languages and computer literacy (Bob Estell) Teaching about risks, BASIC, NASA, etc. (Eugene Miya) Programming Languages (Matthew Kruk) BBoard Lingo (Trojan viruses,...) (Hank Burchard, via Peter G. Neumann) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in SRI-CSL:RISKS-i.j. Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.) ---------------------------------------------------------------------- To: RISKS@csl.sri.com Subject: Re: Responsibility (RISKS-3.20) Date: Wed, 16 Jul 86 09:24:36 PDT From: willis@rand-unix.ARPA 1. Re Dave Benson's comments on responsibility. I suspect that professional licensing has one more attribute that he didn't mention; namely, it establishes some legal status and legal liability for the licensee. And it may therefore give injured parties standing to sue the licensee for injury and/or damages. Also: what about the position that software is a consumer product? If that were to be established, then all of the consumer protection legal apparatus and consusmer protection groups would come into play -- and maybe do something useful. IDEA: You know Susan Nycum; ask her to express an opinion on the issue and the various views. 2. Re Ron Morgan's views. I couldn't agree more with his lament that people equate "computer literacy" with "ability to program", or even worse with "ability to program properly and produce a well checked-out, tested, and documented product that will meet specifications." They are NOT synonymous concepts, but they are related. When the term [computer literacy] was first used and talked about more than 20 years in discussions here at Rand and elsewhere (notably by Paul Armer and Fred Gruenberger, names which I'll wager readers of RISKS don't even know), it meant simply some awareness and understanding of computery; e.g., how they work, what a program is all about, possibly some very low level of being able to use one or at least to stroke a keypunch successfully. YES, Virgina, it was keypunches in those days, not terminals. Automatically of course, the professional programmer knew all about such things, and was computer literate. But the converse was not true: a computer literate did not automatically have all the qualifications, skills and experience of the professional -- or even semi-professional -- programmer. The original intent was primarily to head off the fear that individuals -- and managers and organizations -- then seemed to have of computers. They were strange beasts, using strange technology, doing mysterious and invisible things and seemingly not subject to the usual precepts of management. There was also a conviction even more than 20 years ago that computers would be important in society and in the world and would have a profound effect. One can find papers on the subject in the Joint Computer Conferences of the early 60s. Thus, it was argued that people should simply be acquainted with computery and be able to fit computers into their frames of reference comfortably, and accept them as commonplace mechanisms. Remember when you read this: I'm talking of the period when it was all mainframes and centralized computing shops, and the programming fraternity argued persuasively for and held sway in the closed-shop! By analogy, it was like "automobile literacy" which is a characteristic that we all have even tho we don't repair our own cars or even know what's under the hood. In fact just that sort of argument was used to get the term established. Or again, being "language literate" doesn't mean that one can write Pulitzer material, only that he can read and write the language. A literate person may, but need not, be literary, educated and cultured. We'd do well in the computer field to mind our definitions and semantics. Willis H. Ware, Rand Corporation, Santa Monica, CA, willis @ rand-unix ------------------------------ Date: 16 Jul 86 08:39:00 PST From: "143C::ESTELL" Subject: Programming languages and computer literacy To: "risks" I'm somewhat repeating some of PGN's words of wisdom here, but I must share a gem I got years ago from Lawrence Flon, then at CMU; it's Flon's axiom, and it goes like this: "There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs." The entire article is worth digging out and reading; it's in SIGPLAN Notices, October '75. Sure, BASIC, FORTRAN, COBOL, et al, and certainly Pascal and the other structured languages have taken us away from many of the syntactic errors that bedeviled assembly code; like erasing the (primitive) operating system, or jumping into a data field and crashing the processor on an illegal op code. Cross reference checks, type checking, et al may get us a bit away from semantic errors as well. But what's to keep us from writing just plain wrong formulas? This is parallel to trying to educate surgeons to prevent "bad" operations. Switching analogies, maybe computer literacy should be the equivalent of the "driver's license" (my earlier analogy); and programming licenses should be the equivalent of the auto mechanic's license. Bob ------------------------------ From: eugene@AMES-NAS.ARPA (Eugene Miya) Date: 16 Jul 1986 1008-PDT (Wednesday) To: Subject: Teaching about risks, BASIC, NASA, etc. (RISKS-3.20) I will keep PGN's comments on Cramer's message about irrelevance in mind, but I will come close to straying. In his most recent RISK posting, Dr. Benson alluded to "Certification" a time honored topic of the 1960s (certainly predating me). While I am familiar with the so call Certified Data Processing certificate, I have met very few CDPors. Is what these people inadequate for RISKy systems? Should we update the CDP to include more than business type DP or should we have a more professional (i.e., doctors and lawyers) bonding? I don't know, but it seem a weak basis already exists and is not used, or is used weakly. Several writers alluded to BASIC. Several more said it was irrelevant, I agree. Real-time BASIC is (or was) used by the Navy in ship-board air defense (I was told), and I know it is used in the Deep Space Network for communications with unmmanned planetary probes. Those pictures you see of controllers at the Manned Space Center are NOT programmers, they are physicists, EEs, and other types of engineers. It was recently emphasized in one computer ad that most did not know how to program and that some were learning another Real-time BASIC. For them, the interaction is important; if anything, someone needs to develop a better interactive language to combat the problems mentioned in earlier postings. The "compiled batch" oriented nature of most programming languages are not always conducive to complex control systems. I am not, BTW, and have not worked in complex real-time flight systems. I do not want to worry about those RISKs, and we have all heard the stories about people with broken homes, etc. (few) because they could not handle the stress associated. Most of these flight system programmers are everyday programmers (except they work with flight qualified hardware: slower, smaller memory, etc.). Think what you will of them, they don't all program in Ada yet. If you are interested in this type of work, you should be ready for Congressional investigations (I worked on a project which had one.), and people staring you in the face and asking you tough questions about schedules (isn't hindsight wonderful). This all finally focuses on our attitudes on how we teach risks and computing. Attitude is very important. In private correspondence to our editor, I noted am example of attitude shift in my avocation. Prior to 1946, rock climbers had a saying "The Leader (guy going first) must NOT fall." After the publication of a book entitled Belaying the Leader, climbers took a new implicit approach to belay: "The Leader will fall, what are you going to do about?" The training emphasis shifted to practicing for worse case situations. Climbing in the world went to greater levels of difficulty, fewer trained climbers were killed, and American climbing became a new standard in the world. I think we in computers are in the earliest stages of this. We don't have all the tools for a transition of ideas. But, I hope this qualitative analogy helps. Hope I didn't stray too far. --eugene miya NASA Ames Research Center ------------------------------ Date: Wed, 16 Jul 86 10:11:50 PDT From: Matthew_Kruk%UBC.MAILNET@MIT-MULTICS.ARPA To: Neumann@CSL.SRI.COM Subject: Programming Languages ReSent-To: RISKS@CSL.SRI.COM You have my vote: the less intrinsic pitfalls in a programming language, the better. The "Roman Language Empire" is still young and we should strive for progressive language development or fall. I do not deny that many "good" programs, programmers and languages exist but the day we become complacent and cease laughing is the day we become prey to our own pitfalls. We should come to expect better and not merely be satisfied. (I do not want to start or see a "which programming language is best" debate. In some cases, the simple answer is "that which an individual is most competent at". This can be resolved in your own mind; typically, and sadly, it is resolved by your employer.) ------------------------------ Date: Wed 16 Jul 86 21:18:22-PDT From: Peter G. Neumann Subject: BBoard Lingo To: RISKS@CSL.SRI.COM From the Weekend section of the Washington Post, Friday, 11 July 1986, on a page by Hank Burchard (Weekend at Home) devoted to home computing: Blitz Course in Bulletin Board Lingo [Excerpts] ARCHIVE -- Archiving is a method of compressing programs to have their original size, which makes them much faster to transmit on a modem. Since nearly everything in BBS program files is archived, an ARC(hive) coding/ decoding program is one of the first things ou should look for when cruising bulletin boards; "download" a copy for your own use. Don't use any AC program with a number higher than 5.12. AC5.13 and AC5.14 have been reported to be system-sabotaging Virus and Trojan programs. SOFTWARE SUCKER -- The bane of sysops [SYStem OPerators]. Suckers are people who sign on to a board for one reason: to copy programs. They will download any program they find, whether or not they have any use for it, meanwhile tying up the line. TROJAN HORSE -- One way to crash a BBS. A Trojan Horse is an innocuous- looking origran that when run reformats your harddrive, destroying all your files. To protect yourself against this, ask the store where you bought your computer, or an experienced computing friend, for a Trojan detector program. One very good one is called "Check4Bomb". Put every program you download through this before you run it. This won't catch every bad program (the inventors tend to be ingenious) but it will stop most of them. VIRUS -- A virus program is a relative of a Trojan horse, but is usually inserted in a proven program. Users are often less suspicious of well-known programs. [I toss this one in for good measure. The RISKS OF BBOARDS are rampant, but so are the RISKS OF OVERSIMPLIFICATION. PGN] ------------------------------ End of RISKS-FORUM Digest ************************