The discussions about "NOPLATE" reminded me of an incident that occurred two years ago. Also related is the hazards of using the first match from a database. I was in an auto accident. The other driver was clearly at fault; however, the police check the computer for both drivers and vehicles as a routine measure. The policeman called my plate in: N8SQ. I have amateur radio callsign plates. The response on the radio was something like: "1974 Ford pickup truck, Farmer Jones, Circleville, Ohio. No wants or warrants." The policeman looked at me: the plates weren't on a truck, my name wasn't Jones, I wasn't from Circleville, etc. He was sure he'd caught a live one! Just then, over the radio came, "Wait a minute... There's ANOTHER one! 1986 Pontiac 6000, Stanley Quayle, ..." *whew*! Amateur radio callsigns start with A, K, N, or W. They have an optional letter, a required digit (0 through 9), and one to three letters. In Ohio, truck license plates start with N, have an optional letter, one to three digits, and one to three letters. This was the first I'd heard of the problem. However, since then, I've seen a car and truck with the same vanity plate, owned by different people. Truck plates are a different "series" than car plates, it seems. But they forgot to tell the computer that. Stanley F. Quayle UUCP: cbosgd!osu-cis!bcd-dyn!sfq (614) 424-4052 USPS: 505 King Ave., Columbus, OH 43201 N8SQ @ W8CQK Fido: Stanley Quayle, Node 1:226/610 My opinions are mine. What more of a disclaimer could you need?
Ohio requires SSN for issuing a driver's license. I don't like it, but they're within the federal law (as amended). However, they print the SSN on the face of the license, along with the DMV-issued license number. A chain of stores in the area requires a driver's license for identification when paying by check. The cashier enters the SSN from the license on the register. After a few seconds, at least in my case, an approval code returns. This store uses price scanners. It would be possible to establish a profile of each check-paying customer with this system. They can also do the same with each credit-card customer. They can link the credit-card numbers with SSN for those customers who rent video tapes, since both are required on the video application. The question is, do I complain to the store? If they haven't thought of this already, I don't want to give them any ideas. And, yes, I'm trying to pay by cash.
I finally read this book, after hearing about through this group. A few things bother me about it. First, a little background on myself, to make any possible biases evident. I fly airplanes recreationally, and have a Master's degree in Nuclear Engineering. First, the smallest nit: Twice in the book, once in the text and once in the glossary, "LNG" is defined as "Liquified Nitrogen Gas". Probably a common-mode failure. Of course, it's liquified natural gas. Much more flammable. Medium nit: References to the pilots with personal airplanes in southern California. He makes it sound like all pilots who like to fly are rich and inconsiderate. I almost stopped reading right there. At least I don't have any prejudices against book authors. And, the nuclear power nit: Well, he has a point. My own opinion is that the current crop of nuclear power plants are too complicated and too difficult to control and maintain. Some of his facts sound like he doesn't understand nuclear power very well. (Sorry, no specific examples right now.) The length he goes to bury nuclear power appears to be born from a dislike of the concept rather than analysis of it. And he doesn't mention any of the proposals for inherently-safe reactors. There are designs available now that are simple and that don't have complex interactions. Overall, however, it is a fascinating book. The parts about marine safety are really shocking. I'm glad that I'm living a long way from water. By all means, read this book.
One should not be surprised that the discussion of viruses by computer users should focus on how to protect their own systems. However, as I read RISKS I become concerned that is how the problem is perceived. A virus is a special case. It is a social disease. It attacks not only a target system, but a population of systems, and social order all at the same time. I am sure that if you have imported one into your system and if it does something destructive, you will see primarily in terms of the destruction that it does. However, similar damage could have been done by any Trojan Horse or even by your own error. The problem with the virus is not in the damage that it does to one system, but with the damage that it does to a population and to the fabric of trust that is essential to the sharing of programs and other data and to commerce in general. Suppose that viruses become so pervasive that even those who have never seen one become afraid to use any program that they did not write themselves. Suppose that because of the publicity received by viruses, the public at large were to loose confidence in all computers, in the information they generate, and in information in general. If you think that that is far-fetched, then I ask you to think back to the panic that followed the Tylenol contamination. In a society in which 1500 hundred people a year die early because of the use of asbestos, another 15000 from the use of fossil fuels, 40,000 from the use of the automobile and 200,000 from the use of tobacco, the level of concern was out of any realistic proportion to the number of deaths. But it was not out of proportion to the effect of the loss of confidence in the medicine supply or even of the food supply. I suggest that it was the unconscious concern for the effects of the potential loss of confidence that caused the panic. The perpetrators of the virus know very well how it will behave in the target system, but they have no idea how it will behave in the population. The XMASCARD program did not do any damage in the user's machine, but it brought a multi-million dollar network to its knees. The scope and sensitivity of that network was not only beyond the perpetrator's knowledge, but it was beyond his comprehension. The perpetrators of these toys are, like the sorceror's apprentice, playing with powers far beyond their knowledge or control. The potential for damage is far beyond their puny powers to predict, skills, motives, or their intent. They are toying with the mechanisms of cooperation and coordination that characterize humanity. They are to be pitied for their ignorance, but they are not to be tolerated, much less admired or emulated. A society that depends for its own proper functioning upon any mechanism, dare not tolerate any interference with the intended operation of that mechanism.
On April 22, 1988 I received two back issues of a newsletter entitled "Computer Virology" along with along with a product description for the Disk Defender (tm). "Computer Virology is published in Evanston, Illinois by Director Technologies, Inc. Director Technologies is the manufacturer of DISK DEFENDER, a product which write protects in hardware all or part of a personal computer hard disk. It is our belief that hardware write protection is the only 100% reliable virus protection for the operating system and commonly used programs. If you have any comments, questions, suggestions or article submissions, please address them to: Director Technologies, Inc., Technology Innovation Center 906 University Place, Evanston, IL 60201 312-491-2334 [Quoted without permission from the masthead of the newsletter. I am in no way associated with this firm. This is not a recommendation or endorsement of their product.] The product appears to be a half-card that installs between the drive and the hard disk drive controller card. It can make a portion of the or all the hard disk "write-protected." It has an outboard component with a 3-position switch which permits you to select between "full|zone|none." The outboard switch can be removed in order to remove the discretion from the user. In other words, it is a hardware write-protect tab for a hard drive zone. The size of the zone appears to be chosen by setting dip-switches on the card itself. To suggest that it is 100% effective against a virus is to overstate. Studies in biology suggest that a virus can thrive even in a population in which a large percentage of the members are immune, if a there is sufficient commerce among the non-immune members. This is not an argument against vaccines but only a caution about the limits of their effectiveness. Depending upon design of the virus, the target system and population, and the chosen distribution vector, the effectiveness of this mechanism against the spread of the virus might vary from high to none at all. Good hygiene is the general defense against viruses, but there are limits to how effective it can be. Nonetheless, the individual can and should protect himself within those limits. Bill Murray WHMurray at DOCKMASTER
In RISKS 6:72, Hugh Davies comments on a problem with text being garbled due to the software and hardware disagreeing about the presence of a floating point processor. I'm told that at least in DEC's VAX line, the ULTRIX (UNIX-like) system can be made to handle characters with significantly higher speed by adding an FPP to the computer. Apparently the FP opcodes provide some kind of fast path which can be exploited by programs which are processing strings, even if no floating point calculations are performed. Perhaps some parts of the system recognized the presence of the hardware while others didn't. If A interfaces with B and each has a different set of assumptions about the environment, the results can be "interesting" if they also assume that everybody agrees. (Remember the analysis of the word "assume"? It makes an ASS out of U and ME.) There is an indirect RISK here in that an optional feature on the computer is named in a way which fails to describe its function. Who would have thought that floating point hardware would improve character processing?
I assume when people load containers into ATMs, they replace the ones already loaded with another set. They then return the first set for accounting purposes. Seems like the problem of having people install cash containers in ATMs incorrectly could be (partially) solved by a technique mentioned in at least two other areas in RISKS. In the last issue (6.72), we heard how an airline company fixed a problem of crossing their fire extinguishing lines by making the connections different sizes. Some time ago, there was a discussion on plugging medical equipment into the wrong sockets. (Come to think of it, a third area was the ability to plug some computer equipment (LAN connections?) into a wrong socket (no pun intended)) The different containers could have a small bit of metal or plastic added to them that would fit only in the proper slot in the ATM. This at least reduces the risk; you still have to have the person originally loading the container do so with the correct denomination. Another simple fix (but not as robust) would be to color code each container. Joseph
%A Willard A. Dodge, Jr. %A Reuben B. Moulton %A Harrison W. Sigworth %A Adrian C. Smith, Jr. %T Legends of Caltech %I California of Institute of Technology, Alumni Association %C Pasadena, CA 91125 %D 1983 %K ARCHES program, senior ditch day, room stacking, color blindness and traffic jams, Rose Bowl Hoax 1961 (U of WA ). I am surprised at the number of peple who think this is just a text file which you can just FTP. [Oh, Aaron Schuman, you can just look at my copy.] Please do not send me mail on this. This is a published book which costs $10 and has important photos inside it. (Text is completely inadequate to describe this book, it has photographic proof.) If you want a copy, please contact the Caltech Bookstore. The general number for Caltech is (818)-356-6811. P.S. There is also a Climber's Guide to the Caltech Campus (EE Dept.) which I also have a copy (for a different type of RISK). Any resemblence to the film "Real Genius" by M. Coolidge is intentional. The Book does not contain recent stories of 1) the Rose Bowl Attack on the score bowl (MIT 6 Caltech 25) [documented in earlier RISKs], or 2) the recent changing of the Hollywood sign. This will all have to be covered in some future edition. Of computer interest is the ARCHES program which was used to stuff 1.5 million entry addresses into a McDonald's contest in the 1970s. This 11 line FORTRAN program is the reason why game cards make comments about no electronic reproduction. Please note: I was never a Caltech student. I have many friends there and was a Caltech employee at its Jet Propulsion Lab and at the Institute (CS Dept.) itself for which I have the greatest respect [I would rather donate money to them than my old UC campus, it's better spent at Caltech]. --eugene miya
I have been trying to keep track of Macintosh viruses, but unfortunately my input is limited to articles in this group and on the news networks. I've tried to send out surveys and solicit virus information from several different sources, but everyone refuses to give you any information on the virus. I have no idea of how to legitimatize myself! I am sincerely interested in studying and tracking these rascals, but everyone assumes I'm just trying to do further damage to the community. Phone calls don't help! Letterhead doesn't help! Calls from officials at my University don't help! I realize people have to cautious, but I'm stumped! How do we solve a problem no one is willing to discuss? Everyone who gets a virus posts a message telling what it does and how to rip it out of an infected system. Ask for any other information on the virus, and you hit a brick wall. I am willing to study and track all Macintosh viruses, but it will take the cooperation of those getting the viruses to help solve the problem. I welcome ANY feedback on this! Any suggestions? Any of you out there who have viruses willing to cooperate? Any government agency out there willing to investigate me and verify my intentions? (A frustrated) Chip Copper, Ph.D. Assistant Professor Department of Computer Science Bowling Green State University Bowling Green, Ohio 43403-0214 (419) 372-8142 (My office) (419) 372-2337 (Department office)
My wife deposited a cheque in a Pittsburgh National Bank ATM. After the ATM had accepted the cheque, it aborted the transaction for some reason. She complained to the bank, and they assured her that everything would be taken care of. What actually happened is that all of our cheques this month bounced... Some years ago, I banked with the Canadian Imperial Bank of Commerce. The Commerce's system for deposits was different from any I've seen in the U.S.: After keying in the particulars of your deposit, the system issued you a deposit ticket which you then inserted into the envelope with the deposit. When the transaction completed, you got the standard receipt. This simple scheme was very useful because (1) it allowed you to deposit money without getting frostbite while writing the particulars on the envelope, (2) it provided a transaction identifier which the bank could (and presumably did) use to verify that the transaction was committed, without any possible ambiguity, and (3) it guarded against any mistakes that you might make (listing a different chequing account, etc.), which would be compounded by an error on the part of the ATM (such as aborting the transaction), and (4) it provided a printed verification of the particulars of the transaction that the user could check just before committing his end of the transaction. I suppose it's possible that the American systems print this information directly on the envelope as it's sucked into the ATM, but that doesn't seem very likely. In any event this would obviate the advantage of *knowing* that a readable printed record was actually enclosed with the deposit.
A few weeks ago I went to a local First Interstate Bank branch and tried to withdraw some cash, using my Xerox Federal Credit Union card. I got a rather vague message back, something like "unable to complete transaction". Thinking it might be a local ATM problem, I went a couple of miles down the road to the El Segundo First Bank. That ATM told me "Your card is damaged". The next morning I called XFCU and ordered another card (which takes them over a week to mail to me). I also retried the old card at XFCU. Lo and behold, it worked! It has since worked at many ATM's, including the one that gave me the bogus "damaged" message. I wonder how much these vague or bogus error messages are costing the financial institutions in this country? What's so difficult about putting up a message like, "Unable to communicate with your bank's computer at this time. Try again in a few hours."? --Bruce
George Michaelson, CSIRO Division of Information Technology ACSnet: G.Michaelson@ditmela.oz.au Phone: +61 3 347 8644 Postal: CSIRO, 55 Barry St, Carlton, Vic 3053 Oz Fax: +61 3 347 8987 (written by Colin Brammall in Computerworld Australia, reproduced without permission) HEADLINE: GOSSIP DATABASE - Uni dossier of 'soft' info SYDNEY - A computer-based intelligence-gathering system, which creates dossiers of "soft information" such as rumour, gossip, ideas and personal assessments has been developed at the University of N.S.W. Several Federal Government [that means Australia not USA] bodies including the Army and the Department of Industrial Relations have been shown the product, which runs on any DEC vax machine. It has apparent potential for intelligence bodies such as Asio and Asis and even for Federal cabinet, as well as for departmental and private-enterprise hierarchies. The basis is a high-level messaging system linked to a database which electronically duplicates face-to-face meetings. It is intended to pull together relevant information that might otherwise remain in individuals minds. The discussion/conference is simple. "If people read a message and they want to add to the information, or challenge it, they comment on it, which causes a conference to be created, and a debate opens up with all interested people on the system," said Cyril Brookes, professor of information systems at UNSW, who headed the team which developed the system. The keyword/message system is based on a thesaurus of terms unique to the user organisation, designed to cover all the concepts that anybody in the organisation is likely to message about. Each message is coded with one or more of the thesaurus terms, and is given a level of importance. The highest level might be for the minister/chairman of the board, the next for all first assistant secretaries/general managers and so on. Each user builds an interest profile, putting an order on the system for messages containing certain topics, sub-topics and keywords, and levels of importance. Professor Brookes said the system reported informal information in much the same way that traditional databases reported formal information through such things as exception alerting and as-necessary detail. Because soft information did not pop completely in one place or time, the system brought together all the people who had information to contribute. "we have been fascinated for 10 years or so about the lack of attention paid by the computer community to informal or soft information" Brookes said. "it is my view that the informal data are the most under-utilised resource that managers have available to them." Normal databases recorded history he said. "The future, which is what decisions are about, is not related to history tremendously. The clues to what is going to happen are in peoples minds and in their informal contacts." Bulletin boards and messaging systems do not do the job because they do not massage the information.
Please report problems with the web pages to the maintainer