1-Apr-95 0:31:59-GMT,28558;000000000001 Received: from aramis.rutgers.edu (aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA20380 for ; Fri, 31 Mar 1995 19:31:57 -0500 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.11) with ESMTP id TAA03051 for ; Fri, 31 Mar 1995 19:31:55 -0500 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.11) with SMTP id TAA02335 for ; Fri, 31 Mar 1995 19:31:48 -0500 Received: by chiron.csl.sri.com id AA12581 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Fri, 31 Mar 1995 16:23:48 -0800 From: RISKS Forum Sender: RISKS Forum Date: Fri, 31 Mar 95 16:23:47 PST Subject: RISKS DIGEST 17.02 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 30 March 1995 Volume 17 : Issue 02 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Re: Internet cybergambling (via PGN) Denial of Service Attacks, Jack Jaunters, and the Cool Site of the Day (Jerry Bakin) More on German Train Problems (Debora Weber-Wulff) Computer Crackers Sentenced (Edupage) Self-Censorship of NetPorn (Peter Wayner) RISKS of Green PCs and Disk Caches (Todd W Burgess) "thin, thin, thin computer candy shell" (Peter da Silva) Re: Risks of doing date arithmetic (Bob Frankston) More date/time problems (VAX) (Lord Wodehouse) RISKS of non-standard interfaces (Richard Schroeppel) ABRIDGED Info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat 1 April 1995 00:00:00 GMT (+0) From: info@microsoft.com To: RISKS@csl.sri.com Subject: Re: Internet cybergambling [This message was received by RISKS@csl.sri.com at 04:00:00 PST Friday, in answer to an earlier request for clarification. It may be freely redistributed. BTW, I just returned from a really lively Computers, Freedom and Privacy 1995; I hope some RISKS readers will provide write-ups of their most interesting sessions. P.G. Neumann] In response to your query, we wish to inform you that Bill Gates will announce later today that Microsoft has entered into an arrangement with Native American Virtual Activities to develop a computerized casino that will be accessible on the Internet as well as by dial-ups, with a toll-free 800 number for U.S. patrons. User-supportive software will be bundled at no extra cost within Windows 95. During April, further software will be added compatibly to Bob, Microsoft's new user-friendly empowerment package -- which was officially released yesterday. Bob will even be able to analyze your gambling habits and prompt you if you do something stupid. Microsoft has struck a deal with the National Security Agency under which good crypto (80-bit SKIPJACK, implemented in software) can be used internationally. The deal involves export controls being waived in return for NSA getting a 1.5% share of the profits, the crypto keys being escrowed by yet-to-be-named agencies of the U.S. Government (insiders suggest Treasury and the FBI), and Microsoft promising to keep the crypto from falling into the hands of undesirable elements such as organized crime. PGP will be used to envelope the electronic communications, and its creator Philip Zimmermann will be on the governing board of NAVA, along with Bill Gates, Richard Stallman of the Free Software Foundation, and Steven Spielberg on behalf of DreamWorks SKG. Conservative projections indicate that this will be enormously profitable for all concerned, including the U.S. Government -- which will instantaneously receive withheld taxes on all winnings via Internet electronic funds transfer, based on the use of a valid Social Security Number. Special extended social-security numbers will be allocated for foreign individuals who wish to participate from abroad, although they will generally be subject to a nonrefundable U.S. tax. Cooperation with tax agencies of foreign governments is anticipated. The newly reconstituted Bureau of Wish and Game will oversee the operation. The virtual casino will be operated onshore from specially dedicated Indian lands that are not under state or Federal jurisdiction. However, the operation is expected to be so lucrative that it will voluntarily contribute taxes to the two states that will house the geographically dispersed interoperating computer systems designed to ensure very high system availability. For those states in which gambling is illegal, remote services will be provided so that the activities can legally be conducted remotely from another state, such as Nevada or New Jersey. It is likely that states currently banning gambling will be incentivized to change their laws by the standing offer of tax revenues collected from bettors in their home states. Several banking institutions have already expressed interest in extending their automatic teller-machine functionality, trying to preempt competition from the Internet-compatible First Bank of Internet Visa (TM) ATM cards. Overall, this operation has the potential to completely eliminate national and state deficits. Despite the security and integrity risks raised in a recent article by John Markoff of The New York Times, and some concerns about the socially regressive and antidisestablishmentarian consequences of gambling, there seems to be little opposition to this remarkable confluence of usually disparate interests -- other than from its would-be competitors, Virtual Vegas, the already existing free Internet casino operated from Santa Monica, Calif., and the Online Offshore Casino and Sports Book -- which is expected to open for business next month in the Bahamas. ------------------------------ Date: Wed, 29 Mar 1995 14:02:07 PST From: Jerry Bakin Subject: Denial of Service Attacks, Jack Jaunters, and the Cool Site of the Day Risks of being the Cool Site of the Day: (http://www.infi.net/cool.html) Have you read Alfred Bester's "The Stars My Destination". I just read the Cool Site of the Day FAQ (http://www.infi.net/CSotDFAQ.html) and I found that the sections on "How much traffic can my site expect..." (lots), "What should I do if I'm selected and I find that my site cannot handle the lads involved?" (replace your cool page with a text only page), and "Why would I want my site to be a CSotD" (it's the exposure) parallel the problems described as "jack jaunting". In the Stars My Destination, people found they could teleport (jaunte) at will with proper mental focus (What's your URL?). They lived in a world with almost infinitely quick dissemination of information about current events (Netnews, Websites, and CNN). One result was that when a "cool site" became known, it would become flooded with vast numbers of jaunters from around the world. Many of these jaunters were malicious and used the cover of the millions of other people to perpetrate crimes. For instance, if a fire were televised (today I heard that the Fulton Seafood Market is burning down) thousands of people would jaunte in to be tourists. Some of the people would use the opportunity to pillage. The parallels between the CSotD and Jack Jaunting break down here, because there is no overtly malicious motive, but there is the likelihood of a Denial of Service Attack. It's interesting. You want to be a Cool Site. I want to know of the Cool Sites. Being a Known Cool Site may lead to your demise as a Cool Site. There's nothing new here, this is exactly the same problem as that known as the "Restaurant Review Effect", but it is interesting to see how real life is being recreated in cyberspace. Jerry ------------------------------ Date: Wed, 29 Mar 1995 11:09:50 +0200 From: weberwu@cha01.tfh-berlin.de (Debora Weber-Wulff) Subject: More on German Train Problems So, here's a "real" article, just one little rumor at the end. Some folks objected to me posting rumors, but there are some folks who will talk only on the condition of anonymity, wanting to keep their jobs... >From Computerwoche 12, 24.March1995, page 27 (in German, translation mine, all translation errors mine) CW-report by Walter Mehl (Hamburg) "Siemens computer stops switching system (Stellwerk) in Hamburg" >From Monday to Wednesday last week all signals at the train station in Hamburg-Altona were on stop. [Must be more, I travelled from Hamburg on Friday and waited an hour because of "computer problems"] Just like it was when track was first invented, the switches could be set only by using a crowbar-sized key to shove them into position. The fault was with a computer from the company Siemens, that had gone on-line the day before. The train station in Altona is home to pigeons and seagulls. They had 3 days of peace and quiet while scavenging for food between the tracks and sleeping on the catenaries. Since the morning of 13 March, nothing works anymore in the digital switching station: the main computer from Siemens quit after an error in the main memory occurred. [couple of paragraphs about all the bother people had to go to to get where they wanted to go] ... as we go to print it is not clear if the Deutsche Bahn will demand money back from Siemens. The Bahn was extremely proud of its new digital helper - in their own publication "Der Zug" they had a long article about it. The new technology cost 62.6 million DM (about 45 million $), Siemens pocketed about 2/3 of that sum. The Siemens computer replaced 8 conventional switching systems, which were installed between 1911 and 1952. They controlled all the switches and signals in the station area. In fail-safe mode all signals are red and the switches can be set only by hand. In Altona Siemens first [!!!] used the Simis-3216-computer which uses an Intel 486 chip. Siemens makes these system extremely robust: they can take temperatures between -40 and +85 degrees Celsius and can withstand up to 5 times the earths acceleration in force. Not even a signal with 2000 Volt can influence the running of the system. For security reasons they are run in a 2-out-of-three mode, there are 3 identical computers on site, each could work alone. 2 are constantly running in parallel, so that if something goes wrong the replacement one can be switched on immediately, the normal working of the system is given in just a few minutes. When the system is working normally, each of the two computers control each other, and when both determine the same result, then the switch or signal are thrown. It was determined that the cause was not a hardware problem. The system software was working properly. The shutdown was traced to a design problem: the main memory was too small, it was not sufficient when there were too many events (=trains) and switches. [the rumor mill says it was a stack overflow - would you believe dynamic data structures in a safety-critical system?! The "fix" was to be another half a meg of memory to be on the safe side...]. This critical point was reached in normal ruch hour traffic. The computer [sic, there must be more than one, however!] couldn't work any more and shut itself down. It took 2 days for the Siemens technicians in the Test Center in Braunschweig to reconstruct and analyse the situation. The computers were running again at 5am on Wednesday morning, and from 2pm everything was running smoothly again. [like I say, Friday it was broken again] Debora Weber-Wulff, Technische Fachhochschule Berlin, Luxemburger Str. 10, 13353 Berlin, Germany [You'd think the pigeons would have to watch out for the catenary hot tin roof. PGN] ------------------------------ Date: Tue, 28 Mar 1995 19:56:58 -0500 From: info@ivory.educom.edu (Edupage) Subject: Computer Crackers Sentenced (Edupage 28 Mar 1995) Two computer crackers have been sentenced to federal prison for their roles in defrauding long-distance carriers of more than $28 million. The two were part of a ring that stole credit card numbers from MCI, where one was an employee. Ivey James Lay, who worked at MCI, was sentenced to three years and two months, and his accomplice, Frank Stanton, received a one-year prison term. (St. Petersburg Times 3/28/95 E6) ------------------------------ Date: Mon, 27 Mar 1995 18:46:21 -0500 From: pcw@access.digex.com (Peter Wayner) Subject: Self-Censorship of NetPorn When the movie industry was faced with government censorship and regulation, they joined forces and adopted a voluntary rating system that classified the maturity level needed to understand a movie. Such a system could work well for the net because it could, like netiquette, spread beyond national borders. Plus it might forestall strong arm laws like the Exon bill which just passed the Senate. Here's how it could work. Every person or company that places a WWW page on the network could "rate" the contents of the page by placing it an appropriate directory. A page from my collection of pages might have a URL like: http://access.digex.net:/~pcw/over13/deepkiss.html The directory with the name "over13" indicates that the material in the page "deepkiss.html" might not be appropriate for someone under 13 years old. I imagine four major ratings like "over0" which is open to all, "over13" and "over17" which contain greater indication that two people can do more than talk to each other with their clothes on, and "over21" which is open to everything. How would this stop anyone? Kids can still type. Yes, but each WWW browser could be programmed to avoid pages with certain ratings. Parents with young children could place one of these controlled browsers on their computer and be sure that their kids couldn't read rated pages. These browsers for children could also exclude all pages without explicit ratings. This would allow parents to keep their children away from any material that was not explicitly cleared for all ages. *Would this system work? The people on the Network already show a good attitude for cooperation. Aside from few bold examples, most people carefully follow the rules of netiquette. There is hardly any reason not to cooperate-- the cost is only a few seconds of time and a few kilobytes of diskspace. *What about different cultural norms? This system offers a direct incentive to classify material conservatively. People will rate their pages because they want to be polite and sensitive to other cultures throughout the world. Not because they fear the police. They are not censored, they are just providing other people a chance to avoid potentially offensive material. *Wouldn't people lie? Sure. There are always people who break rules. But they could be punished by social pressure. A service provider might hesitate to "censor" the Web pages of its customers because it believes in free expression. But a service provider could ask its customers to rate web pages because it is the polite thing to do. *Why is this better than the Exon law? Legal measures must always be liberal because the loser goes to jail or pays a fine. This is why we require evidence and the costs of a jury trial. Social systems like this can err on the conservative side. Nudists might not understand why the rest of the world wears clothes, but they can rate their web page "over21" for little cost. Imagine the cost of prosecuting a nudist camp's web page for simply being on the Net. The Nudists who might be from a liberal region like California could decide to fight on principle. The trial would be a battle of experts trying to pin down "community standards" on a place like the Net. The Nudists would be broken financially. The local district would lose out because the court would be too jammed to prosecute normal criminals. The NetRate system saves costs and accomplishes more! Legal systems let the grey zone live. Social systems can restrict the grey zone without stopping it. If anyone has any suggestions or comments, I would like to hear them. I think this system is technically simple, politically possible and something that promotes greater understanding of people throughout the world. I am working on a rating system that would encompass the thoughts of major religions throughout the world. Please let me know if you're interested in reviewing it. ------------------------------ Date: Mon, 27 Mar 1995 16:50:59 -0400 (EDT) From: Todd W Burgess Subject: RISKS of Green PCs and Disk Caches The following happened to me a while ago when doing one of my computer assignments in Turbo Pascal for DOS. Just so you know I'm running a "Green"/Energy Star/VESA Power Management (call it what you will) 486DX2-66 that is set up to power down the hard disk after 15 minutes of inactivity. On top of that I run your standard vanilla software disk cache software. My story as is follows: I was editing my assignment and since I hadn't read or wrote to the hard disk in the last 15 minutes the CMOS instructed the hard disk to power itself down (to save power) but I could still edit my program. Anyway when I was finished my current editing session I saved my program, exited the Turbo Pascal IDE and shut off my computer. Later that day when I went to edit the same program I noticed the program I had saved earlier was not the same one I had loaded up (I had lost half an hours work). What I had found out (with a little experimentation) is this: the file that I had saved was saved in memory in the disk cache. When I exited to DOS, COMMAND.COM was in the cache's memory so the hard drive did not have power-up. When I killed the power with the hard drive off the cache never had a chance to save the file to disk. The RISK here is obvious: 1) Using a PC with DOS, power saving features and a disk cache may result in data loss! This can be particularly RISKy if you like to do your assignments the night before they are due. :) My recommendations based on my own experiences are: 1) If your hard drive powers itself down before you hit the power switch then do a "dir" or some other command that will force the hard drive to power-up. This way when the hard drive comes back on the cache will be able to write itself to disk. 2) Switch to Linux. I haven't had this problem since I switched over. :) Perhaps somebody with a little more understanding of disk caches might be better able to explain my experience. As well I've wondered if continually shutting down the hard drive decreases its life. In conclusion, this whole incident reminds me of a Kermit the Frog quote "It ain't easy being green." :) University of Guelph, Computer Science Major tburgess@uoguelph.ca URL: http://eddie.cis.uoguelph.ca/people/tburgess/tburgess.html ------------------------------ Date: Mon, 27 Mar 1995 15:51:18 -0600 From: peter@nmti.com (Peter da Silva) Subject: "thin, thin, thin computer candy shell" (Cook, RISKS-17.01) Dr. Richard I. Cook's phrase is wonderful! What proportion of the RISKS discussed in this list have been due to people depending on the computer candy shell, or being unable to diagnose a problem when the computer candy cracks? Probably at least half... and this problem isn't going to get better, especially with new operating systems that *never* drop the user down to a file or program interface and teach people to think that the pretty graphic user interface *is* the system. Larry Niven wrote a story, "The Ethics of Madness", where a busy executive went slowly insane because his desktop autodoc had failed. The warning light had burned out... how much more likely when the warning light isn't a light at all, but an icon in the corner of his PADD? ------------------------------ Date: Wed, 29 Mar 1995 09:56 -0500 From: Bob_Frankston@frankston.com Subject: Re: Risks of doing date arithmetic (Kuenning, RISKS-17.01) Huh? -- Dates as measured by computers are inherently integers? Generally computer systems do assume a certain resolution such as seconds and can identify the range of dates (or time spans) representable as integers but whey does that mean they are inherently integers more than any other measure? Naive assumptions lead to judgment rather than evaluation. In fact, Basic typically places the decimal point at the day and then the time within the day is a fraction of the day. Yes, integers are nice because one has (the illusion of) control over them but they are not inherently safer than floating point since one can easily exceed their representation on either end and very few computers systems ( especially in C) will annoy you with reporting loss of significance or overflows. ------------------------------ Date: Tue, 28 Mar 1995 12:04:49 +0100 (BST) From: Lord Wodehouse Subject: More date/time problems (VAX) Reading PGN's book, I remembered another problem on our VAX cluster related to date/time. The BT PDN X.25 network (then PSS and now called GNS) had an address which you could call and get the date/time returned accurate to about 2 seconds. The inaccuracy was due to the call setup/cleardown times and the network response. We coded an application to get this data and adjust the VAX system date/time every eight hours at 0210, 1010, 1810, which takes care of GMT/BST changes as they happen at 0205 in theory. VAXen DECNET networks have features that if times are changed packets can expire suddenly and screwup comms. Also if you run any files with expiry date/times set, you may run into trouble if the clock suddenly advances. (wait for it ...) BT's online clock (X.121 address 23421920100605) returns a string like this: TUE 28/03/95 11:32:59 HRS BST If for any reason the link to the atomic clock at Rugby is not working, the system free runs with a "high" degree of accuracy. Certain fields are changed so you can detect this (I can't remember which, because I cant find original document). One day on successive calls made one after the other, the results returned could be 30 seconds apart. This was outside the specification, but there was no sing of any loss of the radio link to the master clock displayed in the data. Suddenly all communications on the cluster "hung" and general panic occurred with all concerned with the cluster as it was in production and it was about 10am and users reading their mail. Investigations were complicated by the fact that someone did undo a connector on the ethernet, causing all sorts of addition trouble at the same time. When the dust settled, we found the whole cluster had a date/time 15 months in the future, and calling the online clock, it was discovered that this was indeed the time being returned! Mail date/time stamps were out, deferred mail got sent, file expired and were removed and batch jobs all started. It took some time to recover from this. The only explanation given by BT was that there was a problem with the service. We never discovered why we went forward 15 months in May 1988. The moral - well 1) never assume what is written down actually is what happens. 2) if you use such a system, ensure that the clock can't be set forward or backwards say more than one day in date terms and maybe 12 hours in time terms. 3) remember the first two points and act on them. Sorting out the various collisions of batch jobs, which all started at once over the cluster took some time. The summertime/wintertime change is benign in comparison. It is about time computer manufactures fitted good quality clock chips like in ones watch to keep machine clock in synchronisation and thus save all this trouble. A system that checked the clock time every hour could keep the system clock at least in step and if for any reason the change was more than say 5 seconds, flag the problem with the clock, and just use the system clock until the clock was fixed. No system clock should drift more than 5 seconds in an hour ... ------------------------------ Date: Mon, 27 Mar 1995 20:43:06 MST From: "Richard Schroeppel" Subject: RISKS of non-standard interfaces (Jones, RISKS-17.01) This is a truly amazing claim. If it is true, I would think the business case for purchasing standard equipment in a hospital would be quite strong, even if it was built only on liability reduction. Never mind the fact that 2 patients can be treated in the same window on time that one could before, or that your ROI for each unit of equipment would be higher due to the higher use. It is, indeed, a truly amazing claim. On first blush, it seems to say that hospital personnel spend an average of 40 minutes, for each patient, figuring out how to use the equipment. This is so amazing that I find it hard to believe. A more careful reading, however, reveals that what is being reduced is not the time to treat each patient, but a number called "post-admittance treatment lag". This sounds analogous to the time you spend waiting in line at the bank. It is very strongly affected by exactly how much extra capacity the system has: as the (average) load increases, sneaking up toward the capacity, the lines get very long. In this situation, minor variations in load or capacity can cause large changes in customer wait times. In the real world, systems and customers make various adjustments when faced with long lines: customers come back later, evening out the load; the system speeds up by adding resources, or reducing time-per-customer. Also in the real world, since slack is expensive, servers try to minimize it. In the long term, extra slack will cause allocated resources to drift down. The resulting wait time is a compromise between cost and customer tolerance. In the case at hand, the customers are apparently willing to tolerate an extra 40 minutes in the waiting room. Suppose the hospital managed to improve efficiency by a few percent (by switching to standard equipment, or perhaps by training the personnel better), and the waiting time fell from 70 to 30 minutes. There would be more slack periods, with idle people and idle machines; the system response would be to reduce resources until the expected balance between slack and customer tolerance was restored, probably at an average 70 minute wait. The notion that the time-per-patient can be reduced 50% ("2 patients can be treated in the same window on time that one could before") seems mistaken -- it might apply to defibrillators (largely idle anyway?), but is unlikely to apply to the patient's bed, IV equipment, or staff time. A customer in the waiting room is using only a chair, undoubtedly the cheapest piece of equipment the hospital has. Rich Schroeppel rcs@cs.arizona.edu ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.02 ************************ 4-Apr-95 16:42:41-GMT,31233;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id MAA10933 for ; Tue, 4 Apr 1995 12:42:40 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id MAA07247 for ; Tue, 4 Apr 1995 12:42:38 -0400 Received: from chiron.csl.sri.com ([192.12.33.73]) by RUTGERS.EDU (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.11) with SMTP id MAA25689 for ; Tue, 4 Apr 1995 12:40:57 -0400 Received: by chiron.csl.sri.com id AA15193 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Tue, 4 Apr 1995 09:30:55 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 4 Apr 95 9:30:53 PDT Subject: RISKS DIGEST 17.03 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 4 April 1995 Volume 17 : Issue 03 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Chunnel has ghost trains (Lord Wodehouse) Overzealous clock correction? (Robert Rhode) Israelis cough at the name of "Kaf" (Edward P Ravin) A Tale of Two Organs... (Matthew D. Healy) Mysteries of the Mind psychological SW advertisement (Rodney D. Van Meter) Police cop it from computer (Jon Hunt) Japanese transcription (was Re: Patent searchers) (Rodney D. Van Meter) OSHA Ergonomics draft (Jim Horning) Software safety, new handbook, standards (Archibald McKinlay via Jim Horning) Andersen Law Suit Report (Bernard Robertson-Dunn via Jim Horning) Complexity (was RISKS of non-standard interfaces) (Bob English) Re: More on German Train Problems (Branam) Is there a RISK in misremembering SF novels? (Peter da Silva) Re: Self-Censorship of NetPorn (Jerry Leichter) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sun, 2 Apr 1995 16:25:15 +0100 (BST) From: Lord Wodehouse Subject: Chunnel has ghost trains It was probably to be expected, but the Chunnel trains are in trouble because of sea water. In today's Sunday Times (3rd April 1995), John Harlow writes that because of unexpectedly (really?!) high levels of sea water, rogue signals are sent to the drivers and controllers of trains. The drivers get 3 red flashing lights and have to do an emergency stop and wait until controllers have checked the position of all trains in the tunnel, radio back and reset the signals, which takes up to about 20 minutes. A driver for Le Shuttle said there were about 5 emergency stops a week. They are running about 100 trains a day, so this is not many, but there should be no ghost trains at all. Safety inspectors are worried. On March 17th a train had to stop so quickly, glasses fell off tables, and another time a lorry moved forward into another vehicle (the trains carry cars and lorries). The action of the train at 100mph going through the tunnel raises a mist of salt water behind it and this short circuits a low-voltage connection between the rails, which mimics a train. It appears that engineers have underestimated the effect of sea water, an excellent conductor of electricity, on trackside electronic equipment. It is also my belief that they also may have underestimated the corrosive effects of salt water. This will have the opposite effect and thus cause other problems. We wait, for the next ``advanced technology meets old-fashioned, well-known problem and fails again.'' Lord John - The Programming Peer w0400@ggr.co.uk +44 181 966 2109 ------------------------------ Date: Sat, 1 Apr 1995 17:32:47 -0500 (EST) From: Robert Rhode Subject: Overzealous clock correction? I run an extension on my Mac that compensates for the error in the computer's realtime clock by occasionally calling up the Naval Observatory and checking the difference. It also has the option of automatically adjusting the clock by an hour for Daylight Savings Time. Apparently, so does the new System 7.5. Anyone want to guess when I'll arrive at work on Monday? - Bob ------------------------------ Date: Wed, 29 Mar 1995 21:49:02 EST From: HFDG63A@prodigy.com (EDWARD P RAVIN) Subject: Israelis cough at the name of "Kaf" Israeli military censorship forbids the local press from publishing the name of the person who heads the internal security police (known as Shin Bet or "Shabak"). He can only be referred to as "Kaf" (a letter of the Hebrew alphabet). But the Jerusalem Report of 6 April 1995 says that the chief's name and address were published in a mid-March message on the Internet (presumably a Usenet post) "circulated freely to millions of net-users all over the world." The message, probably circulated by opponents of the man newly appointed to the post, invited "Internet readers to send 'letters of congratulation' to the new head man" and gave his correct name and address. The article went on to note the "anachronism of trying to keep the secret-service chief's name under wraps in an era when the flow of information can no longer be controlled." Opponents of "Kaf" have also "daubed his name in bold letters on the censor's office in Jerusalem." [A Feted Kaf or a Fated Kaf? PGN] On the same page, another story mentions 104 year old Yosef Tzadok, who has 24 grandchildren and 36 great-grandchildren, but also just got a notice to register at a Jerusalem kindergarten because his birthday was recorded in a computer somewhere as "December '90"... [Not the first, but yet another premonition of things to come. PGN] ------------------------------ Date: Sun, 2 Apr 95 14:17:07 PST From: jonhunt@olympus.equinox.gen.nz Subject: Police cop it from computer [This incident is amusing and bizarre, but I doubt that it is very uncommon.] Police cop it from computer (Eugene Bingham, NZ Herald, Thursday 30 March 1995) A police information-gathering exercise turned into a matchmaking fiasco as a computer system went haywire. Printouts sent to staff this week as part of the police department census have recorded as fact a large number of nonsensical living arrangements. If the census forms are to be believed: - A policewoman stationed at an Auckland City base is married to the wife of another policeman. - Another female colleague is married to four officers. - Eight officers at a West Auckland station have the same mother. "It is obviously a real big screw-up," a police source said yesterday. "Everyone thinks it is hilarious." The problems arose when staff began opening the census forms and read a page of personal information supposedly held on police records. It is understood hundreds of errors are contained in the section recording next-of-kin details. Embarrassed police officials said yesterday that a computer glitch had led to the mistakes. Superintendent Jon White, in charge of human resources planning, said the computer became confused when no information appeared in a staff member's next-of-kin file. "It picked up other records and inserted them in their place." Mr White said the mistake was "most unfortunate and regrettable." "Fortunately, most of the staff see the amusing side." Those affected by the glitch have simply been told to cross out the wrong information and send the corrected form back. Mr White said the problem highlighted the fact that many officers had let their personal information file become out of date. It was important to keep the next-of-kin information up to date. The census, covering sworn and non-sworn staff, aims to establish a databank of information about the police department. jonhunt@olympus.equinox.gen.nz Christchurch, New Zealand ------------------------------ Date: Wed, 29 Mar 1995 18:17:25 -0800 From: rdv@alumni.caltech.edu (Rodney D. Van Meter) Subject: Mysteries of the Mind psychological SW advertisement I received in the mail yesterday an advertisement for a CD ROM called "Mysteries of the Mind". It includes several (apparently) Eliza-like programs that provide you with psychological counseling. While it is referred to as edutainment software, the advertising makes some extraordinary claims. For example: Exiting [sic] new technology gives you...advantage in...relationships and even sex! No More: * Hopelessness in your life ... * Horrible sensation of Stress and Depression" Thoughts of liability when somebody kills themself after an unproductive session with MotM cross my mind. It refers later to the "loving, personal guidance of World's best psychological software". Now we get into the issues of falling in love with your computer (or robot) that is a popular topic in science fiction. It may be entertaining to use, and perhaps be relaxing, both of which are good, but the thought of people with real problems relying on this rather than seeking professional human help ought to cause the authors to lose sleep at night. Still, is it any worse than the multimillion-dollar self-help book business? Does this potentially represent a fundamentally different problem, or is it only a matter of degree? Perhaps it is even a good thing (self-help books arguably are), but it's certainly not without a downside. --Rod ------------------------------ Date: Mon, 03 Apr 1995 12:19:43 -0500 From: healy@seviche.med.yale.edu (Matthew D. Healy) Subject: A Tale of Two Organs... {The New York Times}, 3 Apr 1995, has an interesting article about two organ restorations in Paris. In late 1992, a much-ballyhooed renovation of the organ at Notre-Dame in Paris was declared complete, to much publicity. About a year earlier, to much less fanfare another Paris organ (at St Sulphice and nearly as large) had been put into service after it was renovated. The St Sulphice restoration was done in a very traditional manner; the president of the firm doing the job told the {Times} that if there was any difference in sound (except for fixing actual problems) after his work, then he'd failed. He saw his company's job as nothing more or less than making the organ work precisely as it had the day it was built. The only electrical part in the restored organ is the air pump. And everyone agrees that the company did a most competent job, exactly as planned. Notre Dame is a very different story. They installed a new high-tech computer system that allows unheard-of flexibility: Literally any combination of pipes can be programmed to operate with any key -- total freedom of registration, so a "stop" is just a subroutine A performance can be recorded, then played back with microsecond accuracy at any later time etc., etc. -- lots of bells and whistles (so to speak :-) And it has been a disaster! Only after months of debugging has it reached the point of being able to get through a Sunday service without glitches. Now there's talk of replacing the computer with a more conventional electronic control system -- one that does nothing more or less than did the old relays that had been used before the renovation. The pipes and valves are all working perfectly, so once they sort out the control system, they'll be in good shape. The basic problem was a classic indeed: going directly to full-scale implementation of new and untested technology without first building a prototype! This should be familiar to all regular RISKS readers. Matthew.Healy@yale.edu Postdoc, Genetics & Medical Informatics http://paella.med.yale.edu/~healy/matt_healy.html ------------------------------ Date: Wed, 29 Mar 1995 17:56:35 -0800 From: rdv@alumni.caltech.edu (Rodney D. Van Meter) Subject: Japanese transcription (was Re: Patent searchers) In risks 17.01, John Gray wrote, quoting from New Scientist: entries in the EPO's international Inpadoc database for patent applicants called Robaato Uiraaton Furemingu, Uiriamu Bii Reisufuiirudo, Bii Oo Shii Guruupu and Kuringe Fuarama... Japanese tapes contain names which have been translated from Western originals into pictorial characters and back again by computer. First, to correct a point: Japanese writing consists of three complementary character sets: the kanji borrowed from Chinese, hiragana, and katakana. Only the first is pictogram-derived, the other two are phonetic. Foreign loan words are always written using katakana. Thus, the statement above misrepresents the source of the problem. In addition, the "corrected" name Laceford, from looking at the above, seems more likely to have been Lacefield (because of the double-i). In Japanese (both written and spoken) there are a number of limitations that make it impossible to render every English word or name correctly (or even unambiguously): for example, 'th', 'w', and 'v' are essentially impossible to represent; the sound 'shi' is made to work for the English equivalents of 'si', 'shi' and 'thi'; 'v' and 'b', sometimes 'j' and 'z', and of course the infamous 'r' and 'l' cannot be distinguished. This leads to an entire field of (sometimes amusing) problems well known among language students. One of my favorites from even before they filed Chapter 11 is that Thinking Machines rendered in katakana becomes (roughly) "shinkingu mashiinzu" -- which can then be reread in English as either "Thinking Machines" or "Sinking Machines". Because of the ambiguities introduced, even if heuristics were developed for translating Japanese katakana words back into English (or other languages), they could never be 100% perfect. Seeing the katakana for the above Laceford(field?), it could be reread as Raceford or perhaps even Raysford. Even in relatively unambiguous cases, English variations in spelling (Jon or John?) and homonyms (bite or byte?) are troublesome without using context, where "context" may have to include _a priori_ knowledge of the correct spelling of individuals' names. The problem is not one-way; seeing Japanese or Chinese words rendered in the Roman alphabet often leaves their corresponding Chinese characters ambiguous, and without the help of diacritics Chinese pronunciation cannot be fully represented in the Roman alphabet. The problem extends to further levels that are related to the overall difficulties of searching and indexing free text as well as the difficulties of translation; I have seen the name of the religious sect likely to be charged with last week's Tokyo (toukyou, if you transliterate the Japanese pronunciation) subway attack written in English newspapers as variously Oom Shinri Kyo (roughly the Japanese pronunciation), Aum Shinri Kyo and Aum Supreme Truth. And of course for Chinese there are several methods of romanizing names; is a search engine supposed to equate Qing and Ching? And how many automated indexing systems will correctly work with, for example, the name !Kung? It goes up another ugly level when you begin to discuss translating articles originally written in Japanese about Chinese persons, places or historical events; the Japanese use the Chinese characters but their own pronunciation, while we use (roughly) the Chinese pronunciation but know nothing about the characters. None of this is news to language students or developers or users of machine translation systems, and these fundamental problems are likely unsolvable, despite the progress of machine translation systems. But with the huge volumes of material to be translated, how can we do any better than living with what the best machine translators produce? For that matter, accurate human translation often requires the active participation of the original author. The risks, besides the above problems of search and index? How about international banking and medical records never getting correctly reconciled, or worse, getting improperly reconciled? Are we going to have to go above the U.S. Social Security Number to an internationally valid identifier? Talk about Orwellian consequences... --Rod ------------------------------ Date: Wed, 29 Mar 95 17:52:53 -0800 From: horning@pa.dec.com Subject: OSHA Ergonomics draft [Anyone concerned with RSI and the like might be interested in this, available via the University of Utah starting at URL http://tucker.mech.utah.edu/ and probably various other places. Jim H.] Note from OSHA These draft pre-proposal materials are intended to facilitate informed discussion as the Occupational Safety and Health Administration (OSHA) develops an Ergonomic Protection Standard. These materials are not being promulgated as a rule or standard. They do not constitute either a Notice of Proposed Rulemaking or a source of official OSHA guidance on ergonomics. Until such time that a final Ergonomic Protection Standard is adopted, OSHA will continue to rely on Section 5(a)(1) of the Occupational Safety and Health Act (the "General Duty Clause") for enforcement authority. Failure to adhere to any draft requirement or guideline in these materials is not a violation of the General Duty Clause; use of these materials to assist in ergonomic protection may indicate that workplace hazards are receiving adequate attention. ------------------------------ Date: Wed, 29 Mar 95 17:58:52 -0800 From: horning@pa.dec.com Subject: Software safety, new handbook, standards [Fwd from sci.engr.safety] >From: arch6@neosoft.com (Archibald McKinlay) Subject: Software safety, new handbook, standards Date: Tue, 28 Mar 1995 12:47:28 -0600 Software Safety Engineering New software safety handbook: sponsored by the US military services, pending NASA, FAA and Coast Guard joining. Book is structured to be compatible with process oriented software development (ISO 12207, DOD-STD-498, IEEE 1498/EIA IS-640) in similarly oriented system engineering life cycle (EIA 632, IEEE 120) and usable for inspections and reviews (IEEE 1028, ISO 9000-3 and/or TickIT). Any acquisition, development and fielding life cycle, including re-use, can be configured/tailored from the "building block" approach. A list of "best practices" is envisioned as an appendix. Possible CD ROM version under investigation. A display will be given at the System Safety Society meeting in July in San Jose, CA, and at the American Society of Safety Engineers Technology 2000 in Orlando, FL, in June. A similar tutorial is hoped for at COMPASS in Gaitherberg, MD, in late June 95. An industry review period is expected beginning in Sept 1995. IEC 1508 "Functional Safety: Safety related systems". Work began and otherwise known as IEC/SC65A working groups 9 & 10 now re-named IEC 1508. Standard will be released for review in mid 1995 in seven parts. Part 1 is general requirements, part 2 requirements for electrical/electronic/ programmable electronic systems, part 3 software requirements, part 4 definitions, part 5 guidelines on application of part 1, part 6 guidelines on application of parts 2 and 3, part 7 bibliography of techniques. This standard will apply to industrial and consumer goods. Extension standards for specific industries is encouraged, hence a medical device and software (databases?) standard has already been formed. Robotics, fire detection and suppression, elevators, off shore rigs, automobile and aircraft parts are expected to be effected. UL 1998 (Underwriter's Laboratory) Standard for Safety-related Software "Standard is to be used in conjunction with current methods used to investigate hardware. The standard covers both software that directly controls safety-related functions and software that has the potential to pose a risk of injury to persons or loss of property. (quoted from UL cover letter)". This standard is appended to end product standards, which include: solid state controls for appliances, primary safety controls for gas and oil fired appliances, molded case circuit breakers and enclosures, industrial control equipment, temperature indicating and regulating equipment, burglar alarm communicator systems, and information technology equipment. System Safety Society and commercial STD-882 The System Safety Society is working with a standards group to make available a commercial version of MIL-STD-882. This standard is in work and a rough draft has been produced for the committee use. There is currently no commercial equivalent that covers all aspects of a system safety program. This will be usable for safety V&V and audits. Software safety should be included. ------------------------------ Date: Wed, 29 Mar 95 18:46:19 -0800 From: horning@pa.dec.com Subject: Andersen Law Suit Report [Fwd from comp.software-eng] >From: Bernard Robertson-Dunn Subject: Andersen Law Suite Report Date: 27 Mar 1995 09:33:02 GMT The following report appeared today (Monday 27 March 1995) in the Australian Financial Review. Andersen Charged Andersen Consulting is charged with fraud, incompetence and neglect in a $US100 million lawsuit filed by UOP, a US-based engineering company. In its lawsuit, which also seeks unspecified punitive damages, UOP said Andersen Consulting bungled the development of computer systems it needed to help manage its business. The company's complaint alleges that after winning the contract, Andersen Consulting's "ineptitude and deception" caused late deliveries, "bilked millions" of dollars from UOP and wound up supplying a computer system that was largely unusable. Bloomberg [Anyone know any more? brd] ------------------------------ Date: 28 Mar 1995 19:50:26 GMT From: renglish@ratliff.engr.sgi.com (Bob English) Subject: Complexity (was RISKS of non-standard interfaces, Cook, RISKS-17.01) : ... much of the problem we have with medical devices is the result of : designers attempting to produce a device surface that _appears_ simple : but actually hides a wealth of complexity... The same comment applies to most of the "computer-" and "software-" related risks discussed in this forum. Computer and software risks are not fundamentally different from other types of risks. In all cases, the root cause of unexpected behavior lies in the complexity of the total system, not in the nature of its components. And when we build systems to perform complex functions, the systems we build are necessarily complex. There are, of course, reasons to build complex systems. Consider the often attacked practice of using software in safety-critical systems, like airplanes. Aircraft companies compete with one another to build the most efficient planes, and as in so many cases, squeezing the last bit of efficiency out of a plane introduces a great deal of complexity into the design. In order to realize the gains, manufacturers have to find ways to allow the planes to be flown with a minimum amount of crew, so they turn to computers to help them manage the complexity, a step that increases (rather than decreases) the complexity of the plane. The fact that something is complex and sometimes behaves unexpectedly does not mean that it's overall performance is not more beneficial than a less complex alternative. A more complex, more efficient plane, for example, may reduce the cost of air travel, allowing more people to choose air travel over other, riskier modes of transportation (it could be argued, for example, that air travel is currently too safe, because the close attention to safety raises the cost of short-haul flights and encourages people to drive instead). An infuser interface that hides complexity from the user may allow infusers to be used beneficially in more circumstances than they otherwise would, and those benefits may outweigh the costs of the cases where the infuser causes harm. With sufficiently complex systems and sufficiently large stakes, however, it is very difficult to make reasonable judgements about the tradeoffs, and even if we make good judgements, we are unlikely to be comfortable depending on systems whose behavior we will never fully understand. --bob-- ------------------------------ Date: 3 Apr 1995 16:50:59 GMT From: branam@netcad.enet.dec.com Subject: Re: More on German Train Problems (Weber-Wulff, RISKS-17.02) In RISKS-17.02, Debora Weber-Wulff indicates surprise at the use of a stack and "dynamic data structures in a safety-critical system", the Deutsche Bahn's new train control system. While my experience with real-time development is limited, and I have no experience whatsoever in safety-critical systems, I would not fault them for using a stack-based architecture. Dynamic data structures, whether stack or heap, are a reasonable means for managing limited memory resources, provided there is a means for storing critical data in permanent, recoverable structures in an atomic fashion. Where I would fault them is for not being aware of the behavior and capacity requirements of their system under load and overload conditions. Were they unaware of the depth of their deepest routine call tree? Or, since this was apparently related to the number of trains being managed, was it a recursive algorithm run amok? A little more modeling and testing by a few paranoid personalities would be in order (my belief is that every project should have a "token pessimist" to combat the general Barney-like optimism that pervades most development work). Further, I would expect a railroad to have done significant capacity planning (how many trains on the tracks at different hours, etc.), which would be used as input into the design and test phases. It's not like they haven't seen rush hour and holiday loads before. Running out of memory is a common risk in dynamic memory management. The naive programmer will simply assume that all allocations are successful (or that the system will deal with allocation failures in a benign and acceptable manner), and is generally unaware of this latent bug because he fails to test the system under sufficient load. The defensive programmer will assume that all allocations will fail, and structure the software to handle such a case. This is a critical decision that can totally alter the design of a program; it is not easy to retrofit defensive code into software that was not built with a defensive frame of mind. ------------------------------ Date: 3 Apr 1995 11:03:22 -0500 From: peter@Starbase.NeoSoft.COM (Peter da Silva) Subject: Is there a RISK in misremembering SF novels? The Stars My Destination is an excellent book, and the descriptions of the methods people used to prevent folks jaunting into their houses are analogous to the current use of firewalls, but I don't recall this particular RISK being brought up in that book. So far as my own poor memory recalls, the "Flash Crowd" idea is Niven's. It was first brought up in the short stories "Flash Crowd", "All the Bridges Rusting" and "The Last Days of the Permanent Floating Riot Club". Many of Niven's other transfer booths stories like "A Kind of Murder" are equally appropriate to the Internet. [Martin Poole also noted TLDotPFRC. PGN] ------------------------------ Date: Sun, 2 Apr 95 12:02:11 EDT From: Jerry Leichter Subject: re: Self-Censorship of NetPorn Peter Wayner suggests that providers of Web pages (and presumably other on- line resources) follow in the footsteps of the movie industry and rate their own materials, so that viewers could be written to limit access by children. It's a nice idea, but Mr. Wayner fails to understand how the movie rating system works. First of all, ratings are not, as in Wayner's suggestion, provide by the producers of movies. Rather, there is a central organization, composed mainly of non-industry people, who set the standards, preview each movie, and provide a rating. The rating is subject to negotiation, and producers can make suggested modifications to get a different rating if they like. The rating system has been the subject of significant debate between producers and the rating board. In particular, the "X" rating, originally meant to describe movies with "adult" themes - "Urban Cowboy" and "Blow Up" are probably significant early examples of mainstream X-rated movies - soon came to apply only to pornographic material, and in fact fell into complete disuse, except for self-ratings by those who made frankly pornographic material. The ratings board added a trademarked "NC-17" rating a few years back to have some way to rate non-pornographic but adult material, but it hasn't seen much use. The second error is that the movie rating system is in meaningful sense "voluntary". The vast majority of movie theatres in the US, other than those specializing in pornographic material, will not show non-rated material. The reason the X rating fell into disuse was that they wouldn't show X-rated material either. NC-17 is in trouble because it is avoided by some of the larger chains, too. More recently, the largest video stores refuse to rent non-rated or X-rated (or perhaps NC-17-rated) material. So ... the rating system is "voluntary", so long as you don't mind being shut out of the market. As a result, I see little similarity between what Mr. Wayner proposes and the movie rating system as it actually exists, and little reason to use the success of one, such as it is, as evidence for the workability of the other. More generally, I see little reason to believe that "netiquette" will be sufficient to restrain anyone interested in providing material to the net - as it has had little effect on flaming, inappropriate commercial postings, or many other net problems. -- Jerry ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.03 ************************ 6-Apr-95 22:00:13-GMT,30731;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA08005 for ; Thu, 6 Apr 1995 17:59:46 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA04126 for ; Thu, 6 Apr 1995 17:59:23 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.11) with SMTP id RAA10264 for ; Thu, 6 Apr 1995 17:59:03 -0400 Received: by chiron.csl.sri.com id AA16890 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Thu, 6 Apr 1995 14:48:47 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 6 Apr 95 14:48:45 PDT Subject: RISKS DIGEST 17.04 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 6 April 1995 Volume 17 : Issue 04 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Thoughts on SATAN, Michelangelo and Crack (Tom Perrine) A possible "solution" to Internet SATAN: Handcuffs () Make a Call, Turn Off the Power (Mike Winkelman) Boeing 777 has dainty feet (Nathan Myers) Risks of HCI designed by non-typist (Pete Mellor) Endless loops in Voice Mail (Dick Mills) Computer will control Nick Ingram's execution (Mike Wilson) "Airport Vending Machine Sells Computer Programs" (Barry Jaspan) Computer Security's an Oxymoron (Edupage) Re: Complexity (Stephen L Nicoud) RISK of webpage rating system (Joan Combs Durso) Chunnel as a Theme Park (Re: Ghost trains) (A. Padgett Peterson) Insecurity over ATM security (Jon Green) Safeware: System Safety and Computers (Nancy Leveson) InfoWarCon '95, First Call for Papers (Winn Schwartau) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 4 Apr 95 21:40:39 PDT From: Tom Perrine Subject: Thoughts on SATAN, Michelangelo and Crack Well, here it is, only 10 hours until the Internet As We Know It will grind to a halt. Of course, the Imminent Demise of the 'Net has been predicted before. In fact, this will be at least the fifth time that I have personally witnessed such mass hysteria and overzealous concern over the "safety and integrity" of the Internet. There has been so much hype over the release of SATAN, including articles in the New York Times, fer cryin' out loud, that entirely too many people have no idea what is going on, but They Are Sure That Truly The Sky Will Fall. It is very strange, and somehow wonderful, that our society finally has enough people with some knowledge of the Internet, that they could even care about the integrity of the Internet. It is also, however, sad that they do not understand that thing which they use every day, and have come to depend on so much. What is the truth behind the hype? Will SATAN be the ultimate "cracking" tool? Is it the network equivalent of an unstoppable skeleton key? Of course not. SATAN is nothing more than a software implementation of a checklist of well-known flaws in the design and/or implementation of the UNIX operating system and its network servers, and Internet protocols. There is nothing in SATAN that hasn't been seen in at least a dozen intrusion attempts in the last year. The holes examined by SATAN have been known to the cracker community for years in most cases. Does this mean that the release of SATAN is unimportant? That all the hype and publicity has been a mistake? That there is no reason to worry? Again, of course not. After the Michelangelo virus media "event" of a few years ago, the computer world breathed a huge sigh of relief. The predictions were that between 15 and 50% of the world's personal computers would be destroyed by Michelangelo. This obviously didn't happen. True, most estimates of infection rates were obviously out of line. But a significant number of companies and individual users reported that due to the media blitz, they now took virus protection seriously, and almost everyone admitted that they scanned their systems for virii in the weeks before Michelangelo was due. SATAN will be important for the same reason that Michelangelo and Crack have been important: they have raised the issue of computer security in a way that cannot be ignored, and they have given harried system and network administrators some of the same tools already in use by cracker. Sites that used to be able to ignore the risks of connecting to the Internet, who believed that they were immune, too low-profile, of just didn't understand now know that they *must* take steps to protect themselves. With the certain knowledge that SATAN (and other tools) are out there, being susceptible to well-known attacks clearly shows a lack of "due diligence", which a term which courts and juries seem to understand. Now that SATAN is out, any commercial site that is cracked may find itself involved in legal action from its users and customers. There is considerable belief (one might also suggest consensus) that the availability of Crack has forced sites to use non-dictionary passwords. Since Crack became available, the "cracking" of passwords from stolen password file has almost completely disappeared from the Internet. SATAN will level the playing field, as now system administrators who things to do other than write custom cracking packages will have the same tools as the "black hats". I hope that the release of SATAN will encourage vendors to increase the security of their shipped products, and raise the level of security awareness throughout the Internet. Just by existing, it will, after a time, improve the integrity of the 'Net as we now know it. But for the next few weeks, "let's be careful out there." Tom E. Perrine (tep@SDSC.EDU), San Diego Supercomputer Center +1.619.534.510 http://sdsc.sdsc.edu/SDSC/Staff/tep FAX: +1.619.534.5152 ------------------------------ Date: Wed, 05 Apr 95 10:00 xxT From: [address withheld by request] Subject: A possible "solution" to Internet SATAN: Handcuffs The authors of the recently released SATAN package for probing Internet sites have shown a level of amorality that should gladden the hearts of the National Rifle Association and arms merchants around the world. By close analogy, SATAN's parents' attitude appears to be that it's perfectly OK, perhaps even admirable, to go from house to house without permission trying each door and window to see if it's unlocked, or perhaps not locked securely enough. If caught inside, the intruder would of course claim he or she was just performing a "security check", and gee whiz, that homeowner REALLY should buy a better lock! Bull****. That sort of argument wouldn't wash with unauthorized residential probing/entries/burglaries, and it shouldn't be acceptable for such unauthorized activities when directed against computer systems either. Up to now, most system administrators have tended to take a fairly permissive attitude towards hacking probes/attacks--at least the first time. Usually the farthest they go is to warn the offending users and/or system administrators at the site originating the attack, and let it go at that. The time has come for this attitude to change. It's time for it to be made clear in no uncertain terms that any unauthorized probing cases will be immediately turned over to law enforcement for appropriate criminal and/or civil actions whenever possible. A variety of laws would appear to make it illegal to use SATAN or similar tools against a site without that site's permission. Most likely there are a number of cyber-lawyers who could do quite well specializing in this area. Where attacking users can be identified, enforcement can be directed towards them. Where sites are unable or unwilling to cooperate in identifying the user, then action may have to be taken against sites where attacks originated as well. It is perhaps unfortunate that this sort of "no more excuses" policy will probably net a large number of rather ignorant users who run tools like SATAN "for fun" while oblivious to the logging, tracking, tracing, and other countermeasures that exist against it. But that's the price they'll have to pay for playing with powerful tools left laying around by amoral software engineers. Playtime is over, kiddies. [Don't forget, SATAN runs as root -- although that is not necessarily an obstacle for many folks, and some of it can be hacked to run unprivileged. But breaking root in the first place falls into the "unauthorized" category. PGN] ------------------------------ Date: Wed, 5 Apr 1995 16:56:47 -0400 From: mlwinkelman@dow.com (Mike Winkelman) Subject: Make a Call, Turn Off the Power I suppose I shouldn't be surprised, but the power went out for 17,000 here in our small town (38,000) last week. The local newspaper first reported that the power company didn't know why it went out, but that it "may be related to someone digging in their back yard". A week later they fixed the blame. A phone call (by the power company), supposedly to one substation, (completely automated judging by the tone of the article) went instead to a different substation (for unexplained reasons) and shut that substation down. It was down for 1.5 hours. The risks?? Just think of a few well placed calls by non-power company people to major metropolitan areas in the dead of night if they have similar systems. ------------------------------ Date: Tue, 4 Apr 1995 23:38:16 -0700 From: ncm@netcom.com (Nathan Myers) Subject: Boeing 777 has dainty feet I have heard recently that the new Boeing 777 jetliner, described in recent news reports as "skating through the approval process", has a little problem that might be interesting to RISKS readers. It seems that an important part of the landing gear is too weak, and will get "used up" (through metal fatigue), and need to be replaced annually. While this is probably not a safety problem, it's an extra expense (frequent inspections and replacements) and an embarrassment. Unfortunately, fixing it isn't just a matter of making the part stronger; it would then be bigger and heavier, affecting fit, balance, and nearby parts. This sort of problem is familiar in the "shakeout period" of all previous jetliners, but it's surprising that it showed up so late in the approval process. (A previous 7?7 has a nonlinearity in the landing gear linkage that caused an oscillation when trying to close the doors; it was fixed by an appalling hydraulic "patch" that cancels feedback during the nonlinear portion of the cycle.) How did this mistake get all the way through Boeing's legendary engineering process? The 777 is the first commercial Boeing to have been modeled entirely on computer before construction. Apparently the part is precisely a factor of two weaker than it should have been. Does this smell like a structural model entry error? I have been unable to find out more about the source of the error, and would welcome more detailed information. Maybe the RISK is in streamlining your engineering process so well, and eliminating so many of the more common mistakes that would have caused delays, that you are already getting final FAA approval before the booboos that only time can reveal are noticed. Or maybe the RISK is just that better communications can leak word of embarrassments few would have known about otherwise. ------------------------------ Date: Tue, 28 Mar 95 15:45:14 BST From: Pete Mellor Subject: Risks of HCI designed by non-typist The Management and Administrative Computing Initiative (MACI) is an attempt to get all universities in the UK to use the same computer package for their administrative operations. (In fact, it has been found necessary to define four "families" of universities with similar approaches, and design a package for each family.) The requirements specification, design and gradual implementation of the MAC packages is proceeding. The following anecdote might amuse readers of RISKS who take an interest in Human Computer Interface design. The part of the MAC package which deals with job applications in a certain university (which shall remain nameless) has had an interesting little "feature" incorporated into its HCI by one of the implementors (who has since moved on to pastures new). To save the effort of the typists in keying data into a name or address field, he arranged that letters could be typed in upper or lower case anywhere, and on input the case would be changed so that initials and the first letter of each word would be capitalised, and the remainder put into lower case. To a two-fingered typist like him, this probably seemed like a great labour-saving idea. For a trained touch typist (such as my informant) it saves nothing, of course. Not only that, but responses to applications are now being sent to "Dr. B. O'malley, University Of Newcastle-Upon-Tyne". Lessons for HCI design would seem to be:- 1. Write a specification. 2. Get someone else to read it before implementation. 3. Better still, get the feedback from the use of a prototype. 4. If you want to know the user's requirements, ask the user! The costs of getting a different person to remove the feature, and of cleaning up the database, are still being counted! Peter Mellor, Centre For Software Reliability, City University, Northampton Square, London Ec1v 0hb +44 (171) 477-8422, Fax.: +44 (171) 477-8585, ------------------------------ Date: Tue, 04 Apr 1995 11:53:17 -0400 From: rj.mills@pti-us.com (Dick Mills) Subject: Endless loops in Voice Mail I just called someone at "XX" Software Inc. He told me he would be at extension 126. Here's an abbreviated transcript of what I heard. IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [126] SORRY, THERE IS NO EXTENSION 126. IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [wait] IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [Hmmm. It is in a loop. What if I dial '0'?] HI THIS IS ANN. I'M NOT IN THE OFFICE TODAY. PLEASE LEAVE A MESSAGE AT THE SOUND OF THE BEEP. BEEP. [Hmm. Didn't work. Hang up and dial again.] IF YOU KNOW THE NUMBER OF THE PERSON YOU'RE CALLING, PLEASE DIAL IT NOW. OTHERWISE WAIT ON THE LINE AND AN OPERATOR WILL ASSIST YOU. [wait] ONE MOMENT PLEASE, YOUR CALL IS BEING TRANSFERRED TO AN OPERATOR. HI THIS IS ANN. I'M NOT IN THE OFFICE TODAY. PLEASE LEAVE A MESSAGE AT THE SOUND OF THE BEEP. BEEP. [Sigh, hang up] So what's the risk? We have been conditioned to think of telephones as non-programmable devices. So when we purchase a new phone system which is programmable, we may neglect applying the same quality assurance to phone programming as we [hopefully] do to normal software. A good way to avoid the trap is to inventory your belongings. Which things do you own that are actually dumb, purportedly dumb, or traditionally intelligent? Presumably you know how to deal with the first and last. Now think carefully about the middle ones. Are you treating them with proper lack of trust? ------------------------------ Date: Thu, 6 Apr 1995 11:25:07 +0100 (BST) From: "Mike Wilson, ICL Medical Portfolio" Subject: Computer will control Nick Ingram's execution >From "Today" newspaper, London, England, 6 April 1995: Nick Ingram's execution will be controlled by a computer. It is the first of its kind and follows a series of electric chair bungles where condemned men survived a manually controlled surge. Three executioners will each push a button to activate the computer but only one is "live", leaving none of the trio knowing if he started the deadly process. The computer will then take 30 seconds checking every connection to Ingram's head, legs and arms and, if there are no problems, will send 2,000 volts slamming into his body for four seconds. It then switches the current to 1,000 volts for seven seconds and 208 volts for two minutes. Throughout the execution, the computer's systems monitor the current, making sure there is no drop in power. Five minutes from when the current is stopped, a doctor will pronounce the Briton dead. The risks are horrifying. Mike Wilson mrw@oasis.icl.co.uk ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1 3PX, UK [Sure gives a new meaning to volt-tolerant systems. PGN] ------------------------------ Date: Tue, 4 Apr 1995 17:13:11 -0400 From: "Barry Jaspan" Subject: "Airport Vending Machine Sells Computer Programs" (AP) An recent AP article describes a prototype vending machine installed at the Raleigh-Durham International Airport. The machine sells shareware. A customer inserts a floppy disk, selects a program, inserts money, and out pops the disk with the software installed. I suppose that the RISKS are really no different than when retrieving software over the network, and practically is not as big a problem since far fewer people will use it. Somehow, though, the thought of a row of machines at which I can buy Camels, Coke, Snickers, and Tetris makes me shiver. Barry Jaspan ------------------------------ Date: Tue, 4 Apr 1995 23:47:21 -0400 From: info@ivory.educom.edu (Edupage) Subject: Computer Security's an Oxymoron (Edupage 4 April 1995) Computer break-ins are still on the rise, often accompanied by significant financial losses. The Computer Emergency Response Team's manager says the number of reported violations was 130 in 1990, 800 in 1992, 1,300 in 1993 and 2,300 in 1994. A 1994 survey by Ernst and Young of more than a thousand companies showed 20% reporting financial losses as a result of computer break-ins. An earlier study by USA Research cited losses of $164 million in 1991 due to unauthorized intrusions. (Technology Review, April 1995, p.33) ------------------------------ Date: Thu, 6 Apr 95 10:38:09 PDT From: Stephen L Nicoud Subject: Re: Complexity (English, RISKS-17.03) (it could be argued, for example, that air travel is currently too safe, because the close attention to safety raises the cost of short-haul flights and encourages people to drive instead) Citing Paul Russell (Chief Engineer, Boeing Airplane Safety Engineering) an August 18, 1994 article in The Aviation Daily reported that the "jet transport accident rate plummeted between 1959 and 1975 but has been fairly flat since then...". "With more and more traffic looming in the future ..." there is "a projection of one jet transport hull loss per week by the year 2010". A hull loss is airplane damage which is substantial and beyond economic repair. Stephen L Nicoud [Disclaimers...] ------------------------------ Date: Wed, 5 Apr 1995 14:48:00 -0400 From: jcd2@psu.edu (Joan Combs Durso) Subject: RISK of webpage rating system The only objection I can think of to the proposed system of sorting possibly objectionable material according to "over13" and etc is this: one of the current justifications for NOT regulating the adult material is that it takes some looking to find it. The proposed rating system would seem to make such materials readily identifiable via searching, thus pointing out for all the world the locations of this material, and making it easier for kids using unrestricted browsers to find. Joan Combs Durso, Penn State Great Valley ------------------------------ Date: Tue, 4 Apr 95 14:29:01 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Chunnel as a Theme Park (Re: Ghost trains, Wodehouse, RISKS-17.03) This happened to my wife a couple of weeks ago & she said some passengers became somewhat frantic looking for rising waters - officials did come around giving out coupons for a half price repeat trip if taken within two months - Universal Studios did something similar when it opened and the Jaws ride did not work. The real RISK will occur if (when) a driver ignores a real signal. Padgett ------------------------------ Date: Thu, 6 Apr 1995 16:20:59 +0100 (BST) From: jonsg@diss.hyphen.com (Jon Green) Subject: Insecurity over ATM security My local branch of the Midland Bank has just upgraded its ATM (automatic teller machine - hole in the wall cash dispenser). The old unit had a central keypad, and a green screen with a filter which restricted the useful angle of vision to about ten degrees either side of dead-in-front. The screen was positioned to the left of the machine, making it easy to block almost the whole arc and it was not readable from more than about 5m away. You could prevent all but the most persistent shoulder-hanger from seeing your PIN being entered, and your balance when it came up on the screen, by interposing your body. The new box features a nice bright colour screen and flashing lights to point you to the next bit of the ATM to look at (card slot, cash slot and so forth). Unfortunately, the nice bright screen is visible clearly from about 10m or more away, over an approximate 90 degrees of arc at least. To make things worse, the keypad is placed to the left of the machine, so that 90% of the population is left to dial in their PIN slowly and laboriously with their wrong hand. Oh, and the keys are so stiff that anyone standing to the right of the machine could not hope to avoid being able to read off the PIN as it is stabbed in. The final insult is that - like former machines from the same bank - the balance is shown on-screen only. No option to print it out instead. What a disaster! The RISKS abound - PINs are highly visible from an adjacent position, all on-screen transactions are highly visible over a wide area and there is no option to check your balance in privacy. The only consolation is that, in sleepy Diss, a mugging would be the talk of the town for months. I had a word with the branch manager. Apparently, these machines are replacing existing units everywhere in the UK in a rolling upgrade programme. He conceded the security problems - reluctantly, after a predicatable comment that, "They must have looked into the security aspects beforehand." I suggested that both (1) an arc-restricting filter be added, and; (2) the firmware be altered to allow an option for balances to be printed only, rather than displayed. I get the impression that the "Listening Bank" will quietly file the suggestions in the round file. jonsg@hyphen.com Hyphen home page: http://www.hyphen.com/ jon@sundome.demon.co.uk And mine: http://www.hyphen.com/html/jonsg/ ------------------------------ Date: Tue, 04 Apr 1995 10:13:10 PDT From: Nancy Leveson Subject: Safeware: System Safety and Computers NEW BOOK-- Safeware: System Safety and Computers, by Nancy G. Leveson, University of Washington (leveson@cs.washington.edu), Addison-Wesley, ISBN: 01201-11972-2, $49.50. This book examines past accidents and what is currently known about building safe electromechanical systems to see what lessons can be applied to new computer-controlled systems. One lesson is that most accidents are not the result of unknown scientific principles but rather of a failure to apply well-known, standard engineering practices. A second lesson is that accidents will not be prevented by technological fixes alone, but will require control of all aspects of the development and operation of the system. The features of a methodology for building safety-critical systems are outlined. PART 1: The Nature of Risk (126 pages) Is there a problem? How safe is safe enough? The role of computers in accidents Software myths Why software engineering is hard Problems in ascribing causality A hierarchical model of causality Root causes of accidents Do humans cause most accidents? The need for and role of humans in automated systems PART 2: Introduction to System Safety (50 pages) Foundations of system safety (systems theory and systems engineering) Historical development Basic concepts (hazard analysis, design for safety, management) Software system safety Cost and effectiveness of system safety Other approaches to safety (industrial engineering, reliability engineering) PART 3: Definitions and Models (75 pages) Terminology Accident models Human task and error models PART 4: Elements of a Safeware Program (290 pages) Managing safety (the role of management, setting policy, communication channels, setting up a system safety organization, place in the organizational structure, documentation) The system and software safety process (general tasks, real examples) Hazard analysis (what it is, how to do it, types of models, types of analysis, current models and techniques, limitations, evaluations) Software hazard analysis and requirements analysis Designing for safety Design of the human--machine interface Verification of safety (testing, software fault tree analysis) APPENDICES: Detailed descriptions of well-researched accidents along with brief descriptions of industry-specific approaches to safety (132 pages) A. Medical Devices: The Therac-25 story B. Aerospace: The civil aviation approach to safety, Apollo 13, DC-10, and Challenger C. The Chemical Industry: The chemical process industry approach to safety, Seveso, Flixborough, and Bhopal D. Nuclear Power: How a nuclear power plant works, The nuclear power approach to safety, Windscale, Three Mile Island, and Chernobyl ------------------------------ Date: Mon, 3 Apr 1995 22:12:13 -0400 From: winn@Infowar.Com Subject: InfoWarCon '95, First Call for Papers InfoWarCon '95 A 2 Day International Symposium on Information Warfare September 7-8, 1995 Stouffer Concourse Hotel Arlington, VA Presented by National Computer Security Association Winn Schwartau and Interpact, Inc. Robert Steele and OSS, Inc. For Call for Papers or further information, contact National Computer Security Association 10 South Courthouse Avenue Carlisle, PA 17013 Phone 717-258-1816 or FAX 717-243-8642 EMAIL: 74774.1326@compuserve.com CompuServe: GO NCSAFORUM or Winn Schwartau Interpact, Inc. Information Security & Warfare V:813.393.6600 F:813.393.6361 Email: Winn@Infowar.Com ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.04 ************************ 8-Apr-95 0:09:42-GMT,22069;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id UAA27134 for ; Fri, 7 Apr 1995 20:09:41 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id UAA01827 for ; Fri, 7 Apr 1995 20:09:37 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.11+bestmx+oldruq+newsunq+grosshack/8.6.11) with SMTP id UAA08068 for ; Fri, 7 Apr 1995 20:09:24 -0400 Received: by chiron.csl.sri.com id AA18228 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Fri, 7 Apr 1995 17:00:43 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 7 Apr 95 17:00:41 PDT Subject: RISKS DIGEST 17.05 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 7 April 1995 Volume 17 : Issue 05 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** PROBABLY NO RISKS NEXT WEEK. SEND GOOD STUFF IN, HOWEVER. ***** ***** See last item for further information, disclaimers, etc. ***** Contents: The risks of flying pigs (Jose Reynaldo Setti) Same Old Song: More calendar problems (Chuck Weinstock) The Risks of believing in Lawyers (jacky mallett) Re: More on German Train Problems (Donald Mullis) Re: RISKS of non-standard interfaces (Matthias Urlichs) Photo ATMs (Harold Asmis) Re: Errors in patent databases (Jerry Leichter) Risks of tightly-packed telephone-number space (Jeff Grigg) RISKS of Digital Analogy [SATAN] (Bart Massey) SATAN, burglaries, and handcuffs (Matt Bishop) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: Fri, 7 Apr 1995 10:47:20 PDT From: Jose Reynaldo Setti Subject: The risks of flying pigs The Toronto Globe and Mail reports that a commercial jet carrying 72 pigs and 300 human passengers had to make an emergency landing after having its fire alarms triggered by excessive levels of methane, ammonia and body heat in the cargo hold where the pigs were traveling (you surely did not expect that the pigs were traveling economy class). Apparently, excessive flatulence, urine, droppings and the heat generated by the bodies of the pigs caused the automated fire-extinguishing system to flood the cargo hold with halon, killing 15 of the very valuable hogs. The risks of flying pigs are evident. Jose' Reynaldo Setti , Visiting University of Waterloo (Canada) from University of Sao Paulo (Brazil) ------------------------------ Date: Fri, 07 Apr 95 13:18:51 EDT From: Chuck Weinstock Subject: Same Old Song: More calendar problems For my personal E-mail, etc., I use the services of an Internet provider. I noticed today that the systems were still on Standard Time. I sent a message to the operators and received the following in return. Due to an obscure bug in the system libraries, for this particular switch to daylight savings time only, the system calculated when it should change to DST incorrectly. (It thinks it does not start until this coming Sunday.) Because the bug will not occur in other years, and because we would have to rebuild all the system programs which depend on this system library, which would take longer than a week, we decided to just wait out the week until the clock returned to sanity. If this is causing you any specific problems, please let us know. I'm sure this sort of thing is well documented in RISKS ... so much so I continue to be surprised that I'm surprised that it continues to happen. Chuck ------------------------------ Date: Fri, 7 Apr 1995 09:06:00 -0400 From: "jacky (j.) mallett" Subject: The Risks of believing in Lawyers Atlas Computer Systems has fired the advertising consultant who suggested that posting an advertisement to all the Usenet newsgroups was an effective way of advertising a 1-gigabyte hard disc drive. Atlas suffered several days of mail-bombing as well as repeated calls to its 1-800 number from irritated Usenet readers. The New Scientist quotes Atlas's vice-president Matt Nye as saying that the consultant suggested spamming the newsgroups after reading Canter and Siegel's infamous publication "How to make a fortune on the Information Superhighway". It's nice to know there is some justice in the world. - Jacky Mallett ------------------------------ Date: Fri, 07 Apr 1995 15:50:12 PDT From: Donald Mullis Subject: Re: More on German Train Problems (Weber-Wulff, RISKS-17.02) : The defensive programmer will assume that all allocations will fail, : and structure the software to handle such a case. Furthermore, the software's ability to recover from the failure of any particular allocation attempt must be tested if we're to have any confidence in its working. It is not enough merely to bear in mind the possibility of allocation failure while writing the client code. Is it feasible to test all possible allocation failure modes? Forcing the allocation routine to always fail would be pointless, since attempts to allocate storage are likely to be contingent on the success of earlier attempts. Alternatively, one could maintain a counter N of program runs, and coerce the allocator to fail on its N'th call. This is a computational effort proportional to the program run time multiplied by the number of memory allocations in each run. This exhaustive method would exercise all possible failure modes for a given input, but is likely to be intolerably time-consuming for real programs. So we retreat to heuristic approaches. One such involves examining the sequence of stored program counters on the stack when the allocation routine is called. A checksum of the program counters can then be computed and compared against a list of those already seen. If no match is found, insert the checksum into the list and return failure; if a match is found, allocate the storage and return success. Thus, upon the first appearance of a particular sequence of program counters on the stack, the allocator will return failure. This has the desirable effect of exercising allocation error recovery code that might appear anywhere in the call chain. However, if that error recovery code contains a bug that only manifests itself when the program variables assume some particular state, the bug may not be found. Consider the following slightly contrived example in C: void *p1; void *p2; Bool allocate_p1_and_p2() { int np1bytes; for ( np1bytes = 1024; (p1 = malloc( np1bytes)) == NULL; np1bytes >>= 1) ; p2 = malloc( 1); if ( p1 == NULL && p2 == NULL) /* never satisfied */ return TRUE; /* XXX: should be FALSE */ else if ( p1 == NULL && p2 != NULL) free( p2); return FALSE; else if ( p1 != NULL && p2 == NULL) free( p1); return FALSE; else return TRUE; } With the stack-examining allocator described above, the line marked with "XXX" will never be executed, and its bug won't be found. One can imagine an allocator that fails pseudo-randomly according to some probability distribution, but again, the more failures, the longer the run time, with no guarantee of finding all possible bugs in the recovery code. ------------------------------ Date: Tue, 4 Apr 95 15:39 MET DST From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: RISKS of non-standard interfaces (Schroeppel, RISKS-17.02) > In the real world, systems and customers make various adjustments when faced > with long lines [...] In the real world, people also make various adjustments when faced with short lines, the most prominent of which is to use the service more, causing the lines to get longer very fast. (NB: Note that people with immediate heart problems are unlikely to come back later. :-( ) This is shown in analyses of real-world commuter traffic patterns. People use the shortest way to work available. So if there's a congestion and you build a new bypass, within a few weeks more people will use the new road, until it's just as congested as before. Unless you eliminate all points where congestions can form, which is of course impossible in the real world. The better way to reduce congestion is to offer an alternate service. For commuters, you use railroads (or tell them to stay at home and commute electronically ;-) -- for people with heart problems, the sensible solition would probably be a fast-track way to get people with life threatening problems ahead of those who wait for getting their warts burned off. Don't ask me, though -- the real RISK is to jump to untenable conclusions ("halve the response time by standardizing on one defibrillator") based on incomplete data. Matthias Urlichs Schleiermacherstra_e 12 90491 N|rnberg (Germany) CLICK here urlichs@smurf.noris.de ------------------------------ Date: Fri, 7 Apr 1995 12:29:47 -0400 From: harold.w.asmis@hydro.on.ca (Harold Asmis) Subject: Photo ATMs (Re: Insecurity over ATM security, RISKS-17.03) This reminds me of an incident that happened about 2 years ago. In Toronto, we used to have these wonderful wall-mounted ATM's in shopping malls. They had high, wall-mounted, membrane keyboards, and were located where lots of people could "hang out". A generally shorter, thinner than average, female co-worker told us that she had used such a machine, had entered a fairly complex transaction, removing money from a secondary account. A hour or so later, while shopping for clothes, her purse was stolen. Within minutes, large amounts of money were removed from her accounts. It was fairly obvious, that someone had watched and memorized her entire key-sequence. They then followed her, or sent someone to steal her purse at an unguarded moment. Luckily for her, it was shown that her PIN number was not obvious, and was not written down anywhere. The bank fought furiously, but she had family and friends with a lot of influence (threatened to take out all their money), and she got her money back. Although the bank denied everything, it was interesting to note, that within months, all such machines were being ripped out from shopping areas and being replaced with "shrouded" keyboards. Also, "hidden" cameras are now appearing everywhere. Harold Asmis, Ontario Hydro Nuclear Tel. (416) 592 7379 Fax (416) 592 5322 Harold.W.Asmis@hydro.on.ca ------------------------------ Date: Sun, 2 Apr 95 11:45:27 EDT From: Jerry Leichter Subject: re: Errors in patent databases (Gray, RISKS-17.01) In RISKS-17.01, John Gray summarizes a report from New Scientist about problem in searching databases of patents, including in particular problems arising because of typos and spelling errors in the database. Plus ca change, plus ce la meme chose. In roughly 1980, I did some work on a spelling checker program. As part of this, I dug through the literature. I found an article - source and details long forgotten - that reported on an empirical study of some kind of textual database. The study found that a significant portion of the entries in the database contained spelling or other recording errors, many of them in the indexed portions of the data. The conclusion was that queries based on exact matches stood a significant chance of failing to find entries they should have found. I don't recall the domain of the database involved, but as I recall missing even one entry that should have matched was considered to be a problem. As a result, they recommended that all queries use some kind of "loose match" algorithm. (I don't recall if they suggested one.) At least fifteen years later, we appear not to have learned this lesson. This is, by the way, an example of a significant limitation of many computer- based indexing systems: They make it difficult to use the *human* ability to do smart approximate matching. A couple of years ago, I heard a fragment of an interview with an author of a book that sounded interesting. I was only able to get the author's last name, and an understanding of the meaning of the title - not the actual title. When I later tried to use the on-line catalogue at the local library, I found it very difficult to locate the book. The catalogue was tree-structured: I had to first choose a particular author - and there were a good number of them with the same last name - then view titles by that author, a few at a time. I gave up after a little while and located a paper copy of "Books in Print", where a few seconds of scanning "by eye" located the book. Computer interfaces work well when you use them to do what the designers had in mind, but when it comes to true flexibility, more traditional designs can often win big, exactly because they are better at "getting out of the way" and letting the pattern matcher in our heads do the work. Jerry ------------------------------ Date: Thu, 6 Apr 95 19:42:20 CDT From: jeff@michelob.wustl.edu (Jeff Grigg) Subject: Risks of tightly-packed telephone-number space Here in Saint Louis we're running low on telephone numbers. With the rapid rise in cellular service, many new phone numbers have been assigned in this area code (314), leading to something of a shortage. This causes (at least) two problems: 1. more wrong numbers when people transpose digits 2. rapid reassignment of numbers when service is disconnected #1: wrong numbers are more likely to successfully connect -- to the wrong person The first problem became REAL noticeable to me when some company in Australia tried to FAX documents to a decorating company in my exchange several times a night over several nights -- AT ABOUT 2:00 AM, Saint Louis time. They had the last 2 digits of the phone number transposed. At no time did they try the number by hand or turn on / listen to their FAX speaker. (You'd think that after several unsuccessful FAX attempts in a row to a new number, they'd try it with a voice phone!) This is really a risk of having voice and data communications over the same network. The fix: I hooked up a FAX machine to my home phone and received the FAX one night. By reading the FAX I could tell who sent it and who they were trying to send it to. (The correct FAX number, without digits transposed, was printed on the FAX they sent!) I forwarded the FAX to the intended recipient, and called them, asking them to talk to their Australian customer. But their telephone operator was playing stupid that day, and kept asking what business relationship I had that their Australian customer would want to FAX documents through me. Telling her about the transposed digits in the phone number didn't help. Eventually I gave up and called the Australian company directly. They understood the problem immediately. (...and we wonder why we loose business to foreigners -- who have brains and use them. ;-) #2: disconnected numbers are more likely to connect -- with the wrong person After moving in, I was given a number that had obviously just been released by someone moving out of my exchange. For the first few months, I'd get several calls a week asking for the other person. I called directory assistance and found his new number. (He was still living in Saint Louis.) When I get calls for him, I give them his new number. There's nothing the telephone company can do to fix this, given the shortage of phone numbers. It's amazing: After 2 years, I still get 2 or 3 calls a month from sales people asking for that other person. He must be on all the best "telephone sucker lists." The sale people almost always give up as soon as they find I'm not who they're looking for. ------------------------------ Date: Fri, 7 Apr 1995 12:01:55 -0700 From: Bart Massey Subject: RISKS of Digital Analogy [SATAN] (Re: A possible "solution" to Internet SATAN: Handcuffs -- RISKS DIGEST 17.04) > By close analogy, SATAN's parents' attitude appears to be that it's > perfectly OK, perhaps even admirable, to go from house to house ... and extends the analogy to argue that those probing systems gratuitously should be punished even if they cause no harm. I think that this quote illustrates well the RISKS associated with what Usenet readers once referred to as "analogy wars" (did Tom Duff coin this phrase?). The risk comes in two parts: 1) It is easy to confuse an analogy with an isomorphism, and behave accordingly. 2) It is easy to take advantage of (1) to win an argument by choosing an analogy which, if treated as an isomorphism, leads to a desired conclusion. In this particular case, consider the following scenarios: a) I decide to implicate X in a crime, so I hack a copy of SATAN so that it looks like my security probes are coming from X. b) I probe randomhost.subdomain.cs, and the DNS resolver decides that this must have been in Czechoslovakia. What are some analogous situations in "burglary world"? a[b]) I disguise myself as X, and then deliberately let myself be caught burgling a house. b[b]) I decide to try to break into my own house to test its security, but accidentally try to break into another house which looks like mine. Neither of these "burglary world" situations seems too likely. This can be seen to be a result of subtle problems in the analogy: In a[b], it would be difficult to disguise oneself effectively enough to achieve the desired result. In b[b], I am unlikely to be confused about which house is mine. (I also am unlikely to try to test a home's security by attempting a breakin.) The "burglary world" [system == home, network == world, port == front door, security == lock, intruder == burglar, legal system == legal system] analogy is very popular on the net, but it really doesn't seem to me to work very well. I find the final identity, in particular, very disturbing. I personally think that SATAN's authors (*not* parents :-) had the attitude that "it's perfectly OK to send network packets to a computer system in order to see how it responds" -- which seems to me like a much less controversial statement. Bart Massey bart@cs.uoregon.edu ------------------------------ Date: Fri, 07 Apr 1995 09:49:03 -0700 From: Matt Bishop Subject: SATAN, burglaries, and handcuffs (anonymous in RISKS-17.04) The SATAN tool's proper use is very different: it's for checking YOUR OWN systems. I doubt that the unnamed correspondent, or anyone else, would object to its use in that capacity. The argument that SATAN should not have been released because it can probe systems not under the prober's control strikes me as odd. The analogy of housebreaking given above overlooks that attempted burglary is illegal in most jurisdictions that I know of. That's what the intruder would be charged with in the analogy above. Does this mean we should ban all tools that could be used to aid someone in checking the safety of a house, since those tools can be used to find the weak points in another's house? Perhaps a simpler conclusion to draw from the analogy is that there is no tool or device that is completely beneficial. Everything can be abused, and SATAN is no exception. The response should not be to focus on the release of the tool, but to focus on educating people in the customary codes of behavior and chastizing those who abuse the tools -- anyway, that's my opinion. The anonymous poster makes this same point later on, but its importance is vitiated by the characterization of the morality of the authors of SATAN (a characterization with which I disagree, by the way). Matt Bishop [BTW, RISKS received too many responses to the original message to include here. Many were supportive of SATAN as a sincere effort to improve security. Several messages took offense to the anonymous author's choice of analogy. Others were seriously annoyed at the mention of the National Rifle Association. In these respects, your moderator regrets apparently being less than careful in his (im)moderation. Sorry! PGN] ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.05 ************************ 18-Apr-95 18:27:16-GMT,30884;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA25838 for ; Tue, 18 Apr 1995 14:27:14 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA18997 for ; Tue, 18 Apr 1995 14:27:12 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id OAA16159 for ; Tue, 18 Apr 1995 14:26:52 -0400 Received: by chiron.csl.sri.com id AA23899 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Tue, 18 Apr 1995 11:10:59 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 18 Apr 95 11:10:58 PDT Subject: RISKS DIGEST 17.06 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 18 April 1995 Volume 17 : Issue 06 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Computer crash freezes train traffic (David P. Schneider) RISKS of patrol-car computers (Glenn Story) Man arrested via stock-control systems (Timothy Panton) Barcode provides picture of burglar (Sean Burns) FDA orders recall of blood bank software (Paul Szabo) Installing Old Software on New Systems (Bruce E. Wampler) The state of software engineering (Jerry Leichter) About the recent Sun "CWS" mailstorm (Mark Graff via David Lesher) New risks in private digital cash (?) Overnight Privacy RISKS... (Peter Wayner) Fry-by-wire? Or just the currents of progress? (Ed Ravin) Re: "The Satan Bugs" () Risks of Library Catalog Keywords (John McHugh) Re: Searching for a book in a database (Erik Kraft) Re: Errors in patent databases (Mark Lomas) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 13 Apr 95 12:18:00 PDT From: d_schneider@emulex.com Subject: Computer crash freezes train traffic >From the Orange County Register, Orange County CA, 3/29/1995 edition, crediting "Register news services": The article describes in 3 paragraphs the effect on train traffic of a computer crash: "[it] froze passenger and freight trains in their tracks" for 2 hours. 8 states in the Southeast US were affected during Monday (3/ 27) evening rush hour on tracks operated by CSX Transportation. Service was restored "under human direction". Services that were held up included Amtrak (2100 passengers), Tri-Rail commuters in south Florida (5000 passengers) and freight trains in locations from Louisiana to North Carolina. [Notes from dps: Most major railroads have reduced the number of dispatching centers, in the trend typical of many modern businesses. For instance, UPRR now operates all dispatching from Omaha, Nebraska, and SPRR from Denver, Colorado. CSX can be assumed to have done the same type of consolidation. Key elements of this move include computer displays to show the status of tracks and traffic flow (replacing specialized "CTC" boards), communiciations equipment (often already in plade, just a new hop). These computers often also show the availability of equipment. Resuming "under human direction" was probably done by the same dispatcher staff, but using "track warrants" instead of signalling, and with locations of trains tracked by radio rather than by the signalling equipment. This would result in slower speeds and larger separations. I would be interested in hearing more details of the crash and in the backup procedures.] /dps (David P. Schneider, Emulex Network Products) ------------------------------ Date: 16 Apr 95 10:40:00 +1700 From: STORY_GLENN@tandem.com Subject: RISKS of patrol-car computers There was an article in the Saturday San Francisco Chronicle with the headline, "Police Hunt Slayer of Oakland School Cop." At first glance this appears to be yet another sad tale of inner-city violence with no relation to computer RISKS. However, buried in the middle of the article is the statement, "The source also said that the slain officer was found sitting in his patrol vehicle and may have been using his patrol car computer at the time of the shooting." Could it be that the visual and mental concentration required to operate a computer can constitute a potentially fatal distraction for a police officer? Glenn Story story_glenn@tandem.com gstory@netcom.com 70135.756@compuserve.com ------------------------------ Date: Tue, 11 Apr 1995 14:25:53 +0200 From: Timothy Panton Subject: Man arrested via stock-control systems I heard an item on the BBC radio 4 news last week that set me wondering about stock-control systems. The story described the arrest of an alleged supermarket blackmailer. He was arrested for planting (fake) bombs in supermarkets. The reporter went on to say that he had been caught because the police had been able to trace him as the owner of the shoebox used in one of the fake bombs. It seems to me that the police must have traced the stock number on the box down the distribution chain using the shoemakers computer systems. Once they determined which shop it was sold from they must have used the shop's stock control system to determine when it was sold. In order for the police to determine who bought the shoes (and the box) the arrestee must have used a means of payment (e.g., credit card) that included his name. I applaud police actions to catch a blackmailer, and I assume that there is more evidence against him to support their case. But I can't help wondering where all those shoeboxes I threw away are now, and who is doing what with them? Is there a risk here? It depends on you. If you a) Trust the police, b) Trust all the people who work in shops you use, c) Have nothing to hide, d) Will never be involved in a case of mistaken identity, then I guess not. Tim Panton ------------------------------ Date: Mon, 10 Apr 1995 16:47:12 CST6CDT From: "Sean Burns" Subject: Barcode provides picture of burglar On Friday, 7 April 1995, KNOW (the St. Paul, Minnesota, National Public Radio affiliate) reported that a jewelry store in St. Cloud had been burglarized. In order to circumvent the jewelry store's alarm the thief first broke into an adjacent florist's shop. He then used a pickaxe to hack his way through an interior wall into the jewerly store. He looted the store at his leisure and fled leaving no prints or other evidence behind--except the pickaxe. A sharp-eyed police officer noticed a barcode sticker was still attached to the pickaxe. The officer took the tool to a local hardware store and had the owner scan the code into his register (the reporter did not say if the officer visited multiple hardware stores). Voila! The pickaxe had been sold the day before the burglary. By matching the time of sale as recorded in the register's database to the time stamp on the store's video-surveillance tapes a clear picture of the suspected burglar was obtained. At air time he had not yet been apprehended. Sean Burns, University of Minnesota/College of Human Ecology, 48 McNeal Hall 1985 Buford Avenue, St. Paul, MN 55108 burns@che1.che.umn.edu 612.624.3281 ------------------------------ Date: Wed, 12 Apr 95 08:29:28 PDT From: szabop@kelly.pen.tek.com (Paul Szabo) Subject: FDA orders recall of blood bank software < Abstracted from The Oregonian, 12 Apr 1995, Section B, page 1 > Computer software used to track blood supplies in about 250 blood banks has been recalled because of the possibility that it could allow the release of contaminated blood. Among the problems with the software: * Untested blood donated by a person for his or her own use could be release for general transfusions. * Blood that should be quarantined while being test could remain available for use !!if two computer users changed its status at the same time!! * The status of a donor whose blood should not be used, after being updated, could revert to its former status, resulting in blood from an ineligible donor being used. It sounds like inadequate test methods are being used to test the software, given the classic mistake in the second item above... The FDA caught the errors in an inspection of Informedics (which is doing business as Western Star), the Lake Oswego, Oregon company that produces the software. John Torici, president of Informedics, said that his company has about 250 clients in six countries, "and in the 12 years we've in in the business they've processed literally millions of units of blood and there has never been an incident of bad blood being released as a result of our software" Other countries don't have our tort system that makes everyone here eager to sue. Is this a good measure of software quality, given the obvious mistakes made above? Does the FDA use adequate software testing methods? Paul Szabo Portland, OR ------------------------------ Date: Wed, 12 Apr 95 13:01:41 MDT From: wampler@cs.unm.edu Subject: Installing Old Software on New Systems It can be risky to install old software on newer systems. Among the many problems Microsoft Windows has it the problem of keeping up with the latest device drivers. This problem is especially troublesome for multimedia cards and drivers, which are usually installed in the \WINDOWS\SYSTEM directory. My own system has mostly 1994 versions of system software and drivers (but it is still Windows 3.1). The other day, I was looking for some trivia information about the "Sound of Music" (did it get an Oscar for best song?), and none of my usual references had the answer. I did have a copy of Microsoft's Cinemania 1992, which I haven't used since I got my current machine. So I thought, OK, simple, I'll just install it to find the answer (No -- best songs are for original scripts, not adapted -- it did get Best Scoring for Adapted Works). I got my trivia answer, and things seemed fine, but they weren't. Because multimedia has always been one of the big problem areas of Windows, and the 1992 Cinemania had some drivers that were "better", it seems that it blindly took its "latest" 1992 versions and replaced the existing drivers in the \WINDOWS\SYSTEM directory without taking into account that it might be 1995 now. (It didn't ask for any confirmation - it just overwrote!) So, the next time I booted my system, my sound was broken. It took me a couple of hours to diagnose the problem and get the current drivers reinstalled, and I know what I'm doing -- pity the poor new or casual user. The RISK -- don't forget today's news is tomorrow's history. While Microsoft might have been trying to be helpful in 1992, they forgot that someone just might use it in 1995. All very irritating! Bruce E. Wampler, Ph.D. (wampler@cs.unm.edu) Adjunct Professor, Department of Computer Science, University of New Mexico ------------------------------ Date: Fri, 14 Apr 95 08:47:55 EDT From: Jerry Leichter Subject: The state of software engineering The following was forwarded to me through a mailing list, and I can't even determine with certainty if the signature line at the end is from the author or some intermediate forwarder. The story is worth the telling, however. -- Jerry Subject: Good software humor: What would you do? At a software engineering course for aspiring managers the participants are asked: If your team of programmers/analysts implemented airplane control software, and you were flying one day, finding out before take-off that this plane was one of those equipped with YOUR software, how many of you would get out? All except one person raised their hands. The course instructor asked the only one to have left his hand down "What would you do?" "Stay in my seat -- if my team wrote the software for this plane, it wouldn't move, let alone take off." Rick Simkin rick@frame.com PHONE: +1 312 2664437 Frame Technology, Advanced Products Services, Chicago ------------------------------ Date: Mon, 10 Apr 1995 20:30:36 -0400 (EDT) From: wb8foz@netcom.com (David Lesher) Subject: Here's a classic... Date: 10 Apr 1995 20:49:58 GMT From: graff@liberty.Eng.Sun.COM ( Mark Graff ) Newsgroups: comp.security.unix Subject: About the recent Sun "CWS" mailstorm Last week a great many Sun customers were subjected to a torrent of mail messages which swamped the Customer Warning Mailing list. Since quite a few of those folks also read this newsgroup, I thought I would post this apology and explanation here. First, quickly, the current status is: 1. The "cws" mail alias is once again disabled. The mail cascade is over. 2. All requests to be added to or removed from the list have been logged and will be executed before we send out the next bulletin. 3. We have reviewed the procedural errors which led to the flood of messages and taken the steps necessary to prevent a repetition. Now, here is a partial explanation of what happened. I maintain a mailing list of people interested in receiving Sun Security Bulletins. The list has thousands of addresses on it, some of which are themselves repeater aliases. When I am ready to send out a security bulletin, I (1) produce a mail alias from the mailing list, (2) active the mail alias on my machine, (3) send the mail, and (4) deactivate the alias. The deactivation step is important. It prevents mailstorms and stops malefactors from probing my machine in an SMTP dialog to obtain a list of bulletin recipients. This step was omitted when we sent out our bulletins last week; so, when a recipient replied, asking to be removed from the list--and cc'ed the "cws@liberty.sun.com" alias--the fuse was lit. When others sent responses to that request to the same mailing list, the mailstorm was launched. In a second procedural error, the next day, no one who could deactivate the list was watching the traffic. So what would have been an annoyance turned into a real donnybrook. Of course as soon as the right people got the right message the alias was deactivated, stopping the cascade of messages. The problem was exacerbated by the fact that (appearances to the contrary) I handle list requests manually, as a security measure. One correspondent, not aware of this, sent several dozen "unsubscribe me" messages to the entire list in an attempt to escape the cascade. This resulted in the creation of thousands of additional messages. I am responsible, and will apologize personally to as many customers as I can. In the meantime, please understand that this was the result of human errors and a good measure of bad luck--not a bad policy, or a lack of interest on our part. I would also like to express my thanks to the many people who, unaware of the exact nature of the problem, suggested technical solutions. As of this moment I am not planning any changes in the handling of the mailing list, which we operated with no problems for several years before the incident last week. We are of course reviewing alternatives. -mg- Mark Graff Sun Security Coordinator mark.graff@sun.com security-alert@sun.com 415-688-9151 p.s. Please correspond with me directly for any further information. ------------------------------ Date: Mon, 10 Apr 1995 19:17:46 -0400 (EDT) From: SYSTEM@LOWGMO.LARC.NASA.GOV Subject: New risks in private digital cash While writing an article about digital cash, a number of new risks occurred to me. If truly safe, secure, and private digital cash can be created, legitimate businesses will not be the only originations to avoid the problems of transporting large amounts of cash. The classic suitcases full of cash will be replaced by a smart card or credit transfer that will look just like any other. To transfer a few million to an offshore bank, you just make a call. For additional security, multiple transactions might be sent from pay phones, cellular phones, and/or sent through an ever changing list of dummy corporations, forwarded phones, etc. The information could be hidden in legitimate data transfers, or just carried. After all, one smart card will look just like any other, no matter how much money is inside. Or the guts could be removed from the card and hidden nearly anywhere. Spies, etc. will love this new money. This particular risk will depend to some extent on just how private digital cash becomes. If it is really an advanced debit card system with encryption, privacy will depend on the ability to get a card without supplying large amounts of personal information. If ID is required only the criminals will have privacy. After all they don't mind lying, don't have fixed addresses, and the risks are minor compared to those they normally face. If the card or account numbers are tracked to deal with theft, fraud, etc., then they will be available to the IRS etc. Of course this information will only be available to the "proper" authorities ... and anyone who knows who to bribe. Also since the cards or what ever, will inevitably have an account number, public key, or other identifier, it won't be long before someone starts connecting paid for by account xxxx and sent to address yyy, and there goes privacy. On the other hand, people are ingenious, and many will be highly motivated. Black market cards and/or accounts will exist. The listed owners might even be real, illegal aliens, little old ladies with nothing to lose, or totally fictitious. When the cards or accounts become international, whole new worlds of villainy open up. The very definition of a bank may change. Most banking is already an exercise in data processing. Without the need for a vault and tellers, the whole thing might be run from an advanced laptop. The notion of offshore banks might take on a new meaning, when the bank might be mobile, or distributed over large distances and many jurisdictions. New, unforeseen risks are also inevitable. When paper money replaced coinage, inflation became almost inevitable. Not that many kingdoms or countries could long resist adulterating the coinage, but I know of no paper money that hasn't suffered inflation. One possible example of the new risks involves check float. Entire industries exist to exploit the time between a check being issued and when it clears. What happens when float, and checks, go the way of the Dodo? What happens to the Swiss banking industry if numbered accounts are no longer necessary? What happens to the IRS if everybody effectively has a numbered account? [Name not included in E-mail. PGN] ------------------------------ Date: Tue, 11 Apr 1995 20:55:08 -0400 From: pcw@access.digex.com (Peter Wayner) Subject: Overnight Privacy RISKS... A common theme in this forum is how computers can create dismay out of order. For instance, I've always considered FedEx to be far superior to the Post Office because you their computer system tracks the packages to the correct destination. Today's WSJ (April 11, 1995, B1) offers a story describing how lawyers routinely subpoena FedEx for these same computerized shipping records. The article mentions a tobacco researcher who had his FedEx shipments subpoenaed by a tobacco company interested in his correspondence. Being a curious and frequent customer of Federal Express, I called up their legal department to find out if anyone had been subpoenaing my shipping records. This seemed to upset them because they get 300-500 subpoenas a day and their data base just wasn't set up to look for my name. They did tell me that they can only offer proof of delivery and copies of the airbills generated from microfiche. These do not arrive overnight, however, because it takes them 2-6 weeks to process each court order. Oh, they did mention in passing that they don't keep any records of cash transactions. ------------------------------ Date: Sun, 9 Apr 1995 23:46:04 -0400 From: Ed Ravin Subject: Fry-by-wire? Or just the currents of progress? (Re: Wilson, 17.04) > Throughout the execution, the computer's systems monitor the current, > making sure there is no drop in power. I am aghast -- it sounds just like the technology used in ground-fault interruptors, those nifty gadgets that turn off the current if you you drop a plugged-in appliance into the tub with you. But instead, this system keeps the current on until its victim has shunted a sufficiently lethal dose. I suppose the lesson is that one person will always find a way to use a technology for the exact opposite purpose that another person was designing it for. And I suppose that computer programmers and electricians have already build lots of systems that have already intentionally killed more people than this electric-chair-controller will ever get a chance to do. But dammit, is this what folks had in mind back when they were inventing embedded controller systems, analog-to-digital converters, silicon-controlled rectifiers and the other doodads that this execution system must use? Ed Ravin eravin@panix.com +1-212-678-5545 ------------------------------ Date: Tue, 17 Apr 95 10:00 xxT From: [Another anonymized responder] Subject: Re: "The Satan Bugs" (RISKS-17.04) A previous anonymous poster [in RISKS-17.04] took some heat by calling the authors of the "Satan" security software "amoral". While that point may be arguable, how about another term that is harder to argue: "inept", or perhaps "sloppy"? Since the original much-heralded release of Satan, CERT has had to send out two bulletins warning of serious bugs in the original version, and in the succeeding version that was supposed to fix the bugs in the first version. In each case, the bugs were of the sort that INTRODUCED security holes where none had existed before. And of course each new version checks to see if it can exploit the security bugs introduced by the previous version--so if you ever stop updating you're really in for a surprise! It doesn't even appear that the bugs were terribly obscure--it looks more like a rush job with inadequate testing. Great security software. If you had a secure system before starting to work with Satan, you can end up with an insecure system afterwards. It's difficult to think of a much less desirable scenario. Such sloppiness in widely distributed software that is supposed to help solve important security problems is hard to rationalize, to put things politely. ------------------------------ Date: Sat, 8 Apr 1995 12:29:49 -0700 From: mchugh@cs.pdx.edu (John McHugh) Subject: Risks of Library Catalog Keywords The recent discussions of typos in databases, etc. remind me of a problem that I have noticed with the on line catalog for the library at Portland State University. Shortly before I started my Computer Security class last year, I decided to check the library's holdings in the area by using the on line catalog. I was somewhat surprised when a subject search using the subject "computer security" turned up very little. Not even Dorothy Denning's classic book was found. Looking up a few books by author or title and checking the index terms indicated that the appropriate search is "access control." There does not seem to be a way to reindex entries or to add cross references. One wonders how many searches go awry because of counter intuitive search terms. PSU's catalog system has another interesting "feature." It is impossible to get out of the system. It was apparently designed for dedicated terminals where the notion of termination or disconnection was considered inappropriate and when you connect to it via telnet you must escape to telnet and close the connection when you are done. John McHugh ------------------------------ Date: Sat, 8 Apr 1995 04:29:05 -0700 (PDT) From: ekraft@netcom.com (Erik Kraft) Subject: Searching for a book in a database (Leichter, RISKS 17.05) Jerry Leichter had a problem finding a book which he did not know the exact author or title. His story shows that a human can perform pattern searching faster then a computer to find the book, but this isn't always the case. The problem with the computer was poor database retrieval. I had a similar experience years ago at a library looking for a book I had seen for a few moments, but had forgotten the author, title, and catalog number. However, I remembered the first letter of the author's last name and the general subject. When I used the "friendly" public machines at the library to search for the book, I had no luck. Rather than scan books in the relevant section of the library, I went to the computer services department and talked to a friend in the library's computer department. By accessing the database through a "computerese" interface, I was able to search the entire database for books within a section of the library (by a range of Library of Congress numbers), first letter of the author's last name, and three possible subject keywords. The computer found two entries matching my request; one was my book. Risks? The "friendly" interface, while increasing general use among the public, lacks the power of a "computerese" interface. The users' perceptions about the power and ease-of-use of computers and databases become clouded because of an attempt to show them the power of same. erik kraft NeXT programmer / 3do programmer ekraft@netcom.com ------------------------------ Date: Wed, 12 Apr 1995 17:19:22 +0100 From: Mark.Lomas@cl.cam.ac.uk Subject: re: Errors in patent databases (Leichter, RISKS-17.05) Even if you do have the correct information at hand, you are relying upon the competence of the database designer. A few days ago I tried to order a book. I knew the names of both the authors, the title of the book, and the publisher. The only information I was lacking was the ISBN. "No problem" I thought, since most of the bookshops here in Cambridge now have access to an online catalogue of all books on sale in the UK. The shop assistant typed in the correct query (here I should explain that it wasn't her fault since, by looking over her shoulder, I could see that she typed everything correctly). The computer said that there were no matching entries. She then tried widening the search by missing out some of the information. Even when asked for all books written by either author the system claimed that nothing existed. Since I was certain of the publisher she agreed to phone them. They claimed it didn't exist, although I knew it did since I had reviewed it for a journal. They then found that their paper list didn't correspond to the computer list - it was listed on paper. Given the ISBN we checked again on the bookshop's system. Sure enough, there was the book with all of the details as I had given them. The book is now on order. However, if we hadn't persisted, the bookshop, and the publisher, and the authors, would have lost a sale. Failure to order a book may seem an unimportant problem, but it made both me and colleagues wonder how many relational databases aren't, and what are the consequences. Mark ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.06 ************************ 20-Apr-95 22:31:28-GMT,27086;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id SAA29803 for ; Thu, 20 Apr 1995 18:31:26 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id SAA18493 for ; Thu, 20 Apr 1995 18:31:23 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA08821 for ; Thu, 20 Apr 1995 18:30:45 -0400 Received: by chiron.csl.sri.com id AA25700 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Thu, 20 Apr 1995 15:14:33 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 20 Apr 95 15:14:32 PDT Subject: RISKS DIGEST 17.07 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Thurs 20 April 1995 Volume 17 : Issue 07 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: New Massachusetts password law invoked on hospital technician (PGN) Less than robust wiring designs (Tim Kolar) Fugue-by-Wire!? (James G Henderson) 11 B-boards dismantled in Montreal (Mich Kabay) Re: Installing old software ... (Ted Wong) Re: RISKS of patrol-car computers (Joe Chew, Matt Raffel) "Friendly" user interfaces (Re: Searching ...) (C. Titus Brown) Re: Searching for a book in a database (Jerry Leichter) Risks of online documentation (Prentiss Riddle) Risks of online catalogs (Doug Shapter) Computer-controlled electrocution (David Karr) 4th Conference on Software Risk (Lorrie Orndoff) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: Wed, 12 Apr 1995 12:49:43 PDT From: "Peter G. Neumann" Subject: New Massachusetts password law invoked on hospital technician Mark L. Farley, 34, of Lowell, was arrested on 9 Apr 1995. Working as an orthopedic technician in the Newton-Wellesley Hospital, he allegedly accessed a former employee's computer account to search through 954 confidential files of patients (mostly young females) for telephone numbers, which he then used to make obscene calls. (He had pleaded guilty in 1984 to raping an eight-year-old girl in Erving.) He is apparently the first person to be charged under a new Massachusetts statute that makes it a criminal offense to use someone else's password to gain access to a computer system. He is also accused of stealing hospital trade secrets, and making obscene or annoying telephone calls -- apparently from the hospital. [Source: Hospital Worker Charged under New Massachusetts Password Law By MATTHEW BRELIS, *The Boston Globe*, 12 Apr 1995.] [Health-care records are increasingly the subject of privacy concerns, because of their rampant abuse. This case has caused quite a stir in the Boston area. PGN] ------------------------------ Date: Mon, 17 Apr 95 18:31:07 PDT From: Tim Kolar Subject: Less than robust wiring designs I just received this peach from a friend at a local multi-million dollar computer company (after their phone was busy all day). They recently had some layoffs, but frankly it sounds like their problems started long before that: > My phone isn't really busy. There's a little problem at ******* today. > They were doing some facilities work in one of the labs and > accidentally set off the earthquake detector. Since earthquakes tend to > set off the indoor sprinkler system, the earthquake detectors shut off > electrical. This lab happened to share some wiring with the phone system, > and nobody knows how to reset it. This is one of those little gaps that > got left with the layoff. The Risks of not having detailed instructions for disaster recovery are apparent. The question of why a lab is sharing power with the main phone system is a sub-Risk left for the student. While I'm at it, just why would you design an earthquake detection system that didn't require two or more significantly separated points for verification? Local shocks from people dropping heavy objects are relatively common... -Tim Kolar cisco Systems ------------------------------ Date: Mon, 17 Apr 1995 21:43:05 GMT From: James@prognote.demon.co.uk (James G Henderson) Subject: Fugue-by-Wire!? You've heard of Fly-by-Wire? well what about Fugue-By-Wire! The UK New Scientist magazine, 15 April 1995, reports that Notre Dame's organ is not suitable for concerts following a two year restoration costing =A31.3 million (Pounds Sterling) in which six computers were installed to relay the organist's instructions from the manuals (keyboards) and pedals to the organ pipes. The cathedral's administrator has cancelled all concerts as a series of malfunctions, including `memory failure', has caused the organ (as he is reported as saying) `to suddenly stop working. It takes five to ten minutes to get it going again. This is too stressful for the organists who never know when it will happen'! It is still used for Mass, however, as when it `crashes' a small organ fills in the unintented silence. JS Bach should have been warned that his `Toccata & Fugue in D Minor' would be too `memory intensive' for organs of the future! James@prognote.demon.co.uk Program Notes Limited ------------------------------ Date: 20 Apr 95 13:12:03 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: 11 B-boards dismantled in Montreal Eleven Electronic Bulletin Board Systems Dismantled (From A Royal Canadian Mounted Police news release) Montreal, April 12, 1995 - Seventeen searches conducted in the Greater Montreal area by the Copyright Investigations Unit of the Montreal RCMP Federal Enforcement Section put an end to the operation of eleven electronic bulletin board systems (BBS). Since 6 o'clock this morning, 75 RCMP members have been dismantling bulletin boards specialized in circulating copyrighted Canadian software such as Le Correcteur 101, CorelDraw, Winfax PRO, as well as products developed by Audodes [Autodesk?], Borland, Clark Development, DataStorm, Disney, IBM, Lotus, Microsoft, Windows 95, Mustang Software, Novell, Playboy, Quarterdeck, Sierra, Symantec and many other firms. Computers and peripherals worth more than one hundred thousand dollars were seized, along with millions of dollars of pirated software. This is the most important operation of this kind yet in Canada against illicit bulletin board systems. About 15 persons will appear in court at a later date to face charges under the Copyright Act which sets out severe penalties for offenders: - 6 months and/or $25,000.00 per count for summary conviction offenses; - 2 years and/or $1,000,000.00 per count for indictable offenses. .... [invitation to press conference 95.04.11].... - 30 - Resource person: Sergeant Serge Corriveau Federal Enforcement Section Tel. (514) 939-8307 or Constable Gilles Deziel Community Relations Section Tel. (514) 939-8308 ----- _La Presse_, the largest newspaper in the greater Montreal area, published a news story about the raids on 13 Apr 1995 (translation and summary by MK): Major Strike by the RCMP in the InfoBahn [Gros coup de la GRC dans l'inforoute] by Eric Trottier, La Presse The RCMP has decided to do a little house-cleaning in the joyously anarchic world of the electronic highway. Thanks to a computer-science infiltration operation, the federal police yesterday dismantled 11 bulletin boards that were trafficking in tens of thousands of software packages around the world. "It's the first time we have been able to implement this type of penetration of BBSs. Even in the U.S., the most important dragnet of this type has so far only allowed the dismantling of six BBSs at a time," said Sergeant Serge Corriveau to La Presse shortly after the investigators completed more than a dozen penetrations and seized more than C$200,000 [U$140,000] of computer equipment. Key points from the article: o News of the raid spread rapidly through the Internet; o The 11 BBSs were involved in large-scale fraud in N.America and Europe. Subscription fees of C$30-C$50 per month allowed participants to download copies of proprietary software at will. o "Everything available legally on the market was offered by these BBSs," said Sgt Corriveau. o Some of the more audacious BBSs offered beta copies of Windows95. o There are about 700 BBSs in the greater Montreal area; the RCMP estimate that three-quarters of them traffic in stolen software. o Some of the BBS have become virtual flea markets of pornography, bomb-making instructions, and details of how to succeed at suicide. o In one of the shut-down systems, stolen goods and illegal assault weapons were advertised for sale. o It has taken a year to infiltrate the BBSs; some officers had to wait up to four months to gain entrance to the inner areas of the boards they were investigating. o The raids involved 75 officers in Montreal, Outremont, Repentigny, Longueuil, Saint-Amable, and the St-Jerome area. o The BBSs shut down are: Notice, Twins, Red Alert, Perfect Crime, Beyond Corruption, Line-Up, Wolf Pack, On the World, Restricted Area and Necromancer Mecon. o Most had about 6 telephone lines for full-time access, serving 100-250 clients, with some in Europe. The larges, Notice, had 350 clients who each paid $50/month, for an untaxed revenue of C$210,000 per year. o The police estimate that 11 to 15 criminal hackers will be indicted as a result of the raids. They each face fines of C$25,000 to C$100,000. M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC); Director of Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Tue, 18 Apr 1995 15:03:53 -0400 From: Ted Wong Subject: Re: Installing old software ... (Wampler, RISKS-17.06) >The RISK -- don't forget today's news is tomorrow's history. While >Microsoft might have been trying to be helpful in 1992, they forgot that >someone just might use it in 1995. All very irritating! --------------------------------- Of course not. Everyone would have switched to Win 95 by then... Maybe there is a RISK here. Suppose a software developer finds problems in some current version of a program, but instead of sending out an immediate bug-fix (with all its attendant negative publicity), elects to wait until the next major version release before including the fixes. If this release is then delayed, are users then left using broken software for longer than is necessary? Ted Wong, Computer Science, Cornell University ------------------------------ Date: Tue, 18 Apr 1995 19:23:08 GMT From: jtchew@netcom.com (Joe Chew) Subject: Re: RISKS of patrol-car computers (Story, RISKS-17.06) >Could it be that the visual and mental concentration required to >operate a computer can constitute a potentially fatal distraction >for a police officer? Depends on the situation. It would be foolish to begin using the computer when you knew you were in a tactical situation that demanded keen awareness of your surroundings. However, a cop who spent his entire shift worrying about being ambushed by someone with a high-powered rifle would, I should imagine, have a brief, ineffective, possibly even dangerous career en route to a psych disability. But perhaps there is a risk, related to the way a computer sucks your attention into a black hole where space and time have little meaning. A cop who pulls over into some secluded area to finish up his paperwork might well face a less absorbing task that lets him monitor what's going on outside the car. There's a RISK much more probable than getting ambushed, though. I became aware of it while watching "Cops" on the bread-and-circuses dispenser one night. Our hero was driving along a city street at a pretty good clip while in a complete heads-down mode, using the computer. Had there been a bicycle or baby buggy in front of the car, the screeching noise from underneath the axle would've been his first clue that something was wrong. --Joe ------------------------------ Date: Tue, 18 Apr 1995 14:53:10 -0700 From: raffelm@netcom.com (Matt Raffel) Subject: RE: RISKS of patrol-car computers (Story, RISKS-17.06) The story relating to the murder of an Oakland Cop, who was slain while using in car-computer, brings another "interesting" RISK to mind. Since the cop was murdered while using the computer, it is safe to assume that the cop was properly signed into the system, when he died. The criminal could have used the computer to access police files, perhaps alter them, or otherwise infiltrate the system and violate the integrity of the computer system. Matthew Raffel Interactive Software Development, Inc. raffelm@netcom.com ------------------------------ Date: Tue, 18 Apr 1995 13:49:31 -0800 (PDT) From: "C. Titus Brown" Subject: "Friendly" user interfaces [ Was: Re: Searching for a book... ] In response to Erik Kraft's message about the lack of power inherent to many "user friendly" interfaces: This sort of thing happens quite frequently; it's one of the reasons why I won't touch Window & Mac machines, while I love UNIX. The typical problem is that it's much easier to implement a "computerese" interface (which requires little design) than to design & implement a worthwhile user-friendly interface *that has the same flexibility*. The risks? Building software upon software that doesn't allow complete flexibility! Eventually *something* is going to break, and if low-level and flexible configuration/command ability isn't available, the only person who's going to be able to fix it will be the original programmer. Perhaps some advice: build the graphics interface to critical utilities on TOP of a flexible command-line system, not concurrent with it. [obRisks: since I don't deal with inflexible user interfaces any more, I don't have any recent examples of this sort of thing. The most relevant one I can think of is the (old?) NeXTStep graphical system manager interface. Once I deleted the NetInfo database, and (after browsing the manual pages in single user mode for several hours) had to reinstall the entire system. It's virtually impossible to change the system using the command-line utilities. ] Titus Brown, brown@krl.caltech.edu. ------------------------------ Date: Thu, 20 Apr 95 10:40:27 EDT From: Jerry Leichter Subject: Re: Searching for a book in a database (Kraft, RISKS-17.06) Erik Kraft responds to my comment about the advantage of "human search" of available computer search techniques in finding a book in a library listing by describing a similar problem he had, which he was able to solve by talking to a friend at the computer center and gaining access to the "computerese" interface. Curiously, when I first described my problem to a friend who uses the same library, he pointed out that the programs involved provided two interfaces: The "easy to use" hierarchical menu system meant for customers, and the higher-powered system meant for librarians. The particular search I needed could, indeed, have been done fairly easily from a librarian's terminal. But this illustrates another aspect of the same risk. Most people don't have friends at the computer center, or even know librarians who will let them use the "privileged" interface. The only interface available to them is the "public" interface, which in the interest of ease-of-use by a population who have no reason, time, or desire to "learn about this fancy computer stuff", has been deliberately limited in its capabilities. I recall a discussion I had a number of years back with Alan Perlis. (Alan was a wonderful person with a very broad range of interest and insights, so this isn't as odd as it will sound.) I had just been trying to buy a wood trash can. I couldn't find any - just cheap metal and cheap molded plastic "fake wood". I commented that technological advances sometimes lowered the quality of the products one could find. Alan's response was that, no, I was looking at it wrong. Pre-technology, most people could only afford to buy low-quality versions of a product; the reasonably well off could buy higher-quality versions. Technology - particularly automation - made it possible to raise the quality of the cheap stuff. This eliminated both the older forms of the product: The real junk was no cheaper to produce than the better post-technology product so couldn't compete; and the former "reasonable quality" was now much more expensive, and only a bit better. Often, a new "super-high-quality" stratum came into being as well - where "quality" often really means "snob appeal" - but at much, much higher prices. (Sometimes this already existed and simply continued; sometimes not). For the relatively less well off, technology provides better products for equal or less cost. For the very well off, it makes little difference. But there is a range in the middle who actually lose ground. We are seeing a similar effect in these library interfaces. For the vast majority of people, who rarely use the library systems and have no need to do anything sophisticated when they *do* use them, they are a clear step forward. Those people who are "wealthy" by virtue of having special access and knowledge at worst break even, and often gain. But there are those in the middle for whom the new technologies are a step backward. Library systems are not alone - those of us who, for example, are used to writing command files or shell scripts to accomplish sophisticated things find GUI interfaces frustrating. More and more systems are "sealed" - at least Mr. Kraft's friend in the library computer center could give him access to a low-level interface. What happens when the only access is through a Web server that no one can log onto? You get the services it chooses to give you, period. -- Jerry ------------------------------ Date: Thu, 20 Apr 1995 08:58:49 -0500 (CDT) From: riddle@is.rice.edu (Prentiss Riddle) Subject: Risks of online documentation I've long been a bit disturbed by the trend toward distributing software without documentation, instead referring the user to online documentation at a WWW site. Here is an example of how this arrangement can go wrong: Forwarded message: > From: efrank@ncsa.uiuc.edu (Elizabeth Frank) > Date: Tue, 18 Apr 1995 12:54:42 -0500 > To: www-security@ns2.rutgers.edu > Subject: re:ncsa security problems > > A new version of 1.3 with several security patches was > released last week. (version httpd_1.3R+ on our ftp server, > ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd) > > Unfortunately, hoohoo.ncsa.uiuc.edu (where our documentation > is located) was hit by lighting and will not be back in > service for a couple of days. This only affects our documentation, > the patched code is on the ftp server which is still working. Note that there is a mirror of the NCSA documentation at http://www.vtls.com/docs/, but it is not clear that either VTLS or NCSA have made a commitment to keep the mirror up to date (nothing at the VTLS site mentions version httpd_1.3R+). This highlights another risk of online documentation: without a careful versioning scheme, it is easy to find oneself fetching documentation for a different version of the software than the code at hand. -- Prentiss Riddle riddle@rice.edu -- Systems Programmer and RiceInfo Administrator, Rice University ------------------------------ Date: Thu, 20 Apr 1995 11:36:02 -0400 From: shapterd@JSC.MIL Subject: Risks of online catalogs Cliff Stoll makes an excellent critique of online catalogs in his new book _Silicon Snake Oil_. He enumerates many of the criticisms that contributors to RISKS have discussed. I recently ran into a problem with the online catalog for the library where I work. Asking to see the card catalog, I was told that it was 2-3 years out of date. The online catalog that replaced it accessed classified information and was therefore unavailable for general use. The librarian had to perform the search for me. Since I was looking for a specific book, it was not a problem. On the other hand, if I was doing more general research, I would have been stymied. Doug Shapter shapterd@jsc.mil | dps@kryten.atinc.com ------------------------------ Date: Tue, 18 Apr 1995 15:19:15 -0400 From: David Karr Subject: Computer-controlled electrocution (RISKS-17.06) People seem upset by the use of a computer to control an electric chair. While I agree that electrocution is horrifying, nobody has identified the computer-related risk. The claimed "risk" seems to be that computers and other electronic devices are being used to kill. But how do the inventors of those gadgets feel about the fruits of their labor being used by military forces? The obvious actual risk is that the computer might make more mistakes than human executioners, or might make worse ones. But the human executioners apparently already have a record of botched executions, so a proper assessment would have to weigh the risks on both sides. Of course a better solution might be to do away with electrocutions altogether, but that debate doesn't concern the use of computers. -- David A. Karr (karr@cs.cornell.edu) ------------------------------ Date: Wed, 19 Apr 1995 13:26:48 EDT From: lao@SEI.CMU.EDU (Lorrie Orndoff) Subject: 4th Conference on Software Risk * CALL FOR PARTICIPATION * * 4th Conference on Software Risk * * Theme: Current Successes and Future Directions * * November 6-8, 1995 * * Monterey, California * You are invited to participate in the 4th SEI Conference on Software Risk, November 6-8, 1995, in Monterey, Calif. The conference will include plenary sessions, formal presentations, invited panel discussions, birds-of-a-feather (BOF) meetings, and SEI Risk Program tutorials. Vendor exhibits will also be offered. * Theme * The theme of the conference is Current Successes and Future Directions. Significant progress in the development and application of software risk management techniques by government agencies, contractors, and vendors has occurred since the 3rd SEI Conference on Software Risk. We ask you to share your field experiences, results, and lessons learned from using and applying these techniques. We request presentations and BOF topics that include: * Applying Technical Performance Measurement to risk management * Measuring the return on investment in risk management: quality or cost * Making informed decisions in conditions of uncertainty * Learning from sharing risks across domains * Adapting existing risk management methods to your organizational culture * Managing people: risk takers and risk avoiders * Managing the risks of using COTS * Participation options * Presentations - individuals or teams interested in making a 45-minute presentation (including questions and discussions) must submit a 2000 to 3000 word abstract and a brief biography. Abstracts must describe, not just list, the topics covered. Preference will be given to submissions that demonstrate results of the application of risk management in software development projects. Birds-of-a-feather - individuals or teams interested in conducting a two-hour BOF discussion Tuesday evening must submit a description (including an outline of the topics covered) and a brief biography. Exhibitions - organizations or individuals interested in exhibiting their risk-related products and services or experimental tools must contact Carol Ulrich for more information. * Important dates * June 23, 1995 Extended abstracts and BOF descriptions due July 17, 1995 All accepted presenters have been notified September 11, 1995 Camera-ready copy of final abstract, slides, and BOF materials due * Benefits to participants * Individual presenters or presentation teams are entitled to one waived registration fee. Birds-of-a-feather leaders will be provided with a classroom setting; the SEI will reproduce materials for attendees. Exhibitors may have the opportunity to present a 10-minute overview of their risk-related products and services or tools to the conference attendees prior to the exhibit. * Send submissions to: * Carol Ulrich, Conference Chair, Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213 Phone 412 / 268-3624 FAX 412 / 268-5758 Internet cu@sei.cmu.edu [Lorrie Orndoff, Administrative Assistant, Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA 15213 Phone 412 / 268-3098 FAX 412 / 268-5758 Internet lao@sei.cmu.edu] * Program committee * Barry Boehm, USC Center for Software Engineering Robert Charette, ITABHI Corporation Richard Fairley, Software Engineering Management Associates, Inc. Yacov Haimes, University of Virginia Center for Risk Management of Engineering Systems Ronald Higuera, SEI Richard Murphy, Deputy Chair, SEI John Salasin, ARPA Carol Ulrich, Conference Chair, SEI The SEI is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.07 ************************ 24-Apr-95 21:47:40-GMT,31636;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA27669 for ; Mon, 24 Apr 1995 17:47:38 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA24990 for ; Mon, 24 Apr 1995 17:47:30 -0400 Received: from chiron.csl.sri.com ([192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id RAA20582 for ; Mon, 24 Apr 1995 17:47:04 -0400 Received: by chiron.csl.sri.com id AA28302 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Mon, 24 Apr 1995 14:35:36 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 24 Apr 95 14:35:35 PDT Subject: RISKS DIGEST 17.08 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 24 April 1995 Volume 17 : Issue 08 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Patched software threatens $26b federal retirement fund (Ed Borodkin) Church Cordless Phone Abused (Mich Kabay) Hollywood and Hackers (Mich Kabay) FTC Warns Of High-Tech Swindles (Mich Kabay) Floating-Point Time (Robert J Horn) Re: Barcode provides picture of burglar (Elizabeth D. Zwicky) Defamation by E-mail (David Dixon) Digital libraries and the great library at Alexandria (George McKee) Police use of "EMP" weapons? (Laurence R. Brothers) Parachute Automatic Activation Devices (Barry Brumitt) RISK of using MIME quoted-printable encoding (Hans Mulder) Extension of Registration for Security and Privacy (Catherine A. Meadows) Mathematics of Dependable Systems (Victoria Stavridou) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 20 Apr 95 14:15 EDT From: Ed Borodkin Subject: Patched software threatens $26b federal retirement fund The following, from the 17 April Government Computer News, highlights the risks from inadequate configuration control: "An audit of the $26 billion federal employees' Thrift Savings Plan found that ineffective control of software development has left the plan vulnerable to processing interruptions and may have compromised its data integrity." The article notes that the audit found: "- Between 1990 and 1993, more than 800 changes were made annually to the software. "- About 85 percent of 1993 updates, mandated or emergency changes, bypassed upfront quality assurance database testing. "- Comprehensive quality assurance testing was rarely performed. "- Six programmers, 17 percent, accounted for more than 40 percent of all 1992 and 1993 TSP software changes, for which there was little documentation." Ed Borodkin ------------------------------ Date: 23 Apr 95 09:26:03 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Church Cordless Phone Abused Irish church discovers hot line to sex service (Reuters, 13 Apr 1995, via CompuServe's Executive News Service) DUBLIN, April 13 (Reuter) - A remote Irish Roman Catholic church ran up an 800 pound ($1,300) bill to a telephone sex service, but the local cleric says none of his priests was involved. The article explains that someone stole dial tone from the cordless phone and placed the calls from outside the church. The cordless phone is no longer on line. The church had to pay the phone bill. M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC) Director of Education, Natl Computer Security Assn (Carlisle, PA) [Some LISP-hacker outside the church said, "Let us play?" PGN] ------------------------------ Date: 23 Apr 95 11:50:36 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Hollywood and Hackers Starring Gene Hacker, Sissy Cyberspacek; Hollywood Has Plugged Into Computers, and Entertainment May Never Be the Same (Kara Swisher, Washington Post, 23 Apr 1995, via CompuServe's Executive News Service) What do you get if you cross Hollywood with Silicon Valley? Siliwood? Last summer, Keanu Reeves and Sandra Bullock romanced each other as they foiled terrorists in the blockbuster action film "Speed." But this year, the two sex symbols are starring in big-budget movies cozying up to computer chips. Tinseltown is churning out a slew of cyberspace films and television shows built around people and computers. The slate of offerings grows daily, as the industry's creative minds focus on making the Internet worldwide network of computers thrilling, the illegal exploits of a notorious hacker gripping and hard disks sexy. The author explains that Hollywood can't resist taking advantage of the growing media hyperbole explosion about cyberspace. Some of the upcoming releases to watch [out] for: ..."Johnny Mnemonic," based on the William Gibson novel about a high-tech courier -- played by Reeves -- with a memory chip embedded in his head. Columbia Pictures Entertainment Inc.'s "The Net," ... will star Bullock as a shy computer systems analyst tossed "headlong into the middle of a murderous web of corruption and conspiracy" after she takes her keyboard where it shouldn't go. United Artists Entertainment Co. in the fall will release "Hackers," which is being flacked as a "cyberpunk thriller" whose protagonists have "awesome power at their fingertips." Walt Disney Co. reportedly is developing "f2f (face to face)" about an on-line serial killer. Fox Television recently launched "VR.5" and "Sliders," whose heroes are sexy computer geeks. It seems John Markoff is deluged with requests for movie rights to his forthcoming book about Kevin Mitnick. [Comments from MK: Oh, good, just what we needed: "Mommy, mommy, I wanna grow up to be like Kevin Mitnick!" Readers of RISKS and participants in the NCSA Forum on CompuServe may want to limber up their typing fingers and get ready to protest the glorification of criminal hackers that will likely be part of Hollywood's portrayal of people like Mitnick. It would be useful to be in the early showings of the films and write reviews for newspapers countering the errors of fact and emphasis we are likely to see.] M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC); Director of Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: 23 Apr 95 11:50:58 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: FTC Warns Of High-Tech Swindles FTC Warns Of High-Tech Swindles; Agency Gets Restraints Against 3 Companies (By Sharon Walsh, Washington Post Staff Writer, Washington Post, 21 Apr 1995, via CompuServe's Executive News Service) When Baptist youth minister Chris High of Tuscaloosa, Ala., put his inheritance into communications technology, he thought he was getting in on the ground floor of a fast-growing industry. He didn't know it is also the fastest growing area for fraudulent investment pitches. Key points from the article: o Federal Trade Commission (FTC) reports tripling in complaints about scams related to wireless licenses: 195 complaints in 1994 vs 63 in 1993. o Criminals run telemarketing operations sucking investments from victims; spend money on lavish lifestyle and more telemarketing, leaving little for licenses and equipment. o Most victims will lose their investments; total of $33 million stolen so far. o Beware of investment opportunities touting mobile radio, digital radio, wireless TV data interchange, interactive video and data services (IVDS). o Some of the criminals even call their victims back "and offer to help get lost money back -- for a fee. These "recovery room" scams are up 400 percent over the last two years, according to the FTC. o The three cases announced by the FTC yesterday were: Chase McNulty Group Inc. of St. Petersburg, Fla., and its officers allegedly offered consumers partnerships in IVDS licenses for $5,000 to $6,000. The FTC contended that the majority of the money the group collected was going to the marketers, not to buying licenses. .... Digital Interactive Associates Inc. and Market Logistics Group Inc. of Florida and Colorado, which had the same officers, allegedly exaggerated the cost of the licenses for which they raised money and used the money for themselves, the FTC said. The agency also said they failed to disclose that it would take millions of dollars more to build an IVDS system. .... Satellite Broadcasting Corp. of Irvine, Calif., and its officials falsely represented that it was applying for a license and had the rights to distribute direct broadcast satellite television programming in Georgia, the FTC said. The company solicited investments of $10,000 to $25,000, the commission said. .... Consumers with complaints should call the national telemarketing fraud hot line at 1-800-876-7060. M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC); Director of Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Sun, 23 Apr 1995 22:02:42 +0059 (EDT) From: Robert J Horn Subject: Floating-Point Time The opponents of floating-point representation for time have done an insufficient analysis. About twenty years ago I was part of a research group doing extensive time series analysis of weather and related data. We needed a good way to represent time. Fortunately we had a few astronomers on the team, so time was reasonably well understood. We chose "second of century", using a double precision floating point representation. Analysis showed that this would preserve millisecond accuracy for the span of interest. (Actually for all of recorded history and more.) Since we usually were satisfied with one minute accuracy this seemed sufficient. There was a brief debate about using a better time base, but 12:00:01 AM GMT, 1 January, 1901 was easy to explain to everyone. There are a few applications that need better than millisecond precision, but for most of the worlds applications double precision floating point will provide enough precision for the next few millenia. (A simple test for those who are unsure about their needs. Do you compensate for the variations in the rate of the Earth's rotation? If not, you probably don't need millisecond accuracy.) This notation had some interesting side effects. At the time, floating point turned out to be somewhat faster than 64-bit integers due to a quirk of hardware. It also led to excellent compatibility with the other time series processing. Time was just another well behaved variable. This notation eliminated a lot of the mistakes made by the typical programmer who is ignorant of traditional time notations and their problems. There could have been some round-off issues, but we rarely did any arithmetic other than addition or subtraction of two times, where millisecond accuracy is maintained. It even led to a simple notation for interval time span data, e.g. "0.01 inches of rain fell between 1633 and 1647 on ...", which is how many meteorological measurements are made. The difficult problems were in translation to and from local. The most severe problem was the inherent ambiguity of local time in recent decades. There are two true times corresponding to each time in the one hour of overlap when Daylight Savings shifts back to Standard. Correctly resolving this ambiguity was always a headache. Fortunately most professional measurements have been recorded in UTC, or GMT before UTC was defined. A word of caution, double precision floating point is suitable for an internal representation of UTC, or "absolute" time. You have to do your own analysis if you are interested in timing relative to some event. Rob Horn rjh@world.std.com P.S. The turn of century problem has made The NY Times. It may be so widely hyped that almost all the problems are fixed by the time it comes. [Hmm! According to you, it comes at 1/1/01 rather than 1/1/00. I wonder who agrees with that! PGN] ------------------------------ Date: Thu, 20 Apr 1995 10:04:10 -0700 From: zwicky@pterodactyl.corp.sgi.com (Elizabeth D. Zwicky) Subject: Re: Barcode provides picture of burglar (Burns, RISKS-17.06) > a barcode sticker was still attached to the pickaxe. Talk about risky ways of going about things! Store barcodes don't identify individual items. All you can determine from the barcode is that the hardware store sold *a* pickaxe. You *might* know what hardware store sold it (if it was a store barcode and not applied by the pickaxe manufacturer), but you can't know which pickaxe it was. Fundamentally, you'll only ever see barcodes that can identify a particular instance if there would be something else that would identify that object. For instance, truck axles have individual barcodes; those simply repeat the individually tracked serial numbers truck axles have always had. Products sold by weight, like cheese and meat, may also have individual barcodes that incorporate the weight. Normally, the barcode doesn't even incorporate all the available information about the object. It's a pure product code. A can of green beans has a barcode label that says it's a can of green beans, and the register tape will reflect that. The same can also has a lot number, so if you drop dead after you eat it, the canning company has some way of figuring out what other cans of green beans might be poisonous. The lot number is *not* encoded in the barcode, and you wouldn't be able to find it from the register information, because the grocery store really doesn't care. I assume that the article is leaving out a lot of information (for instance, that the pickaxe had the name of the hardware store on it, too, and the hardware store only sold one pickaxe recently). But I'm always amazed how willing people are to present barcodes as magic identifiers, and believe that they function that way. Perhaps it's because they look funny and aren't readable by eye? Elizabeth D. Zwicky zwicky@corp.sgi.com ------------------------------ Date: Fri, 21 Apr 95 08:42:50 BST From: David Dixon Subject: Defamation by E-mail Thursday April 20, UK Kathy Marks in the Telegraph reports that a large supermarket chain has paid substantial damages to a policeman whose description was circulated between stores by electronic mail after he complained about a joint of meat. Apparently, the E-mail message was headed "Refund fraud -- urgent, urgent urgent" and gave an account of his complaint, together with details of his appearance and car registration. The policeman only found out about the message when he visited a local branch of the store to give advice about security. A friend who works there showed him a print out of the message on an internal noticeboard. The policeman is quoted: "...If this had got out unchecked it could have done me serious professional harm. I am in a position of extreme trust and there has got to be no doubt...that I am 100 percent trustworthy". His lawyer said that the out-of-court settlement amounted to "thousands, rather than hundreds" (of pounds). --- David ------------------------------ Date: 21 Apr 1995 04:26:57 GMT From: mckee@starbase.neosoft.com (George McKee) Subject: Digital libraries and the great library at Alexandria The April issue of the Communications of the ACM is all about Digital Libraries. More than one of the authors there alluded to the great Library that was founded in Alexandria by the Egyptian king Ptolemy I. One group even calls its project "alexandria". This library was one of the wonders of the ancient world; it contained more than 700,000 volumes at its peak. The CACM writers are optimistic that digital technology can be as much of a monument to the advancement of human knowledge as the Alexandrian Library was in its day. The other major topic of April's CACM issue is the ACM's new Electronic Publication Plan, which details a carefully thought-out set of rules for copying and citation of electronic documents and the status of hyperlinks to World Wide Web documents as citations (the ACM's position) or plagiaristic quoted inclusions (they rejected this view). The transmission of an electronic document from archive to reader poses important questions about the nature of copying to authors and publishers who expect royalties from the sale of their work, which the ACM appears to have succeeded in balancing against the cultural and technical difficulties of applying a pay-per-use paradigm to information resources released onto the Internet. But the ACM policymakers appear to have missed one of the great lessons of the Alexandrian Library. According to my encyclopedia (*), the library was kept in two buildings: one of these was a famous museum, which was destroyed by fire during the siege of Alexandria by Julius Caesar. The other part of the library was kept in the temple of Jupiter Serapis, where during the reign of Theodosius the Great, "a mob of fanatic Christians, led on by the Archbishop Theophilus, stormed and destroyed the temple, together, it is most likely, with the greater part of its literary treasures, in 391 A.D." The Alexandrian Library had endured for over 700 years, yet when it was destroyed, it was an enormous loss to humanity since its contents existed in only single copies, because of the difficulty in duplicating them. Some historians have gone as far as crediting its destruction as a principal cause of the Dark Ages that afflicted Europe for the next thousand years. The ACM Electronic Publishing Plan does not propose any measures to assure the survivability or integrity of electronic publications against disaster or terrorism. Along with the ease of copying an electronic document comes great ease in modifying its content undetectably. Perhaps a greater risk comes from simple financial pressures. Electronic documents must be maintained on functioning computer systems. When funds run short, the temptation will be enormous to purge infrequently-accessed documents from the database in order to reduce maintenance costs, or to forgo copying them to new media when upgrade time arrives. I wrote the thesis for my Master's degree as an electronic document. I still have the original, but it's on a PDP-10 format DECtape. Where can I find a machine capable of reading this tape twenty years later? What's to prevent this from happening to the contents of entire digital libraries? George McKee mckee@neosoft.com +1 713 890 8122 (*) "Alexandrian Library" (1922) Encyclopedia Americana, Albany, N.Y. volume 1 [A to Annuals] p.373. ------------------------------ Date: Fri, 21 Apr 1995 10:09:25 -0400 From: quasar@bellcore.com (Laurence R. Brothers) Subject: Police use of "EMP" weapons? The March issue of Security Management magazine reports that manufacturers are testing some sort of nonlethal weapon designed to deliver a "high frequency pulse" that would disable any unshielded electronic circuitry hit by the beam -- with the suggestion this would be used somehow by the police. Presumably this would be used in a car chase to take out a car's control circuits, possibly disabling its electronic ignition. I naively imagine a car's electronics to be fairly well shielded -- the steel shell, the engine block itself, etc. -- and so this may be quite a powerful pulse (perhaps a microwave-savvy reader can comment?). The article only has a paragraph on this weapon and doesn't explain the technology. I speculate about a police-car-mounted maser or perhaps just a conventional microwave transmitter of sufficient power. The risks here seem fairly obvious. First of all, risks in the actual effect of the weapon during a legitimate high speed chase -- can there be any guarantee that it will only stall the engine? Supposing it takes out the power steering or activates the air-bags or does some other bizarre and dangerous thing? Then there is the question of the precise focus of the beam, and whether it might affect nearby vehicles. Presumably there is no "tracer" effect, so the shooter doesn't know if the target was hit or not. Secondly, assuming that it is a good weapon, i.e., it has good targeting, only has the effect of stalling the engine or simply reducing engine performance, etc. then it seems there would be little to prevent any random microwave-hacker from doing the same thing, relatively indetectably, especially if the weapon consists solely of a powerful microwave transmitter. Oh, as a side note, the article mentions that the device would be able to destroy any sort of computer equipment.... Laurence R. Brothers quasar@bellcore.com ------------------------------ Date: Fri, 21 Apr 95 11:15:02 EDT From: Barry Brumitt Subject: Parachute Automatic Activation Devices (AAD's) Modern sport parachute systems are frequently equipped with an automatic activation device on the reserve parachute that will initiate deployment of the reserve if the person descends through a certain altitude whilst exceeding a certain velocity, i.e., if you're low and falling fast (no parachute!) it will initiate deployment of your reserve. Currently, the most popular AAD (and by far the best made technically) is the CYPRES. When turned on, it performs a self check that tests the repeatability of the pressure sensor (to compute altitude), the integrity of the system, as well as reporting the battery voltage and testing the voltage on a dummy load. The CYPRES can activate the reserve via a pyrotechnic cutter, which, when current is applied, fires, and cuts a crucial bit of line which allows the reserve container to open. The CYPRES has only one button, and the self-test is performed each time it is turned on, with feedback to the user of the success or failure of the test. CYPRES mandates that batteries be replaced every 500 jumps, 2 years, or when the self-test fails with a battery-low code, whichever comes first. Recently (last two weeks), a CYPRES activated (i.e., the jumper was low and falling fast), but failed to cut the loop,and the skydiver hit the ground with no parachutes out. Current reports indicate that: 1) The selftest was succeeding 2) Battery voltage *as reported by the self test* was in the moderate to high range (6.2 of 5.8-6.3v) 3) The batteries were 4 years old (2 years beyond their lifetime!) 4) The unit functioned correctly when tested in a chamber with a new battery. 5) The battery apparently lacked sufficient power to heat the wire to ignite the charge A full report by the manufacturer has *not* been issued, so it is possible that there are errors in this report, however, it is correct the best of my knowledge. The question: Does violating the *written* guidelines constitute a situation in which the self-test can *fail* to report the correct status of the unit -- and should the user be aware of this failure mode? The risk: if you build in a self-test that does not in fact cover all failure modes, you are putting the user at increased risk, as people will rely on the electronic self-test, rather than the written instructions on how to use the device. In a life-or-death situation, it is RISKy to provide a self-test that produces ambiguous results. Caveat: CYPRES has been designed to be as user friendly and reliable as possible. In the 3 years since it has been widely used in the sport, CYPRES's has been responsible for saving approximately 50 jumpers who would likely have otherwise died (true positives). There have been no innapropriate activations (i.e., false negatives). There have (obviously) been millions of uses where the device has not fired, and it wasn't supposed to anyways (true negatives). This is the first incidence of a false positive, where the unit should have fired, and failed to perform. Conclusion: Read your manuals, and perform scheduled maintenance even *if* the self test might imply that it isn't necessary. Barry Brumitt, D-15427, Skydiving Instructor AFF/SL '95, CYPRES equipped ------------------------------ Date: Fri, 21 Apr 1995 13:43:35 +0200 From: hansm@win.tue.nl (Hans Mulder) Subject: RISK of using MIME quoted-printable encoding In RISKS-17.07 James@prognote.demon.co.uk (James G Henderson) wrote: > [...] that Notre Dame's organ is not suitable for concerts following >a two year restoration costing =A31.3 million (Pounds Sterling) [...] ``=A31.3 million Pounds Sterling'' sounds like quite a lot of money. On closer inspection, the restoration cost was only 1.3 million: `=A3' is the MIME quoted-printable encoding for the Pound sign (a script L). The theory behind MIME quoted-printable encoding is that it leaves 99% of the text alone, thereby allowing users with older software to grasp the essence of the message. That may be true, but it also means that the recipient of such a message will not be aware that the message he read was almost, but not quite, the same as the message the sender sent. Incidentally, MIME quoted-printable provides three codes for currency signs and all three end in a digit: the dollar sign is `=24', pound is `=A3', and yen is `=A5'. Hans Mulder hansm@win.tue.nl ------------------------------ Date: Fri, 21 Apr 95 16:46:15 EDT From: meadows@itd.nrl.navy.mil (Catherine A. Meadows) Subject: Extension of Registration for Security and Privacy Originally, the deadline for registration for Security and Privacy was today, April 21. However, we still have a number of openings still available, and we have extended the registration period through May 5. Instructions for registration are in the advance program and registration form. Cathy Meadows Program Co-Chair [The full program and registration information are included in RISKS-16.80. Please contact Cathy for further information. PGN] ------------------------------ Date: Fri, 21 Apr 1995 16:34:10 -0700 From: Victoria Stavridou Subject: Mathematics of Dependable Systems (conference announcement) MDS 95: 2ND CONFERENCE ON THE MATHEMATICS OF DEPENDABLE SYSTEMS 4-6 September 1995, University of York, England Sponsored by Nuclear Electric THE INSTITUTE OF MATHEMATICS AND ITS APPLICATIONS CALL FOR PAPERS (extended deadline) AND APPLICATION FORM The construction of dependable systems, by which we mean systems providing high levels of reliability, availability, safety and/or security, is a problem of considerable concern to both providers and users of information processing systems of all types. Historically, different aspects of system dependability (e.g. reliability and security) have been studied quite independently, albeit that many of the goals are similar. For example, the notion of certifying functionality assurance levels applies equally to reliable systems and secure systems. In addition, users will often require some combination of security and fail-safe operation. The purpose of MDS 95 is to consider the mathematical aspects of the provision of dependable systems, one goal being a comparison and possible unification of mathematical techniques for providing safe, reliable and secure systems. A number of different mathematical approaches have been taken to the overall problem, including probabilistic/statistical reasoning, formal models of safe, secure and reliable systems and logics of authentication and access control/privilege delegation. Papers on all these areas are solicited, the unifying theme being the application of mathematical techniques to the overall dependability problem. Hence papers will be particularly welcome that cross-fertilise the application domains. The conference will consider dependability for both hardware and software systems. PROGRAMME AND PROCEEDINGS: The conference will consist of three days of presentations by contributing authors. The programme will also include invited lectures by prominent researchers and practitioners in dependable systems theory and practice. Time will be made available for discussions. A digest of papers will be available to participants during the meeting and the proceedings will be published after the conference. PANEL DISCUSSION: The Panel will be chaired by Dr B Wichmann (National Physical Laboratory and The Open University) and led by Professor J Rushby (SRI). Other members will be announced later. The main topic will be the contribution of Formal Methods to certification. INVITED SPEAKERS: Monsieur P Chapront (GEC Alsthom, France), Professor J Knight (University of Virginia, USA), Professor B Littlewood (City University, UK), Professor D L Parnas (McMaster University, Canada), Professor F Piper (Royal Holloway, University of London, UK) and Dr C T Sennett (Defence Research Agency, UK). SUBMISSIONS: Five copies of complete papers (in English) should be sent to Mrs Pamela Bye, Conference Officer, The Institute of Mathematics and its Applications, 16 Nelson Street, Southend-on-Sea, Essex, SS1 1EF, England (Tel. +44 1702 354020, Fax +44 1702 354111, Email imacrh@v-e.anglia.ac.uk) by 17 May 1995. [...] [For the rest of the announcement, submission standards, registration info, etc., contact Victoria Stavridou . PGN] PROGRAMME COMMITTEE: Programme Chair : V Stavridou (Royal Holloway, University of London), D Gollmann (Royal Holloway, University of London), M Ingleby (British Rail Research), J Jacob (University of York), N Jefferies (Vodafone Ltd), B Littlewood (City University), R Shaw (Lloyd's Register), B Wichmann (National Physical Laboratory). ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.08 ************************ 26-Apr-95 20:52:53-GMT,28992;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id QAA28476 for ; Wed, 26 Apr 1995 16:52:34 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id QAA09919 for ; Wed, 26 Apr 1995 16:52:31 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id QAA09982 for ; Wed, 26 Apr 1995 16:52:12 -0400 Received: by chiron.csl.sri.com id AA00546 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Wed, 26 Apr 1995 13:41:45 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 26 Apr 95 13:41:44 PDT Subject: RISKS DIGEST 17.09 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Weds 26 April 1995 Volume 17 : Issue 09 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Incorrect phone tracing lands Bostonian in jail (Michael J Zehr) Risks of discontinuous speech (Daniel P. B. Smith) Portable phone ban in British hospitals (David Wadsworth) EMPathic Traffic (Peter Wayner) Use of Lottery Security System to assist in fraud (Mike Wilmot-Dear) "Outrage! of the Month" by National Taxpayers Union Foundation (Stan Niles) Re: Risks of Keyword Systems (Mark Fisher) Re: Floating-Point Time (Robert J Horn, PGN, Geoff Kuenning) Re: 11 B-boards dismantled in Montreal (JdeBP) Re: Digital libraries (Andrew Kass) Re: Risks of Library Catalog Keywords (Patricio Poblete) The risk of being ashamed of the uses made of your work (John Lupien) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 26 Apr 95 12:00:35 -0400 From: tada@MIT.EDU (Michael J Zehr) Subject: Incorrect phone tracing lands Bostonian in jail On the day of the bombing of the federal building in OK, some federal buildings in Boston were evacuated due to bomb scares. At least one of the scares was the result of a prank phone call. The police very quickly arrested an 18-year-old man, who allegedly placed the call. The police have been waiting for several years for a new phone tracing system. Currently they have to call NYNEX (the local phone company) and initiate a trace while a caller is still on the line. The new system (scheduled to be put into place hopefully this year) will let the police trace the call automatically. While preparing documents for trial, NYNEX discovered that a technical operator had transposed a trunk number during the trace, and thus they had traced the call to the wrong phone number (perhaps traced the wrong call to the right phone number?). The accused was released, NYNEX made lots of apologies including offering a full scholarship with no strings attached, and the person who made the actual call remains at large. Some points to note: The current tracing procedure requires manual entry of trunk numbers and has a very clear failure mode.... ... but NYNEX had enough recorded information to later on determine that a mistake was made. (Well done!) When the new system is installed, the traces will be entirely automatic. They might be more reliable, but it's unclear if there will be an audit trail in the case of failures. (It sounds like just a software system -- if there's a bug in the algorithm, how will the algorithm detect it?) (If there are ways to spoof the system used to identify the phone number, that leads another set of problems.) There's always the risk of "but the computer says" syndrome. -michael j zehr [Also noted by Mark Kruse and Nachum Shacham , whose news excerpt noted that the mistake was discovered when police requested the necessary paperwork showed the wrong number. (In law enforcement matters, computer records generally have to be backed up by original noncomputer records.) PGN] ------------------------------ Date: Tue, 25 Apr 1995 17:55:29 -0400 From: dpbsmith@world.std.com (Daniel P. B. Smith) Subject: Risks of discontinuous speech ComputerWorld 15 Apr 1995 mentions that some early adopters of speech recognition software are starting to develop voice problems. In the article, the vendors minimize the seriousness by suggesting that inexperienced users tend to talk too loud, and that the problem can be overcome by voice training. However, it occurs to me that my singing instructors have mentioned that interrupting a vocalization is a definite source of stress to the vocal cords; part of voice training consists of learning to keep as even a flow as possible. I suspect that speaking isolated words with distinct pauses between them is a very unnatural kind of voice activity and that we have not heard the last of this problem. Daniel P. B. Smith dpbsmith@world.std.com ------------------------------ Date: Wed, 26 Apr 95 14:51:27 GMT From: dwadsw@etna.demon.co.uk (David Wadsworth) Subject: Portable phone ban in British hospitals Our local paper 'the Nottingham Recorder' has the following item about portable phones: Mobile phones have been banned from hospitals throughout Britain following a police probe into more than 100 deaths in an intensive care unit at Worksop's Bassettlaw General Hospital. A Department of Health circular has been sent to every hospital in the country warning 'The department has received reports of mobile and cellular telephones interfering with the operation of medical devices Portable, cordless and cellular telephones should not be used close to patient monitoring,infusion or life support equipment because interference may affect their normal operation with potentially serious patient consequences....... Patients, contractors and other visitors should be discouraged from using such telephones in hospitals.' The risks seem to be obvious. I also wonder that apparently hospital staff are to be banned from using these whereas everyone else is only to be `discouraged'! David Wadsworth dwadsw@etna.demon.co.uk ------------------------------ Date: Tue, 25 Apr 1995 01:21:45 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: EMPathic Traffic (Re: Brothers, RISKS-17.08) Laurence Brothers writes in RISKS-17:08 that some are investigating letting the police use high-powered electro-magnetic pulses to crash a getaway car's computer chip and bring it to a halt. What if the EMP destroyed those incriminating computer records stored on the laptop on the front seat? Or crashed the computer chip running that crook's pacemaker? Every RISKS reader should have EMPathy for this. [Pacemaker risks also noted by robert_rose@VNET.IBM.COM, rjwells@undergrad.math.uwaterloo.ca (justin wells), Mike Haertel , and tada@MIT.EDU (michael j zehr), as well as unilink@online.rednet.co.uk (David Alexander) -- who noted hearing aids, electronic drug-infusing devices, electronic locking devices, alarm systems, security cameras, radios, etc., and the rampant opportunities for malicious misuse. PGN] ------------------------------ Date: Wed, 26 Apr 95 15:53:01 BST From: mikewd@leica.co.uk (Mike Wilmot-Dear) Subject: Use of Lottery Security System to assist in fraud There has been some publicity recently here in the UK about an attempted fraud against the "Instant Win" version of our National Lottery. Whilst the current alleged fraud is very crude and was unlikely to not get spotted it does appear to show are rather classic case of a computerised security checking system designed for *verification* which can be used to *obtain* information as well as simply verifying it. The "Instant Win" lottery makes use of scratch cards, purchased from retail outlets, which when the foil covering is scratched off reveal whether the card is a winner and if so for how much. For smaller amounts the winners can collect their winnings immediately from the retailer. (Larger amounts have to be claimed from the lottery company directly). In order to prevent fraud, as well as the winning amount the card also has on it (again concealed under the foil) a security code number which can be used to verify a winning card is genuine. This is done by the retailer entering the security number into a computerised terminal supplied by the lottery company which apparently not only displays if the ticket is a winner but also the amount of the win. The current alleged scam is said to work by the retailer just scratching off the foil above the security number and then using his terminal to see if the card was a big winner. If not he attempted to sell it to an unsuspecting punter and hope they didn't spot the small bit already scraped off! Now obviously the current scam is rather crude and not very likely to succeed as it only requires one suspicious punter to tip off the lottery company. But it does appear to demonstrate what would seem to be a classic flaw in a security system designed just for verification in that rather than requiring input of both the code number and the winning amount and then simply giving a Good/Bad response it actually gives out information in response to only one input! Whether there are actually any practical ways of exploiting this flaw, it does seem surprising that a lottery system , surely something giving a high priority to effective security should have an obvious flaw like this. After all it is a close parallel to the classic flaw in a computer login system that would tell you that a username was invalid before asking for a password, hence allowing a hacker to identify valid usernames. Surely no-one would dream of implementing such a vulnerable system these days... Mike ------------------------------ Date: Mon, 24 Apr 1995 09:48:56 -0600 (MDT) From: Dr Stan Niles Subject: "Outrage! of the Month" by National Taxpayers Union Foundation In "Capital IDEAS" (Vol. 3, No. 6, April 1995) a publication of the National Taxpayers Union Foundation, there is an article on page 4 entitled "Outrage! of the Month" which is actually composed of three outrages. The third outrage relates to programming computer dates. This subject has been discussed on RISKS before so I'll just give the text of the outrage. Begin quote. BLIND DATE The federal bureaucracy's computers are about to be dragged kicking and screaming into the 21st century. It seems the original computer program designers, many of whom are now dead or retired, never gave much thought to allowing government software to read dates beyond December 31, 1999. Computers could mistakenly think, for example, that a date entered as "4/15/00" meant April 15, 1900, not the year 2000. Massive accounting errors could therefore become the norm, such as calculating benefit checks based on 100 years of interest instead of just one year. Data Dimensions, a computer consulting firm, estimates that "millennium conversion" could cost the federal government $75 Billion in equipment and labor to implement. A typical federal agency will need to modify up to 100 "applications" (computer programs that use dates), at a labor expenditure of up to 60,000 people-days. So far, the Social Security Administration (SSA) is the only agency to begin the task of "millennium conversion," which is expected to take SSA seven years. Do you want out of the government's costly time-warp? Stan Niles, PhD 505-678-3834 sniles@arl.mil ------------------------------ Date: Wed, 26 Apr 95 09:18:00 PDT From: Fisher Mark Subject: Re: Risks of Keyword Systems At least in the case of document retrieval, full-text indexing with stop words, word stemming, a semi-automatically generated thesaurus, relevance scoring, and relevance feedback have been shown to outperform the best manually indexed documents in retrieval accuracy and completeness. This result goes back to Gerard Salton's 1971 paper, "A New Comparison Between Conventional Indexing (MEDLARS) and Automatic Text Processing (SMART)" (CORNELLCS:TR71-115, available at [Hmm! According to you, it comes at 1/1/01 rather than 1/1/00. > I wonder who agrees with that! PGN] Who am I to argue with astronomers? They work in mathematics and FORTRAN, so counting starts with one. Therefore the first day of the first century is 1/1/00000001. C was invented later, and never really accepted by astronomers. We just moved things closer by starting at 1901. Rob Horn rjh@world.std.com [The customary convention was also commented on by jcs@zoo.bt.co.uk (John Sager), pbm1001@thor.cam.ac.uk (Paul Menage), harper@kauri.vuw.ac.nz (John Harper), ag325@detroit.freenet.org (William M. Bickham), "david (d.p.) woodman" , rjwells@undergrad.math.uwaterloo.ca (justin wells), and Greg Lindahl , an astronomer who noted "Astronomers get to go to 2 sets of turn-of-the-century parties... you nay-sayers only get to go to one." I'll be at the former, when most of the computer-related risks are likely to begin. PGN] ------------------------------ Date: Tue, 25 Apr 95 21:02:17 PDT From: "Peter G. Neumann" Subject: Re: Floating-Point Time Oh, yes, I certainly agree that the astronomers and ephemeris/almanac folks like 1/1/01 as the century start. However, because there was no year ZERO, that does not scale backwards. The first century BC clearly began on 1/1/-100, and the first millennium BC on 1/1/-1000. The only SANE way to handle this is to provide a 99-year first century; just as we have leap-years and leap-seconds, we could have a backwards leap-century. Indeed, it is just as well there were no computers in virtual-year 0000, or the religious wars would have been proven recursively unsolvable. PGN ------------------------------ Date: Tue, 25 Apr 95 13:53:39 PDT From: geoff@ficus.CS.UCLA.EDU (Geoff Kuenning) Subject: Re: Floating-Point Time (Robert J Horn, RISKS-17.08) > We chose "second of century", using a double precision floating point > representation. Analysis showed that this would preserve millisecond > accuracy for the span of interest. Sigh. There is more to time calculations than just understanding time, and there is more to numerical analysis than just the range of the mantissa. I'll try this once more, keeping it brief. This project wouldn't have used IEEE format 20 years ago, but let's proceed with the analysis under modern assumptions. The IEEE double-precision floating-point representation provides 53 bits of significance in the mantissa. Using the approximation that 2^10 = 10^3, this can be see to allow a range of about 8x10^15 in the mantissa, before bits start getting dropped. Since there are about 3x10^7 seconds in a year, or about 10^8 every 3 years, one can represent about 8x16x3 = 384 years to millisecond precision without violating that range, right? Wrong. This is true only if you represent time as integer milliseconds. Since the representation used seconds, the milliseconds were represented fractionally. There are only four millisecond values that can be represented accurately in a binary floating-point system: 0, 250, 500, and 750. ANYTHING ELSE is an approximation. This is especially true if your calculations involve any addition and subtraction of times. > Since we usually were satisfied with one minute accuracy this > seemed sufficient. It sounds like this project involved some sort of modeling of the physical world. In such cases, the loss of a few bits of accuracy may not matter, although I still think programmers ought to understand numerical analysis better than most do. But remember that the original discussion of time representation arose in the context of measuring time in computer and financial applications, where these bits can matter. > There are a few applications that need better than millisecond precision, > but for most of the worlds applications double precision floating point > will provide enough precision for the next few millennia. (A simple test > for those who are unsure about their needs. Do you compensate for the > variations in the rate of the Earth's rotation? If not, you probably don't > need millisecond accuracy.) This is both a broad and a biased statement. Here's a simple response to the simple test: I'm not dealing with astronomical phenomena, and so I couldn't care less about variations in the Earth's rotation. What I care about is whether I can query the system time, do something, query the time again, and subtract to get an accurate elapsed time. I care about not only milliseconds, but microseconds (and in a few years, nanoseconds). Now it's true that I generally deal with time in a small range. Unfortunately, the system time is represented in terms of a relatively long base interval. So I have to be able to take two times measured in years, subtract them, and get microsecond precision in my results. If the times are represented as integer microseconds, I can be sure that everything will "balance," as the accountants say. If a sloppy floating-point representation insists on giving it to me as integer and fractional seconds, things won't add up, and my papers may not get published. > There could have been some round-off issues, but we > rarely did any arithmetic other than addition or subtraction of two > times, where millisecond accuracy is maintained. But addition and subtraction are precisely the places where numerical errors are introduced! Millisecond accuracy was *not* maintained in this situation. Since you only cared about minutes, this hardly mattered, but it's still an incorrect statement. > A word of caution, double precision floating point is suitable for an > internal representation of UTC, or "absolute" time. It's only appropriate when you're doing modeling of the physical world, where you don't care about losing a few bits of accuracy in the fraction because your measurements aren't that good anyway. Double precision is a *terrible* way to model elapsed time inside a computer system. It has nothing to do with the nature of time, and everything to do with numerical analysis. Geoff Kuenning g.kuenning@ieee.org geoff@ITcorp.com http://www.cs.ucla.edu/ficus-members/geoff/ ------------------------------ Date: Mon, 24 Apr 1995 19:10:28 +0100 From: JdeBP@jba.co.uk Subject: Re: 11 B-boards dismantled in Montreal (Kabay, RISKS-17.08) Of course, we have here the canonical example of PR people (in this case the "Resource Persons" who provided this information) who really don't understand what they are saying when talking about computers. What company, for example, is "Windows 95", and what products does it develop ? Add to that the fact that products developed by Clark Development (makers of PC Board) and Mustang Software (makers of Wildcat) are *legitimately* distributable on a try-before-you-buy basis as shareware, and you have the canonical nightmare of BBS operators being forced to prove to the computer illiterate judicial process that they were perfectly entitled to make copies of such files available for download. In my experience of BBSing, I also have to suspect that some of the "products" developed by Borland, Microsoft, IBM, Novell, et al., may well have been freely distributable service fixes. All of these companies have been known to make such patches widely available for the benefit of their customers. Take one service pack, accidentally label it with the name of the product that it is a patch to, and there's an immediate source of confusion even to people who know what they are doing ... On a more light-hearted note : Why should access to information on how to successfully commit suicide be made unavailable to software pirates ? Surely those interested in stamping out piracy would applaud such a move ? Also, who would trust instructions on how to "succeed" at suicide to be reliable, when it is patently obvious that the author obviously lived long enough afterwards to write up said instructions ... ? ------------------------------ Date: Mon, 24 Apr 1995 22:38:12 -0400 From: delphi@lcs.mit.edu (Andrew Kass) Subject: Re: Digital libraries (McKee, RISKS-17.08) Have no fear, other research groups are working on this problem! The Library 2000 group at the MIT Lab for Computer Science is part of a 5 university project working on digital libraries. One of our highest priorities is replication. Data stored in a digital library system will be replicated; not only locally, but in a geographically diverse way to protect against a wide-area disaster. The replication scheme itself is transparent. If a site goes down, other sites replace it automatically. In addition, we are working on long term storage. This means persistent storage as well as moving data to the current media continually (as opposed to leaving it on a PDP-10 DECtape). However, the only media which has persistence of 50+ years which has been proven in a reliable way is film. So a possibility is to microfilm the bit patterns of digital documents as an archive mechanism. For more information on our project and some interesting papers on fault-tolerance and replication, please refer to our WWW site: . Andrew Kass, MIT Laboratory for Computer Science; Library 2000; President, MIT Eta Kappa Nu; delphi@lcs.mit.edu ------------------------------ Date: Mon, 24 Apr 1995 10:11:35 -0400 (CST) From: ppoblete@dcc.uchile.cl Subject: Re: Risks of Library Catalog Keywords (McHugh, RISKS-17.08) > ... It is impossible to get out of the system. ... My university installed recently a library system with a similar feature. Here, you need a password... to log out of the system! The password, of course, is included in the documentation handed out to users, but it is easy for casual users to be trapped by the system. Me? I just use telnet and ^]q, thanks. Patricio Poblete ------------------------------ Date: Tue, 25 Apr 1995 12:58:17 -0400 From: John Lupien Subject: The risk of being ashamed of the uses made of your work >Date: Tue, 18 Apr 1995 15:19:15 -0400 >From: David Karr >Subject: Computer-controlled electrocution (RISKS-17.06) >People seem upset by the use of a computer to control an electric chair... Some don't care. But in this age of "software reuse" and modular hardware & software components, there is a real risk here. It's the risk of having one's work put to uses of which you are ashamed, or would be if you knew about it. This risk exists in the development of any modular type of component - you don't know what the next user is going to hook it up to (a bomb, a power grid, or an incubator). There are ways to mitigate this risk, such as working on components so specialized that such use would be infeasible, but this only goes so far. A certain engineer I know of tells me of the irony of being caught by a radar speed trap after having invented a key component of the radar guns being used - it's not always the "bad guys" that make unanticipated use of the technology, and it's not always the "good guys" that invent the item being used in an unanticipated context. So there are lots of opportunities to "suffer" in this way. More to the "RISKS" point, though, the components any given engineer or inventor designs may well be coopted for other uses to which they >seem< suited, but actually are not - trying to adapt "fail-safe" control technologies to become "fail-deadly" (when "deadly" is the intent of the novel component context) brings up an entirely new face of the re-engineering complexity debate. Particularly when, as in this case, the lethality of the resulting system is intended to be highly directed, but there are people (other than the intended victim) involved in the use of the equipment. It would be hard to feel good about a fail-safe one designed into one's component if the result was that the executioner fries instead of the convict... The previous post also tried to point out that eliminating capital punishment (which would make such machinery a moot issue) is a debate not germain to RISKS. While I tend to agree with this in specific, I wanted to point out that (political/social/other) systems can be designed in ways which encourage or discourage the implementation of RISKy support structures, but this notion is rarely considered in guiding the development of social policy. Another RISK of ignoring RISKS? John R. Lupien lupienj@wal.hp.com ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.09 ************************ 30-Apr-95 23:38:37-GMT,30442;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA07313 for ; Sun, 30 Apr 1995 19:38:35 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA00101 for ; Sun, 30 Apr 1995 19:38:32 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id TAA24092 for ; Sun, 30 Apr 1995 19:38:29 -0400 Received: by chiron.csl.sri.com id AA04190 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Sun, 30 Apr 1995 16:30:52 -0700 From: RISKS Forum Sender: RISKS Forum Date: Sun, 30 Apr 95 16:30:51 PDT Subject: RISKS DIGEST 17.10 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: Status: O RISKS-LIST: Risks-Forum Digest Sunday 30 April 1995 Volume 17 : Issue 10 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Metromover inner loop back on line (Charles P Schultz) Radar-detector messages & cop-car computers (Mark Seecof) AOHell (Simson L. Garfinkel) Terrorism and telecommuting (Tim Kolar) CyberWinter: A Forecast (Richard K. Moore) Privacy directory (Simson L. Garfinkel) Re: Lotus Notes authentication protocol challenged (Charlie Kaufman) Re: Floating-Point Time (David Cline, Bill Hopkins) Re: Digital libraries (Shannon Nelson, Michael D. Sullivan) Clipper paper available for anon FTP (Michael Froomkin) Advanced Surveillance, Call for Papers (Dave Banisar) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: 28 Apr 95 08:22:57 -0600 From: CharlesP_Schultz-ECS013@email.mot.com Subject: Metromover inner loop back on line Miami's Metromover was running again Wednesday afternoon after the downtown inner loop was closed for more than two days because of "phantom" trains on the track. Trains began rolling again on the 1.9 mile inner loop at 12:19 p.m. The rest of the 4.4-mile system - an outer loop and extensions north to the Omni International Mall and south to Brickell - was not affected. Metro-Dade Transit Agency technicians attributed the problem to a faulty transmitter in a computer. Manny Palmeiro, a MDTA marketing manager, said the system detected trains when none were on the tracks. "Phantom" trains have been a recurring Metromover glitch, one of a long string of computer and other electronic and electric problems plaguing the system. MDTA disclosed last week that in the spring and fall, sunshine sometimes trips safety sensors that detect the presence of trains. Those sensors are being realigned to shield them from the sun. Last month, MDTA managers warned that Metromover glitches likely will not go away soon. In fact, they said glitches may well be a permanent fixture of the nation's largest and most elaborate downtown automated rail system. [Source: *Miami Herald*, 27 Apr 1995] ------------------------------ Date: Thu, 27 Apr 1995 19:22:22 -0700 From: Mark Seecof Subject: Radar-detector messages & cop-car computers At page 91 of the April 1995 Law and Order magazine (v.43 no.4) in the "Police Equipment News" section a short item describes a "Collision avoidance system" which "takes advantage of the millions of radar detectors in civilian use." Basically, the system requires police cruisers and other emergency vehicles (e.g., ambulance) to be equipped with microwave transmitters designed to set off speed-radar detectors. Drivers will presumably react to radar-detector alerts by looking around, improving the chance that they will see and yield to or avoid a vehicle using lights &| siren to claim right-of-way. The detector vendor Cobra Electronics developed the system and sells detectors capable of decoding short text messages from the alerting signal. Cobra's present CAS transmitters can be programmed to send either "Emergency Vehicle" (moving vehicle) or "Road Hazard" (vehicle stopped on highway) and the scheme allows for other messages. I'm not sure how to score the risks here. I admire the elegance of regarding existing radar detectors as general-purpose warning receivers, and the message encoding is icing on the cake. (I applaud the designers for using an open and flexible alphameric code to permit arbitrary message content.) On the other hand, the transmitters will ``pollute the channel'' (degrade S/N ratio) in a sense, making it harder for drivers to detect ``real'' radar threats. So long as police confine system use to emergencies I think it's great. If the system gains wide use, auto makers could put alert-receivers into vehicles at the factory (such receivers need not serve as general radar-detectors; they could discriminate warning signals by their alphameric code content). An article in the same magazine at page 77 by Tom Yates titled "Magic Patrol Cars: Police Travel Information Superhighway" suggests in glowing terms the many benefits to be had from increasing the computerization of patrol cars. I think the author reveals a certain naivete. For example he writes of one in-car machine: "the system is easy to learn because the software operates under the computer industry standard MS-DOS/Windows operating systems. To make the system even faster dedicated function keys minimize the number of keystrokes required for a given operation such as calling up information, editing data, or initiating system functions." He's describing a system to be used while the patrol car is moving. Considering how the car may lurch around I wonder if users will get in trouble by sometimes striking the wrong function key? Later in his column Mr. Yates (who, I should point out, is a good writer and clearly an expert on police vehicles and operations--if still on middle of the computer learning curve) discusses engine computers and suggests that they will be improved to offer very sophisticated variations in performance for different (e.g., cruising, pursuing) situations. I'm sure many RISKS readers would wait, as I would, for the second or third software release... Mark Seecof [all usual disclaimers implied] ------------------------------ Date: Fri, 28 Apr 1995 15:27:59 -0400 From: simsong@acm.org (Simson L. Garfinkel) Subject: AOHell (C) 1995 Simson L. Garfinkel Originally appeared in The Boston Globe, April 21, 1995 [Reproduced in RISKS with the author's permission] It's 10:00 P.M. on a weekend night, and some obnoxious guy in the America Online Chat Forum won't shut up. What do you do? You give them the finger, of course. And if that doesn't work, you can always shoot them. Want everybody in the chat room to shut up so you can talk? Just click the button labeled "Ghost," and the screen will clear away everyone else's comments, giving you space to make yourself heard. You won't find these features on America Online's standard set of menu options. But they are part of a new anti-AOL program called AOHell that's making the rounds on some electronic bulletin board systems. AOHell can do more than make mischief in America Online's chat rooms: the program has a number of devilish features that seem designed for turning online lives into living nightmares. Armed with AOHell, one user can send dozens, or hundreds, of electronic mail messages to an unwitting victim in just a few seconds, a technique known as "mail bombing." AOHell can also mail bomb the victim's fax machine and even his US mailbox. And what if you really don't like another subscriber? Just click on the "Punt" command and you'll abruptly log them off, thanks to an apparent bug in America Online's operating software. Why would someone develop such a program and give it away for free over the Internet? "I hate the staff on AOL for one, I hate most of the people on AOL for another, and I wanted to cause a lot of chaos," explains one of the anonymous authors of AOHell, who identifies himself only as Da Chronic, in the program's instruction manual. Indeed, AOHell's worst punches seem to be aimed directly at America Online itself. AOHell has a nefarious system built into it for generating fictitious credit-card numbers. According to users, the program can make free accounts that last up to 10 hours of online time or one week, whichever comes first. For users with high bills for the nation's second-largest online service, AOHell has the ability to let users download files for free. "Any member using AOHell will have their account immediately terminated," says Margaret Ryan, a spokesperson for the company. AOHell is a piece of software for engaging in illegal activities, sometimes called banditware, which runs in conjunction with America Online's communications software for Windows-based computers. It appears to be the first time that such a program has been written to directly attack one of the nation's large online services. Some of the AOHell's abilities appear to exploit bugs in the America Online system, while others, such as the ability to display a raised middle finger in a chat room, seem to merely simulate an extremely rapid typist. Ryan wouldn't say if AOL has any technical fixes in the works that would prevent the program from functioning properly. Indeed, Ryan doesn't even know who wrote AOHell. Although AOHell's author has chosen to remain anonymous, a built-in feature allows AOHell users to send bug reports to the program's author. Those reports get sent to a computer in Finland called an anonymous remailer, which allows people on the Internet to exchange electronic mail without knowing each other's identities. "If you think AOH 2.0 is marvelous, wait until you see 3.0," wrote the program's author, in response to an electronic mail message. "I'm almost finished with it and it will make version 2 look like a Commodore 64 program, to say the least." ------------------------------ Date: Fri, 28 Apr 95 23:24:31 PDT From: Tim Kolar Subject: Terrorism and telecommuting In the aftermath of the recent tragedy in Oklahoma, there have been several reports of government agencies allowing at least temporary telecommuting arrangements for their employees. One wonders if widespread telecommuting could alleviate this kind of problem completely. Individual attacks and attempts to disrupt the communications backbone are a possibility, but I'm not sure there's much to attract terrorists in either of them. Harrassing individuals hasn't done much for the so-called "Unabomber", and disruption of telephone service is more an annoyance than something to live in terror of. In any case, I like the sound of "everyone go home and work" a lot better than "we'll be installing video cameras on every street corner". -Tim Kolar ------------------------------ Date: Sun, 30 Apr 1995 09:39:02 +0000 From: rkmoore@iol.ie (Richard K. Moore) Subject: CyberWinter: A Forecast Not that this should be unexpected news to any of you, but Cyber Winter is at hand. We are aware of the Cyber Glaciers -- in the form of the S.390 Censorship Bill and the S.1984 FBI Police-State Enablement Act -- blasted loose from the Washington Ice Floes by the ever-so-timely Oklahoma explosion. But merely the _news_ of the glaciers is enough to chill hearts and will... One list, with mild political content, was shut down last week with no explanation. After persistent investigation, I was able to learn that someone up the byte-chain feared that the list _might_ be perceived as controversial _by someone someday_, and out of concern for his "job and family", felt he better shut down the list ASAP. I learned this from the person himself, although it took several rounds of questions to get past his layers of embarrassment. This was at a prestigious university. I promised not to name names. The Internet is very fragile. It doesn't require police activity to shut it down; all it takes is the fear of controversy, in a climate of media-fanned public emotions. The lists and servers operated by universities and corporations are brittle as fine crystal -- those institutions have no incentive to risk even the _potential_ censure of their customers, alumni, directors, funding sources, etc. Commercial providers (AOL, CServe, etc) similarly won't wait for a knock on the door before they "clean up their act" -- and I mean sparkling lemon-fresh baby-powder clean, suitable for children, grannies, and Baptists (no offense intended.). We are entering what the ACLU refers to as a "chilling" era. The Well, CPSR, APC -- and other sites with a conscience -- will in many cases take a principled, courageous stand for cyber rights. But those are exactly the sites that the Police State legislation is designed to suppress. They can't afford to pursue the "Enumerated Defenses", the way Cyberspace INC will be able to, when it distributes its interactive soft-porn cyber-soaps into everyone's home, in order to sell burgers, lager, and designer jeans. Forget open BBS's -- they'll soon be history. It's time to get out your winter coats. For what little difference it'll make, you might want to take down the personal email and snail addresses of your online associates while you still can. ------------------------------ Date: Sun, 30 Apr 1995 10:24:19 -0400 From: simsong@acm.org (Simson L. Garfinkel) Subject: Privacy directory This isn't so much a RISK as a RESOURCE. The Privacy Journal has assembled a really phenomenal directory of privacy professionals. The directory has hundreds of people, with their names, phone numbers, addresses, email addresses, and brief descriptions of what they do or have done that's notable in the privacy field. I've been writing about privacy issues for nearly a decade, but even my own personal database pales in contrast to what the Privacy Journal's publisher Robert Ellis Smith has assembled. You can get the directory for $12.50 from Smith. It is available in print or electronically. Here is Smith's entry: Smith, Robert Ellis Publisher Privacy Journal P. O. Box 28577 Providence RI 02908 401/274-7861 fax upon request Attorney, publishes monthly newsletter, books and special reports; author of Our Vanishing Privacy (1993), The Law of Privacy Explained (1993), Compilation of State and Federal Privacy Laws (1994) E-mail address: 0005101719@mcimail.com (Note: I write occasionally for The Privacy Journal, but this is still a great resource.) ------------------------------ Date: 28 Apr 95 9:53:31 EDT From: Charlie Kaufman/Iris Subject: Re: Lotus Notes authentication protocol challenged (Gong, RISKS-16.87) >(2) [...] Cynthia Dwork of IBM Almaden wrote in ACM SIGACT >News 26(1) (March 1995) that the authentication procedure using public-key >systems in Lotus Notes, as described in its "Internals online book", has >security flaws. Lotus's response is (1) the actual system does not work as >described in the manual and (2) how it actually works is proprietary >information. [LG: (1) is dangerous by itself, and if (2) is true, then why >pretending to describe the procedure in the first place.] It's all true. The authentication protocol used by Lotus Notes is a somewhat involved mix of public key and secret key cryptography designed for good security and performance. In the Security Internals online book in a section on the certificate hierarchy and the implied trust model, there is an aside on how authentication takes place once the two sides know each others public keys. Because the truth was complex and the complexity seemed irrelevant, the author substituted a "classic" public key authentication protocol for the real one. Unfortunately, while that protocol was not itself flawed, using the same public key for that protocol and for the encryption and the signing of electronic mail would be insecure. That was the central point of the Dwork article: that two well designed cryptographic protocols can be insecure when used together sharing keys. The actual Lotus Notes authentication protocol does not have this problem. While the Lotus Notes authentication protocol was never intended to be proprietary or secret, it was also never fully publicly documented, and the public documentation that did exist was incorrect. A more complete writeup has subsequently appeared in the book "Network Security: Private Communication in a Public World", by Charlie Kaufman, Radia Perlman, and Mike Speciner, Prentice Hall, 1995. The on-line documentation will be corrected. Charlie Kaufman Email: charlie_kaufman@iris.com Tel: 1-508-392-5276 Iris Associates, One Technology Park Drive, Westford, MA 01886, USA ------------------------------ Date: Sat, 29 Apr 1995 19:49:08 GMT From: dcline@netcom.com (David Cline) Subject: Re: Floating-Point Time (Kuenning, RISKS-17.09) > ... Since there are about 3x10^7seconds in a year, or about 10^8 every > 3 years, one can represent about 8x16x3 = 384 years to millisecond > precision without violating that range, right? Wrong. This confuses milliseconds and microseconds; You can represent 285 years to *microsecond* accuracy in 53 bits. If you only care about millisecond accuracy, you can represent about 285,000 years. There are also ways of using the sign bit to double the effective range. Dave Cline Spring Valley Software dcline@netcom.com [Your moderator is dismayed that this is dragging on so long! PGN] ------------------------------ Date: Fri, 28 Apr 95 11:12:30 EDT From: hopkins@VFL.Paramax.COM Subject: Re: Floating-Point Time On the year-zero and religious wars: PGN suggests [RISKS-17.09] that first-century dates (which were, after all, not invented until well after the fact) would have created religious wars had there been computers to suggest that there should be a year zero. Any self-respecting computer, however, would have balked at attempts to divide the factions by zero. Bill Hopkins hopkins@VFL.Paramax.Com Unisys Corporation (Soon to be Loral, they say) 610-648-2854 or 363-7464 Valley Forge Eng'g Ctr, POB 517, Paoli PA 19301 ------------------------------ Date: Thu, 27 Apr 95 13:11 PDT From: snelson@ptdca2.al.intel.com Subject: Re: Digital libraries (Kass, RISKS-17.09) > [...] However, the only media which has persistence of 50+ years which > has been proven in a reliable way is film. This points out a risk of being to close to the technology. Perhaps the microfilm is the only "technological" way of storing media for 50+ years, but it seems to me that the low-tech method of printed books has about 5 to 10 times that lifespan, depending on the paper and ink used. It also has the benefit of being immediately accessible to the reader, as no fancy technology is necessary to extract the data, outside of a current prescription for one's glasses. Shannon Nelson Portland Technology Development, Intel Corp. snelson@ptd.intel.com (503) 642-8149 I don't speak for Intel ------------------------------ Date: 30 Apr 1995 01:20:08 -0400 From: mds@access.digex.net (Michael D. Sullivan) Subject: Re: Digital Libraries (Kass, RISKS-17.09) And what about paper (acid-free), papyrus, or other similar media that have lasted hundreds or thousands of years intact? Or stone (e.g., cuneiforms or etchings on silicon)? Microfilm (silver on film) has been around far less time than these. In fact, the film media used in the 1930s (nitrocellulose) has proven to be disastrous -- it practically self-destructs. Moreover, silver has only been in use for a bit over a century as a means of fixing an image, and it has distinct disadvantages, due to oxidation. Carbon-based ink on non-acid paper, on the other hand, lasts virtually forever. Perhaps replacing paper with Mylar would be a good step, but silver halide images would not appear to be good for long-term archiving; photographers have turned to platinum and other means of giving longevity to photographic images, in lieu of silver. India ink on papyrus or vellum might last longer, though. Maybe convert the data to carbon-based laser toner on Mylar in barcodes? Michael D. Sullivan | INTERNET E-MAIL TO: mds@access.digex.net Bethesda, Md., USA | also avogadro@well.com, 74160.1134@compuserve.com ------------------------------ Date: Thu, 27 Apr 1995 15:24:59 -0400 (EDT) From: Michael Froomkin Subject: Clipper paper available for anon FTP My paper, "The Metaphor is the Key: Cryptography, the Clipper Chip, and the Constitution" is now available for anonymous FTP. It is about 180pp. long, and contains more than 800 references. I would welcome your feedback on this paper -- even (especially?) contributions to the inevitable errata sheet. (Please note this document resides at what is officially a "temporary" site, so that if you create a web link to it, please let me know so that I can notify you when it moves). Contents of FTP://acr.law.miami.edu/pub/.. File Type - - - - - - - - - - - - - - clipper.asc ASCII clipper.wp WP 5.1/Dos clipperwp.zip Pkzipped version of clipper.wp clipper.ps My best effort at Postscript. YMMV. (approx. 7Mb.) clipperps.zip Pkzipped version of clipper.ps clipper.ps.gz Gzipped version of clipper.ps Ports provided by nice people (please note I have not checked these): clipper.ps.Z Unix compressed version of clipper.ps with carriage returns removed -- courtesy of Whit Diffie clipperMSW.sea.hqx Binhexed self-extracting Microsoft Word 5.1 for Macintosh version of clipper.wp -- courtesy of Ted Byfield None of these files contains correct and final page numbers, and there are generally trivial typos that were corrected in the printed version. The printed version appears at 143 U.Penn.L.Rev. 709 (1995). I intend to put up a web version presently. The .index file in the above directory will have details when a clean copy is ready for prime time. A link to an experimental and highly buggy HTMLized version may appear at erratic intervals at http://acr.law.miami.edu at the very bottom of the homepage. A.Michael Froomkin, Associate Professor of Law, U.Miami Law School, POB 248087, Coral Gables, FL 33146 USA +1(305) 284-4285 MFROOMKI@UMIAMI.IR.MIAMI.EDU ------------------------------ Date: 29 Apr 1995 13:22:30 -0400 From: "Dave Banisar" Subject: Advanced Surveillance, Call for Papers CALL FOR PAPERS Advanced Surveillance Technologies Sponsored by Privacy International, and Electronic Privacy Information Center 4 September 1995 Copenhagen, Denmark Overview Over the past decade, fundamental changes have taken place in the nature and the environment of surveillance. New information systems offer an unprecedented ability to identify, monitor and track a virtually limitless number of individuals. Some leading-edge technologies are likely to revolutionize the practice of surveillance. The factors of cost, scale, size, location and distance have, in many instances, become largely irrelevant. The impact of political and economic change throughout the world has also created unforeseen dimensions to surveillance. The evolution of a Global Information Infrastructure will have a profound impact on the scope of potential surveillance of individuals. The end of the cold war and the privatization of public sector activities has magnified the impact of change. The merging of technologies has also created new opportunities for wide-scale surveillance. The nature of surveillance has changed to the extent that modern information systems involve a pre-requisite of general surveillance of populations. The pursuit of perfect identity has created a rush to develop systems which create an intimacy between people and technology. Advanced biometric identification and sophisticated ID card systems combine with geographic tracking to create the potential to pinpoint the location of any individual. The use of distributed databases and data matching programs makes such tracking economically feasible on a large scale. Extraordinary advances have recently been made in the field of visual surveillance. Closed Circuit Television (CCTV) systems can digitally scan, record, reconfigure and identify human faces, even in very poor light conditions. Remote sensing through advanced satellite systems can combine with ground databases and geodemographic systems to create mass surveillance of human activity. The globalization of information systems will take information once and for all away from the protection and jurisdiction of national boundaries. The development of data havens and rogue data states is allowing highly sensitive personal information to be processed outside any legal protection. At a more intimate level, research is underway in more than a dozen countries with the aim of implanting microchip technology directly into the human brain. US and European medical institutes have already conducted many such operations. The creation of a direct link between the human brain and computer technology is at an advanced stage. Such procedures are initially aimed at stimulating dead senses and paralyzed limbs. Within two decades, it is possible that such implants will be at a sufficiently advanced stage to enable complex interaction between the brain and external technology. The science of nanotechnology, which involves the re-configuration of individual atoms and molecules, will present the potential for virtually undetectable covert surveillance. These and other developments are changing the nature and meaning of surveillance. Law has scarcely had time to address even the most visible of these changes. Public policy lags behind the technology by many years. The repercussions for privacy and for numerous other aspects of law and human rights need to be considered sooner rather than later. This one day conference will present an overview of these leading-edge technologies, and will assess the impact that they may have in the immediate future. Experts and analysts will discuss the nature and application of the new technologies, and the public policy that should be developed to cope with their use. The conference theme is unique, and interest in the event has already been expressed from throughout the world. Program contents The first session will assess new dimensions in current surveillance technologies. The remainder of the day will be devoted to exploring technologies which are in the formative stage of development. Preliminary List of Topics: o Advanced Satellite Surveillance o Microchip Implants o Nanotechnology o Biometrics and perfect identity o Advanced Geodemographic Systems o Data Havens and Rogue Data States o Information Warfare o Cryptography The conference will be held in Copenhagen, and is timed to coincide with the 17th annual international meeting of privacy and data protection commissioners. Number of participants : approximately one hundred Cost: US $75 - Individuals/non-profit organizations $175 - Commercial organizations Privacy International and the Electronic Privacy Information Center are now requesting abstracts for papers. Papers should be directed at a general audience, and should either present an overview of an aspect of advanced surveillance technology, or they should discuss the likely use and impact of the technology. Abstracts or papers can be emailed to Privacy International at: pi@privacy.org Alternatively, they can be sent to : Privacy International Washington Office 666 Pennsylvania Ave, SE, Suite 301 Washington, DC 20003 USA 1-202-544-9240 (phone) 1-202-547-5482 (fax) Web address: http://privacy.org/pi/ gopher/ftp cpsr.org /cpsr/privacy/privacy_international/ David Banisar (Banisar@epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * ftp/gopher/wais cpsr.org Washington, DC 20003 * HTTP://epic.digicash.com/epic ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.10 ************************ 4-May-95 21:15:25-GMT,27742;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA20145 for ; Thu, 4 May 1995 17:15:24 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id RAA11256 for ; Thu, 4 May 1995 17:15:22 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id RAA04192 for ; Thu, 4 May 1995 17:15:18 -0400 Received: by chiron.csl.sri.com id AA07263 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Thu, 4 May 1995 14:06:55 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 4 May 95 14:06:53 PDT Subject: RISKS DIGEST 17.11 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Thursday 4 May 1995 Volume 17 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Finnish Executives Jailed for Software Piracy (Edupage) Cellular phones and Pacemakers: a RISKY Combination (Peter M. Weiss via Duane Thompson) The Road Watches You: 'Smart' highway systems may know too much (Simson L. Garfinkel) Using a car alarm to steal a car (Kevin Purcell) Final Program for COMPASS '95 (John Rushby) Safety through Quality Conference, 23-25 Oct, Cape Canaveral, Florida ``Cybercritical'' (Cliff Stoll's new book) (Edupage) Re: Portable phone interference in hospitals (Derek Hill) Re: CyberWinter: A Forecast (Arthur A Mcgiven) Re: "Outrage! of the Month" (Jeff Grigg) Year 2000? Don't forget 1752! (Matthew D. Healy) Re: Floating-point time (Andrew D. Fernandes, Peter Ludemann, Phil Brady) Re: Radar-detector messages & cop-car computers (F. Barry Mulligan, Mark Seecof, Richard Soderberg) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sun, 30 Apr 1995 20:26:07 -0400 From: info@ivory.educom.edu (Edupage) Subject: Finnish Executives Jailed for Software Piracy The two top executives of a Helsinki engineering company have been given 60-day jail sentences and $72,000 fines for knowingly using illegal copies of AutoCAD computer-aided design software. The stiff punishment is a victory for the Business Software Alliance, which says that its member companies suffered $15.2 billion in global losses last year due to software piracy. (Financial Times 4/28/95 p.3) [Edupage, 30 April 1995] ------------------------------ Date: Mon, 1 May 1995 19:52:13 -0700 (PDT) From: Duane Thompson Subject: Cellular phones and Pacemakers: a RISKY Combination When they talk about a "heart stopping" telephone call, this must be what they mean. Date: Mon, 1 May 95 11:15 EDT >From: "Peter M. Weiss +1 814 863 1843" BUT DO YOU STILL HAVE TIME TO CALL 911? [abstracted] The Wireless Technology Group says studies show that in some cases cellular phones placed near the chest can cause pacemakers to recalibrate themselves or stop and restart. The advisory group warns that new digital pocket phones are of particular concern -- especially since their numbers are likely to proliferate once personal communications services are widespread. No such effects from the older analog cellular phones have been observed. A spokesman for Medtronic, a pacemaker supplier, says the company is advising patients with pacemakers to turn off their portable phones when the phone is in a shirt pocket, to hold the phone 10 to 12 inches from the chest when using it, and to hold the phone to the ear opposite the side where the pacemaker's implanted. (*Wall Street Journal*, 28 Apr 1995, p. B1) [It is a very old problem. The first pacemaker death due to interference was recorded in the Risks annals in 1980 (in Software Engineering Notes, before the on-line Risks Forum was established). PGN] ------------------------------ Date: Wed, 3 May 1995 15:37:38 -0400 From: simsong@acm.org (Simson L. Garfinkel) Subject: The Road Watches You: 'Smart' highway systems may know too much [This is slightly longer version of my article that appeared in the March 3 1995 issue of The New York Times.] The Road Watches You: 'Smart' highway systems may know too much (C) 1995, Simson L. Garfinkel Highway authorities throughout the country are building futuristic "smart road" systems designed to unclog our highways and bridges, improve driver safety, and create a variety of new services for our nation's motorists. But these smart roads could lead to an Orwellian surveillance state if we do not act now to change their course. One smart road system is already in operation on New York's Tappan Zee Bridge. Called E-ZPass, the system allows drivers to drive through the toll plaza without reaching for their wallets or rolling down their windows. Instead, a computer operated by the Thruway Authority reads an electronic tag mounted inside the car's windshield, and automatically deducts the toll from a special pre-established account. Other systems are going up around the country. In Florida, the Orlando-Orange County Expressway Authority has a system called E-PASS which lets drivers pay their tolls on the East-West Expressway and certain parts of the Central Florida GreeneWay. Instead of a windshield tag, E-PASS uses a radio transponder the size of a flashlight mounted under the car's front bumper. A similar system is being planned for the San Francisco Bay Area. These automatic toll collection systems are just the beginning of a nationwide plan called Intelligent Transportation Systems, or ITS. Rather than have each city adopt its own tag or transponder, the Department of Transportation and ITS America, a Washington-based organization that promotes the system, are scrambling to create a single, national standard. As envisioned, smart roads could further reduce highway congestion by alerting drivers to upcoming accidents; a computer display mounted on the dashboard could suggest alternative routes. With its planned two-way communication between the car and the intelligent road, ITS could even eliminate the search of a place to park. Instead, your car's computer could automatically locate the nearest lot with an opening and electronically reserve you a place. But there is a dark side to this plan, a privacy problem that its boosters are trying to pave under. These systems offer unprecedented opportunities to monitor the movements of drivers. It would create a bank of personal information that government and private industry might have difficulty resisting. Consider Florida's E-PASS system. Each month, every E-PASS subscriber gets a detailed statement listing the exact time, date and location that each toll was collected. ITS America has adopted a set of privacy principles which say that states shouldn't take advantage of this dat, yet the organization specifically envisions that "states may legislate conditions under which ITS information will be made available." Phil Agre, who teaches communications at the University of California, San Diego, and closely follows privacy issues, warns that there might be other unintended consequences of the widespread use of ITS systems. Auto insurance companies already offer discounts to driver who don't live in areas of high auto theft or accidents; in the future, says Agree, they might offer discounts to drivers who can prove that they haven't driven onto "the wrong side of the tracks." The data could also be sold illegally by insiders. Information about a person's movements might be a key fact in forcing an out-of-court settlement in a divorce or worker's compensation case. Private investigators would have a big incentive to bribe low-paid clerical workers for a photocopy of somebody's toll-crossing bill. There is an alternative to this system. Instead of transmitting an account number, a radio would transmit "digital cash" using a smart card inside the car similar to the telephone cards used in many European countries. But judging by plans under way so far, state agencies and the Government haven't shown much interest in making privacy a priority in the design of the tomorrow's intelligent highways. Americans have always loved the freedom that their cars give them. Could that too become a thing of the past? Simson Garfinkel is a Cambridge-based writer who covers privacy issues. His fourth book, PGP: Pretty Good Privacy, was published by O'Reilly in January. ------------------------------ Date: Mon, 1 May 1995 16:43:26 -0700 From: xenolith@halcyon.com (Kevin Purcell) Subject: Using a car alarm to steal a car We had a car stolen from our company's parking garage recently. The car had a car alarm which appears to have aided the car thief. The thief wandered around our building (a separate risk) until he found an a set of keys in an empty cubicle. The cubicle occupant had left the cube for a few moments. The thief the keys and then wandered down to our five level parking garage. We presume he walked down the spiral pressing the button on the car alarm transmitter on the key chain. When he came into range of the car it chirped, giving away its location and he deactivated the alarm. He then stole the car. Personally I hate audible car alarms and prefer to mechanically immobilise a car. Another argument in my favor! Kevin Purcell // kevinpu@atm.com // xenolith@halcyon.com PGN: This risk showed up in a tv program this week. Interesting! I didn't figure it was original nor did I talk about how to combat the problem which amount separating the alarm controller from the keychain with the attendant risk of them becoming separated or lost or have a silent alarm (indicate alarm state by a flashing LED rather than beeping or flashing the headlamps). The latter is probably a better solution. The best solution is to immobilise the car mechanically. ------------------------------ Date: Mon 1 May 95 10:40:22-PDT From: John Rushby Subject: Final Program for COMPASS '95 COMPASS '95 Tenth Annual Conference On Computer Assurance Systems Integrity, Software Safety, and Process Security June 26-30, 1995 National Institute of Standards and Technology Gaithersburg, MD Sponsored by: IEEE Aerospace and Electronics Systems Society IEEE National Capital Area Council In Cooperation with: British Computer Society COMPASS covers several topics of interest to RISKS readers including safety-critical systems, testing, formal methods, safety kernels, security, standards, and processes. The technical program features 22 papers on these topics, plus a panel discussion on "Safety and Security Issues in Developing and Operating Intelligent Transportation Systems." The keynote speaker is Robert Veeder, Tax Payer Privacy Advocate of the IRS on "Privacy Risks to Computer Systems." The banquet speaker is none other than Peter Neumann, illustrious moderator of this newsgroup. There's also a tools fair (the WWW page has latest details of the tools to be shown). The conference is preceded by two days of tutorials on the following topics "The Practical Application of Formal Methods to High Integrity Systems" "Security Engineering Capability Maturity Model" "Safety Analysis in the Mil STD 498 Project Environment" "Metrics for Risk Assessment, Software Quality, and Process Improvement" "Real-Time Rule-Based Systems: Analysis & Optimization" You can get the program and other details as follows. 1. Via WWW from http://www.csl.sri.com/compass95.html 2. Via FTP from ftp://ftp.csl.sri.com/pub/compass95-brochure.txt 3. Email Rushby@csl.sri.com if all else fails The location is the National Institute of Standards and Technology, Gaithersburg, MD, which is one of the northern suburbs of Washington DC. [Many thanks to John for having taken the time to post what I consider to be an ideal conference announcement, short, to the point, justifiably relevant to RISKS readers, and containing information on how to get the REST OF THE STORY. Most often I have to edit down the full conference info; I get many complaints if I run the whole thing. Cheers! PGN] ------------------------------ Date: Mon, 1 May 1995 10:59:48 -0400 (EDT) From: RQCFR@lmsmgr.lerc.nasa.gov Subject: Safety through Quality Conference, 23-25 Oct, Cape Canaveral, Florida Abstract deadline: 15 May 95 ------------------------------ Date: Sun, 30 Apr 1995 20:26:07 -0400 From: info@ivory.educom.edu (Edupage) Subject: ``Cybercritical'' (Cliff Stoll's new book) A new book ("Silicon Snake Oil") by Clifford Stoll, the scientist and computer security expert who once tracked down an international spy ring using the Internet, documents his disdain for most of what goes on in cyberspace. "The information highway is being sold to us as delivering information, but what it's really delivering is data... Unlike data, information has utility, timeliness, accuracy, a pedigree." He says that what's missing in cyberspace is "anyone who will say, hey, this is no good... Editors serve as barometers of quality, and most of an editor's time is spent saying no." (New York Times 4/30/95 E7) [Edupage, 30 April 1995] ------------------------------ Date: 3 May 1995 16:57:28 GMT From: Derek Hill Subject: Re: Portable phone interference in hospitals Following the posting quoting the Nottingham Recorder article about an incident at the Bassetlaw General Hospital, in which 100s of patients died, I contacted the Medical Devices Agency to check the truth of the story. It was the first time I'd tried to contact the MDA by email, and I got a reply - by fax :-( Thank you for your enquiry concerning the Nottingham Recorder. There is no truth in the newspaper's allegation regarding an incident at the Bassetlaw General Hospital. Mr J Lefever also confirmed that the Safety Action Bulletin, which I have posted here in the past, is the most recent advice on the subject of mobile phones in hospitals. So, as far as I understand, there are anecdotal stories of mobile phones interfering with medical equipment, but these incidents have not been fatal. The current advice is that the use of mobile phones, two-way radios etc. should be discouraged in the vicinity of sensitive monitoring equipment. Derek ------------------------------ Date: Tue, 02 May 95 14:23:19 GMT From: Arthur@mcgiven.demon.co.uk (Arthur A Mcgiven) Subject: Re: CyberWinter: A Forecast (Moore, RISKS-17.10) It seems clear to me that much of the anti-free-internet propaganda comes from journalists, politicians, etc who are technologically illiterate - one only has to analyse what they say to see that. Clearly such people don't surf the internet, so someone is feeding them with stories, knowing full well what reaction to expect. That could be someone with an interest in converting the internet into a controlled and / or profitable enterprise. There are similar attacks here on the BBC and no doubt in the USA on the PBS from similar quarters. Arthur A Mcgiven arthur@mcgiven.demon.co.uk Compuserve 100315,3453 ------------------------------ Date: Wed, 3 May 95 15:10:04 CDT From: jeff@michelob.wustl.edu (Jeff Grigg) Subject: Re: "Outrage! of the Month" by National Taxpayers Union Foundation > In "Capital IDEAS" (Vol. 3, No. 6, April 1995) ... [conversion to > correctly handle the year 2000] is expected to take SSA seven years. Interesting. The way I figure it, 1995 + 7 years = 2002. I think I see a problem here. [Yeah, Jeff! I was wondering if anyone would pick up on that one. PGN] ------------------------------ Date: Mon, 01 May 1995 16:04:09 -0500 From: healy@seviche.med.yale.edu (Matthew D. Healy) Subject: Year 2000? Don't forget 1752! [I deleted a comment about accounting software that plans 5 years in the future already being at risk. We've done that one before... PGN] I recently saw a posting in comp.databases.sybase about another problem. The date/time functions of Sybase won't accept dates before 1753 because most of the English-speaking world changed over to the Gregorian calendar in 1752, and they wanted to avoid all the OldStyle vs NewStyle problems with earlier dates. Well, this guy was in charge of alumni records at an institution that was founded before 1725; for their oldest records they've had to roll their own date/time functions. Matthew.Healy@yale.edu Postdoc, Genetics & Medical Informatics ------------------------------ Date: Tue, 2 May 1995 19:49:51 -0400 From: "Andrew D. Fernandes" Subject: Re: Floating-point time It seems to me that the real issue as to whether or not floating point representations are appropriate for timestamps is not "can I get microsecond resolution?" but "is it going to work unconditionally?" Floating point numbers bedevil numerical programmers for several reasons; we need to know the radix, number of mantissa and exponent digits, behaviour of rounding, etc. to guarantee "good" results---there is a reason that textbooks have been written about numerical analysis. Modern computers generally stick to the IEEE-754 standard for floating point arithmetic, and thus code is usually fairly interchangeable, but anyone who has ever done intensive number crunching on old IBMs, VAXen, or CRAYs can tell horror stories about interchanging floating point programs between systems. Even going between a SPARCstation and my '486 at home, I can see a few digits change. "Unconditional portability" is ludicrous under these conditions. A 64 bit integer can represent 1.84e19 values, which implies about 2 nanosecond resolution of a thousand year interval. Integer math is very portable across computer systems, or at least is very easy to describe fully, and 1 + 1 always evaluates as 2, and not 2.0001. -Andrew D. Fernandes (adfernan@cnd.mcgill.ca) ------------------------------ Date: Thu, 4 May 95 11:42 PDT From: ludemann@netcom.com (Peter Ludemann) Subject: Re: Floating-point time In my original note I mentioned something really simple: handling clock ticks. Not handling time, which is a topic for PhD theses (Stanford is about to grant a PhD for a thesis on temporal representation in databases). My problem was simple: I needed to do 48-bit arithmetic on a machine which had 32-bit integers. I had been given an assembler routine which did the 48-bit arithmetic wrong; and I was fortunate to test it in December when its accumulated error was about 3 minutes in converting clock ticks to a date (in January, it had almost no error). So, what to do? Obviously, writing 48-bit arithmetic in assembler was error-prone and tedious. Doing it in PL/I (this was before C was generally available) wasn't much more fun nor less error-prone (anyone who has read the PL/I manual's description of handling overflow and precisions will agree that it's not a pretty sight; and I later learned that the PL/I implementors had got it wrong anyway). And I didn't have access to LISP's rational-number packages. In a flash of inspiration, I realized that double-precision floating point, with 53-bit mantissas, would handle my 48-bit integers with no round-off errors. Converting between 48-bit integers and floating point is simple (it's a "well-known assembler idiom" that takes about 3 instructions). And everything would then proceed perfectly (even a Pentium can get floating-point addition and subtraction right). At one stroke I had removed a few pages of difficult assembler and replaced them by a few lines of PL/I. Less code, less chance of error. [Inspired by this, I wrote a disk accounting package that eschewed packed decimal arithmetic and instead used floating point (of course, I calculated everything in cents because 1.01 doesn't represent exactly but 101 does. Another success.)] One of my jobs as a programmer is to reduce the risk of error in my system. I can only test so much. Testing 48-bit integer arithmetic is not fun, at least for me; and proving the code right is difficult (Knuth allegedly wrote "Beware of bugs in the above code; I have only proved it correct, not tried it."). PL/I's implementation of 15-digit packed decimal was buggy. And I wasn't being paid by the number of lines of code (au contraire: if I finished early, I took time off). The lessons for RISKS: before you try to do something complicated, maybe there's something simple and reliable lying around that you can pervert slightly into the form you want. [My original RISKS lesson was to be sure to test time/date conversion routines at many times of the year; if they work in January, they might not work in December.] - Peter Ludemann ------------------------------ Date: Tue, 2 May 1995 18:26:06 GMT0BST From: Phil Brady Subject: Re: Floating-point time [Your moderator is dismayed that this is dragging on so long! PGN] Agreed - the debate has been interesting, but hasn't it run it's course yet? The fact is that every programmer needs to decide whether to use floating, decimal, integer, string, etc and the appropriate precision for every variable in every program depending on the application. If they don't know the appropriate form for time for the problem in hand, then they aren't programmers! Phil Brady, University of Wales, Swansea 01792 295160 ------------------------------ Date: Sun, 30 Apr 1995 23:08:03 -0500 (CDT) From: "F. Barry Mulligan" Subject: Re: Radar-detector messages & cop-car computers (Seecof, RISKS17.10) >... microwave transmitters designed to set off speed-radar detectors. It's interesting to note a recent thread in rec.radio.scanner, where a number of posters recounted with glee their use of low-power microwave emitters to trigger radar detectors. The uniform response by drivers was to hit the brakes. Equipping an ambulance with such a device should ensure that the first vehicle on the scene of a rear-end collision will be equipped for the emergency. ------------------------------ Date: Thu, 27 Apr 1995 19:22:22 -0700 From: Mark Seecof Subject: Radar-detector messages & cop-car computers At page 91 of the April 1995 Law and Order magazine (v.43 no.4) in the "Police Equipment News" section a short item describes a "Collision avoidance system" that "takes advantage of the millions of radar detectors in civilian use." Basically, the system requires police cruisers and other emergency vehicles (e.g., ambulance) to be equipped with microwave transmitters designed to set off speed-radar detectors. Drivers will presumably react to radar-detector alerts by looking around, improving the chance that they messages from the alerting signal. Cobra's present CAS transmitters can be programmed to send either "Emergency Vehicle" (moving vehicle) or "Road Hazard" (vehicle stopped on highway) and the scheme allows for other messages. Michael Hoffberg hoffberg@phebos.aps.anl.gov mike@anl.gov ------------------------------ Date: Thu, 4 May 1995 13:46:39 +0100 (NFT) From: richard soderberg Subject: Radar-detector messages & cop-car computers Having done some emergency medicine in ambulances, I cannot refrain from the following reflection. What does the average (slightly speeding) motorist do when s(he) realizes that someone is aiming a radar beam at the car? Easy, they will slam the brakes! This is precisely what I would *not* want to happen a few cars up front if I was trying to negotiate a tricky traffic situation at high speed, instead, I'd like people give way in a controlled manner. /RS Richard Soderberg, MD, The Karolinska Institute, Libr. and Med. Info. Center, Doktorsringen 21 C, S-104 01 Stockholm SWEDEN +46 8 728 80 00 ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.11 ************************ 13-May-95 23:03:01-GMT,27532;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA13067 for ; Sat, 13 May 1995 19:02:59 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA19682 for ; Sat, 13 May 1995 19:02:52 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id TAA15959 for ; Sat, 13 May 1995 19:02:43 -0400 Received: by chiron.csl.sri.com id AA12433 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Sat, 13 May 1995 15:55:06 -0700 From: RISKS Forum Sender: RISKS Forum Date: Sat, 13 May 95 15:55:05 PDT Subject: RISKS DIGEST 17.12 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Saturday 13 May 1995 Volume 17 : Issue 12 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Software Piracy (Edupage) Risks of trusting authority... (Peter da Silva) Mercedes-E marketing spreads virus (Klaus Brunnstein) Nautilus foils wiretaps (Simson L. Garfinkel) Microsoft "Bob" passwords (Jeremy Epstein) Internet Addiction (Ivan Goldberg) More on CNID (Marc Rotenberg) The Risks of trying to teach someone that doesn't want to learn (David P. Miller) Cellular disturbances (Torsten Lif) GPS Risks (Mark Moore) GPS landing systems (Neil Youngman) Problems with wrong assumptions about date conversion (Paul Eggert) Re: Year 2000? Don't forget 1752! (Tom Wicklund) ASIS articles Webbed (Frederick B. Cohen) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: Sun, 7 May 1995 19:54:51 -0400 From: info@ivory.educom.edu (Edupage) Subject: Software Piracy (Edupage 7 May 1995) Worldwide estimates of losses from piracy surpassed $15.2-billion last year. The problem is most rampant in Indonesia and Kuwait, where about 99% of all software is copied illegally. (Toronto Financial Post 5/6/95 p. 8) ------------------------------ Date: Fri, 5 May 1995 10:59:09 -0500 From: peter@nmti.com (Peter da Silva) Subject: Risks of trusting authority... > ... Clifford Stoll ... says that what's missing in cyberspace is > "anyone who will say, hey, this is no good... Editors serve as barometers I would say the opposite is true. On Usenet you *can't* get away with posting nonsense, because there are thousands of "editors" ready to jump on your posting and gleefully shred it in public. With printed information, you're depending on the editor being competent to judge the veracity of the information presented. It's become routine, for me at least, to check on the net to verify things I've read in print media. Yes, you have to be a bit savvy, to find the groups where competant people are monitoring postings, but that's true in print too. You have everything from the electronic equivalents of the National Enquirer, to groups like, well, comp.risks. > The date/time functions of Sybase won't accept dates before 1753 because... What do they do about dates in pre-soviet Russia? I had the same reaction to the general idea of using floating point numbers for relative time. Even in integers you need to beware of the singularity around zero (say you're dividing an integer by 2 to schedule events, if your division truncates towards zero you'll miss one event because -1, 0, and +1 all end up at the same point), with floating point these singularities are scattered up and down the number line. In any case the example seems to have been more a case of using floating point operators to perform 48 bit integer arithmetic, rather than using floating point arithmetic. ------------------------------ Date: Wed, 10 May 1995 15:49:36 +0200 From: Klaus Brunnstein Subject: Mercedes-E marketing spreads virus 2000 journalists recently received a diskette containing marketing information on Mercedes' new E-class cars. As hidden donation, this diskette contained also a virus of the Stoned family (Stoned.NoInt alias Stoned III alias Bloomington) which so far was not "in the wild" in Germany. After having been alarmed, Mercedes shipped 2,000 diskettes of a reliable AV product to the journalists. Many media reported this accident in Germany, claiming that "this virus is harmless". This is not fully untrue as the only intentional "damage" in this stealth variant of the Stoned family results in failures only with high-density diskettes. It is also possible that unintended damage occurs in the directory structure. This virus attempts to hide the infected boot sector against detection by some AV product. Fortunately, the product choosen by Mercedes reliably detects Stoned.NoInt on diskettes and disks. Question remains open whether the addressed journalists tested and cleaned all diskettes and systems which had been in contact with the infected diskette; otherwise, Mercedes marketing may have a long-time impact on some Mercedes drivers' PC systems :-) Klaus Brunnstein (Univ.Hamburg, May 10, 1995) ------------------------------ Date: Thu, 11 May 1995 15:43:02 -0400 From: simsong@acm.org (Simson L. Garfinkel) Subject: Nautilus foils wiretaps PC SOFTWARE FOILS WIRETAPS 5/10/95 By SIMSON L. GARFINKEL Special to the Mercury News As the U.S. Senate debates granting the Federal Bureau of Investigation new powers to wiretap personal communications, three West Coast computer programmers have planned their own preemptive strike: a free program, distributed on the Internet, that renders legal and illegal wiretaps useless. The programmers, Bill Dorsey of Los Altos, Pat Mullarky of Bellevue, Wash., and Paul Rubin of Milpitas, plan to release today a program that turns ordinary IBM-compatible personal computers into an untappable secure telephone. It uses an encryption algorithm called ''triple-DES'' that is widely believed to be unbreakable. ''Electronic surveillance by the government is on the rise,'' says Dorsey, the group's lead programmer. ''There also exists an equally large threat from the private sector as well: industrial espionage. Foreign governments are interested in wiretapping and getting information out of our high-tech firms.'' Called Nautilus, the program is being released as an attack on the Clinton administration's national encryption standard, the Clipper chip. Civil rights groups have criticized the Clipper initiative, since the federal government holds a copy of every chip's master key and can use that key to decrypt -- or decode -- any Clipper-encrypted conversation. But since the keys used by Nautilus to encrypt conversations are created by users, the government does not have a copy. A nod to Jules Verne Nautilus has another advantage over Clipper: Whereas AT&T's Clipper-equipped Telephone Security Devices Model 3600 costs $1,100, Nautilus is free program. ''You don't need any special expensive hardware for it. You just use ordinary PCs,'' says Rubin. The name ''Nautilus'' was taken from Captain Nemo's submarine in the Jules Verne novel, ''20,000 Leagues Under the Sea.'' But whereas Nautilus the sub was used to sink Clipper ships, the programmers hope that their creation will sink Clipper chips. To use Nautilus, both participants must have a copy of the program and an IBM PC-compatible computer equipped with a Sound Blaster card and a high-speed modem. The two participants must also agree upon a series of words called a ''pass phrase,'' which is used to encrypt the conversation. Both participants run the program and type in the pass phrase; one person instructs their computer to place the telephone call, the other instructs their computer to answer. Once the call is in progress, either user must press a key on their computer in order to speak, similar to using a hand-held radio. But unlike walkie-talkies, the users can interrupt each other. Could help criminals Such innovations could lead to conversations that would be practically foolproof from eavesdropping, either by pranksters or the government. It could become invaluable in future years to financial institutions and other corporations involved in sensitive negotiations. ''It will certainly be beneficial to many citizens and many other users of it,'' says Jim Kallstrom, assistant director of the Federal Bureau of Investigation's New York field office. ''I suspect that it also will be beneficial, unfortunately, to criminals. ''I would hope the extremely enterprising and smart people that we have in this country would work toward solutions that would not only protect the communication of citizens . . . but would also allow the law enforcement objectives to be maintained.'' Rubin stressed that while Nautilus was a challenge to write, it ''isn't rocket science.'' Much of the program, in fact, was assembled from parts that already were available on the Internet, the worldwide network of computer networks. It will even be easier to construct programs similar to Nautilus once Microsoft releases its computer telephony system for Windows 95. ''It will be impossible to keep a program like Nautilus out of the hands of people who want it,'' Rubin said. Gene Spafford, a professor of computer science at Purdue University who is an expert on computer security, said: ''It will be interesting to see what reaction this provokes from the government.'' Nevertheless, Spafford said, in order for encryption to be widely adopted, it will have to be ''built into the phones.'' Dorsey said that anybody in the United States who has Internet access can download the program. For the instructions, use the Internet FTP command to connect to the computer FTP.CSN.ORG. Change to the ''mpj'' directory and retrieve the file called README. Use a text editor to read the README file, which contains some fairly complex instructions on how to get the actual Nautilus file. This computer has been set up so that the program cannot be downloaded by people located outside the United States. ''I intend to follow all laws regarding the release of cryptography,'' he said. ------------------------------ Date: Wed, 10 May 1995 09:25:28 -0400 (EDT) From: jepstein@cordant.com (Jeremy Epstein -C2 PROJECT) Subject: Microsoft "Bob" passwords The May/June 1995 issue of InfoSecurity News reports that Microsoft Bob (Microsoft's "user-friendly" front end to Windows) has a "feature" that if you mistype your password three times in a row, it concludes that you've forgotten it, and asks if you want to change it. The Microsoft product manager says "It's not really an attempt at security" (no kidding!). If this is what "user-friendly" systems have to offer for security, I think I'll retreat to the world of paper tape and punch cards! --Jeremy Epstein, Cordant Inc. ------------------------------ Date: Thu, 11 May 1995 12:20:52 GMT From: psydoc@netcom.com (Ivan Goldberg) Subject: Internet Addiction [ Article crossposted from comp.multimedia ] [ Author was Ivan Goldberg ] [ Posted on Thu, 11 May 1995 12:14:59 GMT ] As the incidence and prevalence of Internet Addiction Disorder (IAD) has been increasing exponentially, a support group, The Internet Addiction Support Group (IASG) has been established. Below are the official criteria for the diagnosis of IAD and subscription information for the IASG. Internet Addiction Disorder (IAD) - Diagnostic Criteria A maladaptive pattern of Internet use, leading to clinically significant impairment or distress as manifested by three (or more) of the following, occurring at any time in the same 12-month period: (I) tolerance, as defined by either of the following: (A) A need for markedly increased amounts of time on Internet to achieve satisfaction (B) markedly diminished effect with continued use of the same amount of time on Internet (II) withdrawal, as manifested by either of the following (A) the characteristic withdrawal syndrome (1) Cessation of (or reduction) in Internet use that has been heavy and prolonged. (2) Two (or more) of the following, developing within several days to a month after Criterion 1: (a) psychomotor agitation (b) anxiety (c) obsessive thinking about what is happening on Internet (d) fantasies or dreams about Internet (e) voluntary or involuntary typing movements of the fingers (3) The symptoms in Criterion 2 cause distress or impairment in social, occupational or another important area of functioning (B) Use of Internet or a similar on-line service is engaged in to relieve or avoid withdrawal symptoms (III) Internet is often accessed more often or for longer periods of time than was intended (IV) There is a persistent desire or unsuccessful efforts to cut down or control Internet use (V) A great deal of time is spent in activities related to Internet use (e.g., buying Internet books, trying out new WWW browsers, researching Internet vendors, organizing files of downloaded materials.) (VI) Important social, occupational, or recreational activities are given up or reduced because of Internet use. (VII) Internet use is continued despite knowledge of having a persistent or recurrent physical, social, occupational, or psychological problem that is likely to have been caused or exacerbated by Internet use (sleep deprivation, marital difficulties, lateness for early morning appointments, neglect of occupational duties, or feelings of abandonment in significant others) Subscribe to the Internet Addiction Support Group by e-mail: Address: listserv@netcom.com Subject: (leave blank) Message: Subscribe i-a-s-g Ivan Goldberg, MD, 1346 Lexington Ave NYC 10128 212-876-7800 ikg1@columbia.edu psydoc@netcom.com http://avocado.pc.helsinki.fi/~janne/ikg/ ------------------------------ Date: 13 May 1995 11:48:49 -0400 From: "Marc Rotenberg" Subject: Re: more on CNID >From EPIC ALERT 2.04: Calling-Number-ID Blocking Fails in Pennsylvania and Wisconsin Following the disclosure by the New York Times that Calling-Number-ID blocking had failed in New York State, newspapers report that at least two other states have had similar problems with the controversial phone service. The Philadelphia Inquirer reported on March 1 that the phone numbers of more than 13,000 Bell Atlantic customers were improperly disclosed. Bell Atlantic did not inform the customers or the Public Utility Commission for several weeks, until they corrected the problem. The phone company described the problem as "human error" in many cases and a software programming error in others. The Pennsylvania PUC is investigating to see if Bell Atlantic violated state law by not informing customers of the error when it was discovered. Last month, after the NYNEX problems in New York State were uncovered, Ameritech revealed that nearly 1,000 customers in Wisconsin also were unprotected after signing up for the service. Marc Rotenberg, Electronic Privacy Information Center, 666 Pennsylvania Ave SE, #301, Washington, DC 20003 202-544-9240 ftp/gopher/wais cpsr.org ------------------------------ Date: Thu, 11 May 1995 13:55:22 -0500 From: dpmiller@mitre.org (David P. Miller) Subject: The Risks of trying to teach someone that doesn't want to learn STUDENTS SUE COLLEGE OVER COMPUTER COURSE (Edupage, 9 May 1995) Two students won the lawsuit they brought against New York's Pace University when an instructor for a beginner's course in computing gave a homework assignment the students thought was too hard: calculating the price of an atom of aluminum on Friday given such information as the price of aluminum on Wednesday, the rate change between the prices of the metal on Wednesday and Friday, the atomic mass of aluminum, the value of Avogadro's number (6.02 X 10 to the 23rd power), etc., etc. The students handled their own case against the university, and asked the teacher to answer such questions as: "Do you this was a good choice for a beginning class?" The judge decided: "Students are consumers. There is nothing holy or sacred about educational institutions." (Wall Street Journal 5/9/95 A1) The judge seemed to mistake the product of educational institutions as being the work that is given out (rather than the learning that results from doing the work). This article is short on details (did the rest of the class think this was hard? Was the grade in the course based heavily on this assignment? How was the course advertised?). But I cannot imagine the details that would justify the judge finding for the plaintiffs. (especially since, at heart, this is a trivial problem). The only excuse I can think of is that the judge (along with those students) perceives computers as inherently difficult, and therefore any course which is not obviously hand-holding the students must be fundamentally advanced. David P. Miller, MITRE Corporation, 7525 Colshire Drive, McLean, VA 22102 (703)883-7667 dpmiller@mitre.org http://www.ai.mit.edu/people/dmiller/dpm.html ------------------------------ Date: Mon, 8 May 95 10:18:52 +0200 From: Torsten.Lif@eos.ericsson.se (Torsten Lif - Cyberspace Cyclist) Subject: Cellular disturbances I have one to add to the recent article about cellular phones being banned from hospitals. A week ago, one of my fellow sysops had to reboot one of our SUN servers. He was installing some software on one server when his cellular phone rang and the console terminal (a VT220-clone) of another server started "hiccupping" badly. After he power-cycled it, the server had halted and wouldn't start without a full reboot. As he was sitting there staring at the row of consoles, his cellular phone rang (again) and another terminal crashed! This time it was sufficient to "c"ontinue the server so there was only a halt of a few seconds, but the implication is clear. We carry those cellular phones to be available quickly in case a server goes down. Instead, the phone was the cause of a crash. The new (European) digital "GSM" cellular standard produces lots of interference as can be heard on any radio or even HiFi amplifier within a few feet of a GSM phone in operation. An apparently "idle" phone next to any critical electronic equipment is a time-bomb waiting to go off since an incoming call to it automatically triggers bursts of transmissions as the phone acknowledges the call. This means that banning the use of them may not be enough - people don't tend to think of just carrying a phone as "using" it. They must be turned OFF. As an aside, the previous (analog) cellular standards did not cause nearly as much interference despite operating in the same 900 MHz band. At the worst, they might "blank out" radio receivers momentarily but we never observed them interfering with digital equipment. Now, the European Union is pushing GSM as its sole cellular standard and is trying to force operators to phase out analog systems to provide more channels for digital. I think we've only seen the tip of this iceberg yet... Torsten Lif, Ericsson Telecom AB Stockholm, Sweden Torsten.Lif@eos.ericsson.se ------------------------------ Date: Fri, 05 May 1995 21:29:54 -0400 From: marko@sinanju.jjm.com (Mark Moore) Subject: GPS Risks All of the talk of time recently reminded me of an article in the March/April 1995 issue of ``Ocean Navigator'' entitled `GPS-derived time baffles NOAA researcher' written by Dan Endres of the Climate Monitoring and Diagnostics Lab near Point Barrow, Alaska. In this article he discusses the discrepancies he discovered in time as reported by WWV and his Garmin GPS-50 receiver. He ``found a discrepancy of up to 1.5 seconds between the time readout of a Garmin GPS-50 and time as broadcast by WWV.'' He decided to compare several GPS receivers with a GOES synchronized clock and all of the GPS units showed the same problem. After a discussion of the differences between UT (UT0, UT1 (GMT), and UT2), ET, and AT he reports the assurances of the manufacturers that the GPS units report accurate UT. What his own testing found was that the GPS receivers would ``start out displaying time very close to the 486-DC (GOES sync'd clock), and within 15 minutes would drift to settle at between 1 and 1.5 seconds slow.'' After several additional phone calls, a technician (employer not mentioned) explains that there is indeed a software problem "and that all the manufacturers were aware of it but not sure how to fix it, or if it was even worth fixing because of the small error." The author explains the obvious risk of shipboard personnel relying upon GPS time for a high degree of accuracy. There are, of course, the usual additional risks of blindly relying on technology manufactured by people who are reluctant to admit to problems. The parallels to the Intel FPU situation are clear, though I expect no outcry from the GPS using population. They have other, bigger problems enumerated in earlier editions of RISKS. The moral is also the usual one: If the results matter, verify. Mark Moore, Technical Consultant (and novice celestial navigator) Renaissance Solutions, Inc. marko@sinanju.jjm.com Mark_Moore@rsg.com ------------------------------ Date: Fri, 12 May 1995 15:19:30 +0000 From: youngman@signal.dra.hmg.gb (neil youngman) Subject: GPS landing systems I was just reading about proposals for a GPS based Instrument Landing System to replace current systems (Scientific American, April 1995). One system disconnects the autopilot and sounds the alarm if it detects a problem with the GPS. I hope the captain is right on the ball if the autopilot suddenly disconnects at low level! It might be better to sound the alarm and let the captain override the autopilot? Neil Youngman ------------------------------ Date: Thu, 4 May 95 20:03:56 PDT From: eggert@twinsun.com (Paul Eggert) Subject: Problems with wrong assumptions about date conversion I see several problems with programs that arbitrarily reject dates before 1753, as Sybase does according to Matthew Healy in Risks 17.11. * Even if we restrict ourselves to 20th-century dates, it's unwise to expect a general-purpose database server to implement the local civil calendar accurately. Some parts of the world did not switch to the Gregorian calendar until as late as 1920. Should a database server in, say, Athens reject a 1915 birthday? * Even if we assume locations now in the USA, it's unwise to assume that 1753 is the correct cutoff date; Alaska did not switch to the Gregorian calendar until 1867. * Several countries switched to the Gregorian calendar as early as 1582, and it's incorrect to prevent historical applications in these countries from using early Gregorian dates merely because England hadn't switched yet. In general, it is easier to document, use, debug, and internationalize programs that assume the Gregorian calendar all the way back to at least the Year 1. Specialized applications requiring other calendars can do conversions as necessary, perhaps using standard conversion libraries. For more on this subject, including an extensive set of conversions between all sorts of calendars, please see the following references. Calendrical conversion routines by E M Reingold are widely available as part of GNU Emacs. N Dershowitz and E M Reingold, Calendrical calculations. Software--practice and experience 20, 9 (Sep 1990), 899-928. E M Reingold, N Dershowitz, and S M Clamen, Calendrical calculations II: three historical calendars. Software--practice and experience 23, 4 (Apr 1993), 383-404. ------------------------------ Date: 5 May 1995 12:01:28 -0600 From: wicklund@Intellistor.COM (Tom Wicklund) Subject: Re: Year 2000? Don't forget 1752! There's an additional risk from the fact that different nations switched calendars at different times. Catholic countries switched in the 1500's, but England didn't because at the time (Henry VIII and Elizabeth I) the reformation was in full swing and anything Catholic was bad. I saw a comment about this when studying the Spanish Armada. The Spanish dates will all be about 10 days off of the English, which creates problems comparing dates between the records of each country. ------------------------------ Date: Fri, 5 May 1995 09:36:42 -0400 (EDT) From: fc@all.net (Frederick B. Cohen) Subject: ASIS articles Webbed The American Society for Industrial Security's (ASIS) Security Management Magazine is now making select articles available on an experimental basis over World Wide Web. This WWW area is still under development, but you might want to read a fine article about the problems of erasing electromagnetic media no on-line in this area. The URL is: http://all.net:8080 ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.12 ************************ 18-May-95 17:02:27-GMT,27503;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA16883 for ; Thu, 18 May 1995 13:01:59 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id NAA05665 for ; Thu, 18 May 1995 13:01:55 -0400 Received: from chiron.csl.sri.com ([192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id NAA10335 for ; Thu, 18 May 1995 13:01:49 -0400 Received: by chiron.csl.sri.com id AA15561 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Thu, 18 May 1995 09:52:16 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 18 May 95 9:52:15 PDT Subject: RISKS DIGEST 17.13 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Thursday 18 May 1995 Volume 17 : Issue 13 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: "Double your fun" (CA lottery woes) (Bruce Findlay) AOL Used For Sting by Miami TV Station (David Tarabar) Marketing use of medical DB (Mark Seecof) Safeware: System Safety and Computers, Nancy Leveson (PGN) Computers, Ethics, & Social Values, Johnson and Nissenbaum (PGN) Building in Big Brother: The Cryptographic Policy Debate (Lance Hoffman) Microsoft plans corporate espionage (Chris Norloff) RISKS in Microsoft's Windows95 (identity withheld) Re: "Bob" passwords (Brian T. Schellenberger) 30 February 1712 (Tapani Tarvainen) Re: Intuit's Macintax security lapse... (Don Faatz) Re: "Nautilus foils wiretaps" (M. Vincent) Re: Cellular disturbances (David Woolley, Frederick Roeber) Re: Internet Addiction (Shawn Mamros, Rob Cunningham) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 16 May 1995 07:50:47 -0700 From: Bruce Findlay Subject: "Double your fun" (CA lottery woes) Excerpted from the local paper of record, the San Jose Mercury News [probably on 15 May 1995, which is when a similar item appeared in the San Francisco Chronicle. PGN]: Lottery computer gets ahead of itself California Lottery officials scrambled Sunday to make amends for a computer glitch that unexpectedly halted sales three hours early for the weekend's $3 million jackpot. By mistake, the computer began issuing tickets for Wednesday's upcoming drawing instead - causing anger and confusion for lottery players and retailers around the state... Lottery officials decided Sunday that players affected by the mix-up will have their tickets honored in both contests... Lottery spokesman said an employee of Sacramento's GTECH, which runs the lottery computer, was conducting routine maintenance when he mistakenly entered a command that closed the draw pool for Saturday's drawing. ...it wasn't clear how many tickets were sold during the three hours but GTECH has promised to make up any losses to the state. RISKS? Where do I start? Why was an employee able to disturb what is supposed to be an unriggable game? If GTECH does not know how many tickets were sold, how will the loss be made right? And since when does basic operator error mean the same thing as "computer glitch?" ------------------------------ Date: Tue, 16 May 95 11:23:26 -0400 From: dtarabar@hstbme.mit.edu (David Tarabar) Subject: AOL Used For Sting by Miami TV Station A Miami TV Station (WPLG) set up a sting operation on America Online that resulted in the resignation of a VP at the Denver Post. In an attempt to show how easily strangers can approach unsupervised children on online services, the TV station created an AOL user that pretended to be a 13 year old boy. A birthdate was clearly listed in a user profile and the 'boy' spoke like a 13 year old who liked swimming and skateboarding. A user named 'Ken4boys' spoke with this 'boy' in private chats and said that he would be coming to Florida soon, and asked, "How about a hot-oil massage from an older guy". Ken4boys did meet an actor at an agreed upon place, but within seconds found himself facing a TV camera and an investigative reporter. When this news story made it's way back to Denver, Ken resigned his position as VP of Marketing at the Denver Post. The anonymity of online personas seems a major risk here for all involved. The TV station was being fraudulent in its attempt to get a juicy sweeps week story. Still it is worrisome that they were able to find someone who appeared to use AOL to spice up his business trips. 'Ken4boys' also learned the danger of anonymity, but it is difficult to feel sympathy for him. I have been skeptical about the 'PCs are a danger to your kids' stories on local news, but this is an impressive example. I don't think that AOL is too happy about any aspect of this. ------------------------------ Date: Thu, 11 May 1995 14:28:00 -0700 From: Mark Seecof Subject: Marketing use of medical DB Under the headline "Eli Lilly Plans to Use PCS Unit's Database to Boost Drug Sales" the Wall Street Journal reported on page B6, May 11, 1995 that: "Eli Lilly & Co. sees big opportunities for expanding use of its Prozac antidepressant and other drugs by exploring the patient database it acquired with its $4 billion purchase of PCS Health Systems." (Errors in the summary here may be Mark Seecof's fault). Lilly's CEO Randall L. Tobias said that patients, as well as Lilly, would benefit from Lilly's trolling the PCS database of prescriptions for 56 million patients to find (a) patients whose prescriptions suggest that they may suffer from depression manifested as several other minor illnesses--Lilly will try to get doctors to prescribe Prozac for those patients; (b) patients who may be taking inadvisable combinations of drugs--Lilly will warn its pharmacists or doctors; (c) drug-treated diabetic patients who might be persuaded to take to Lilly's Humulin insulin product. (The story DOESN'T say) Lilly may find other ways to exploit the prescription billing data. For example, Lilly could use it to monitor other firms' pricing strategies. Or Lilly could match the data with other data--for example, Lilly could match prescription billing info against credit report or insurance (MIB) data then sell derivative information to people. (How many landlords will rent to tenants who have prescriptions for AZT?) Various privacy laws may restrict some of the possible uses of the data. But none of them will protect the people whose medical condition can be estimated from the record of the drugs prescribed for them from unscrupulous marketers at Lilly or even faithless clerks at Lilly willing to take bribes from, say, skip tracers. I think that Lilly's plan to push Prozac on people with "backaches and sleeplessness" (direct quote from Tobias) is unethical and risky. Mark Seecof ------------------------------ Date: Wed, 17 May 95 19:10:38 PDT From: "Peter G. Neumann" Subject: Safeware: System Safety and Computers, Nancy Leveson If you have ever been seriously concerned with developing systems that must satisfy stringent safety requirements, or expect to be sometime in the future, you MUST read this book. Just published, it is immediately the definitive work on software safety, and has a system perspective that is really important. After careful consideration of the fundamentals, requirements analysis, hazard analysis (including models and techniques), and human interfaces are examined with loving care. Many cases familiar to RISKS readers (Therac-25, Apollo 13, the Challenger, Bhopal, Three Mile Island, Chernobyl, and others) are treated in considerable detail in the appendices, and much new information is revealed. The book is useful as a course text and as a guidebook for safety engineers. And it all fits in 680+xvii pp. Your Risks Moderator says check it out. Author = {Nancy G. Leveson}, Title = {Safeware: System Safety and Computers}, Publisher = {Addison Wesley, Reading, Mass 01867-3999}, Year = {1995}, Note = {ISBN 0-201-11972-2} ------------------------------ Date: Wed, 17 May 95 18:58:16 PDT From: "Peter G. Neumann" Subject: Computers, Ethics, & Social Values, Johnson and Nissenbaum Deborah G. Johnson and Helen Nissenbaum have come up with a superb book, collected from a bunch of friends and colleagues with long experience and interesting views on the titled subject. This book is absolutely essential for anyone concerned with ethical issues related to the use of computers, and should also be read by anyone not clear on the issues. I won't list all the chapters and contributors, but it is a fine selection. Author = {Deborah G. Johnson and Helen Nissenbaum}, Title = {Computers, Ethics, & Social Values}, Publisher = {Prentice Hall, Englewood Cliffs, NJ 07632}, Year = {1995}, Note = {ISBN 0-13-103110-4} ------------------------------ Date: Thu, 18 May 1995 04:48:10 -0400 (EDT) From: "Lance J. Hoffman" Subject: Building in Big Brother: The Cryptographic Policy Debate A collection of readings with commentary by Prof. Lance J. Hoffman (The George Washington University) has now been published by Springer Verlag. >From a publisher's blurb: "...This book presents the best readings on cryptographic policy and current cryptography trends. ... Detailed technological descriptions of promising new software schemes are included as well as analysis of the constitutional issues by legal scholars. Important government cost analyses appear here for the first time in any book. Other highlights include the text of the new US digital telephony law and the pending encryption regulation bill and a list of hundreds of cryptographic products available around the world. There is even a paper on how to commit the perfect crime electronically, using public key encryption. Much more detailed information and a table of contents is available by pointing your Web browser to http://www.seas.gwu.edu/seas/instctsp/docs/book 560 pages, 19 illustrations, softcover $29.95 ISBN 0-387-94441-9 Call 1-800-SPRINGER to order, email orders to orders@springer-ny.com Professor Lance J. Hoffman, Dept of Elec Eng and Comp Sci, The Geo Washington U, 801 22nd St NW, Wash DC 20052 (202) 994-4955 ------------------------------ Date: Wed, 17 May 95 13:44:40 EDT From: cnorloff@tecnet1.jcte.jcs.mil Subject: Microsoft plans corporate espionage Microsoft officials confirm that beta versions of Windows 95 include a small viral routine called Registration Wizard. It interrogates every system on a network gathering intelligence on what software is being run on which machine. It then creates a complete listing of both Microsoft's and competitors' products by machine, which it reports to Microsoft when customers sign up for Microsoft's Network Services, due for launch later this year. "In Short" column, page 88, _Information Week_ magazine, May 22, 1995 The implications of this action, and the attitude of Microsoft to plan such action, beggars the imagination. Chris Norloff cnorloff@tecnet1.jcte.jcs.mil [Also reported by jyoull@cs.bgsu.edu (Jim)" and herzog@uask4it.eng.sun.com (Brian Herzog - Sun Microsystems, Inc.). The following analysis was also sent to RISKS by a contributor who requested anonymity. PGN] ------------------------------ Date: Wed, 17 May 95 12:22 xxT From: [identity withheld at submitter's request] Subject: RISKS in Microsoft's Windows95 Sometime in the latter part of the summer, Microsoft is planning to release their Windows95 follow-on for Windows 3.1 to the masses. Whether the effort required to keep things working after installing the release vs. the perceived benefits of Win95 makes the installation a sensible decision is quite an open question. Reports from beta testers are indicating that even for Windows experts, getting their system running again after the upgrade can be a bad experience, given the wide variety of complex hardware, drivers, and other components that have been integrated into Windows 3.1 environments over the years. For Windows users who are less than experts, the problems risk being even more serious, with various applications (or even entire systems) effectively useless without various "tweaks", fixes, new drivers, new software, etc. In other words, the backwards compatibility of Win95 in the real world of people's existing Windows 3.1 installations should be an issue of grave concern, especially among users concerned about prolonged downtime. We may be reaching a stage where the sheer complexity of PC application software and hardware is making the entire concept of major operating system upgrades being installed successfully by average users extremely problematical. It seems very likely that large numbers of Windows 3.1 users will (or at least should) be extremely cautious about being an early adopter of Win95. Bya the way, here's a new feature announced for Win95 that carries new RISKS of its own. Called "AutoPlay" it is apparently a feature of the Win95 CD-ROM driver that allows CD-ROM authors to create a special init file on the disc that will automatically start running programs from the disc as soon as a disc is inserted into the CD-ROM drive. From the descriptions available so far, there doesn't seem to be a system-wide way to disable such a feature, you have to remember to hold down the shift key on your keyboard while inserting the disc to disable it for that particular insertion (apparently folks with remote keyboards might just be out of luck!) What sorts of harm could come from autoloading of CD-ROMs? Outside of the obvious malicious applications (don't laugh, CD-ROMs are getting so cheap to produce that all manner of nasties could be planted on purpose or by accident), there's the obvious problem that most PC CD-ROM applications need considerable software and disk support, often involving significant use of disk space, changes to system-wide configuration and other driver data, etc. It is not unusual for these changes to conflict in some manner with other programs and installations, needing manual intervention. At least when you do the installation manually you can stop, look for README files, etc. before starting the guts of the install, but if the CD-ROM fires off on its own there's no telling what might happen. True, a reasonable CD-ROM author would query the user about this process rather than running off and starting the install without user input, but it's probable that many authors who want things to look "slick" won't bother with this. In fact, Microsoft seems to be encouraging the "slick" attitude in their description of this feature. Another point. You're about to start seeing music CDs that carry CD-ROM programs and data on the initial part of the disc before music track 1. If such discs tried to make use of the Win95 AutoPlay feature, an unsuspecting user who stuck the music disc into his or her CD-ROM player planning to hear only music (lots of PC users play music CDs on their CD-ROM drives these days) could end up getting a lot more than bargained for. ------------------------------ Date: Tue, 16 May 1995 13:36:02 GMT From: bts@unx.sas.com (Brian T. Schellenberger) Subject: Re: "Bob" passwords (Epstein, RISKS-17.12) |if you mistype your password three times in a row, it concludes that you've |forgotten it, and asks if you want to change it. It's easy to make fun of this scheme, but *I* think it's a pretty good approach. This is equivalent of the foil on your vitamins: Not tamperproof protection, but tamper-*evident* protection. This avoids the problems of users who aren't accustomed to password forgetting them and getting locked out, saving Microsoft technical support a lot of hassle. It is intended for home computers, which as a rule are not widely accessible to the public, and don't have any password protection currently. And it's part of a program whose "job" is not security, but user assistance; it would be inappropriate to add security in such a program that might lock people out of their computer. On the other hand, a scheme that makes it evident if somebody has been mucking around on the computer is a handy feature, and that's just what has been achieved here. (Whether or not the product manager and/or development team realizes it.) I think there is a RISK in assuming that all security must be maximal. (Not to downplay the RISK in not advertising this for what it is, if that's what Microsoft is doing.) Brian T. Schellenberger SAS Institute Inc. R2266 919-677-8000 x7783 [It also provides a seeming denial of service opportunity, enabling an attacker to change EVERYONE's password. But then even that would not matter. This is almost as good as having NO passwords. Chances are no one would ever bother to look at the audit trail anyway, because in the absence of meaningful authentication, the accountability is next to worthless. PGN] ------------------------------ Date: 14 May 1995 17:42:30 GMT From: tt@tarzan.math.jyu.fi (Tapani Tarvainen) Subject: 30 February 1712 (Re: Wicklund, RISKS-17.12) >There's an additional risk from the fact that different nations >switched calendars at different times. Indeed. Sweden adopted the leap-year rule of the Gregorian calendar in 1700, making it a non-leap year, but without adjusting the calendar otherwise, so that after that Sweden was out of sync with both Julian and Gregorian calendars. After a while they discovered it was not such a great idea, and in 1712 Sweden moved back to Julian calendar by adding an extra day to February, resulting in the unusual date of 30 February 1712. One should be careful in rejecting "impossible" dates... Tapani Tarvainen ------------------------------ Date: 10 May 1995 01:11:42 GMT From: don_faatz@rpi.edu (Don Faatz) Subject: Re: Intuit's Macintax security lapse... Unfortunately, it doesn't take a software screw-up to mess up electronic income taxes. My boss has had a Compuserve account for a few years. Each year at tax time, he receives several people's tax returns in his Compuserve e-mail. His Compuserve E-mail address is one character different than the address of some company that offers an electronic filing service via Compuserve. He has contacted both Compuserve and the vendor - neither were interested in trying to solve the problem. The returns are encrypted in some way ... ------------------------------ Date: Tue, 16 May 1995 11:01:57 +0100 (BST) From: "(aardvark)" Subject: Re: "Nautilus foils wiretaps" (Garfinkel, RISKS-17.12) Simson points out that the software is only available to the US. Now I may not be the cleverest person in Europe, but I do have an account on a FreeNet site in the US which for the moment will remain nameless. Now really, what is to prevent me downloading nautilus to my free-net and from thence to home. Note that I am NOT indicating that I am about to do this, but it's a valid RISK - isn't it! Malcolm Vincent (m.vincent@qub.ac.uk) ------------------------------ Date: Wed, 17 May 95 23:53 BST From: david@djwhome.demon.co.uk (David Woolley) Subject: Re: Cellular disturbances (Lif, RISKS-17.12) >The new (European) digital "GSM" cellular standard produces lots of >interference as can be heard on any radio or even HiFi amplifier The risks here are of confusing the behaviour of faulty equipment of one type with there being a fault in another piece of equipment, and of generalising that to the behaviour of faulty equipment of a third type. Also there is a risk of only seeing one side of a two sided problem. The fault resulting in the "interference" here is in the amplifier, which is acting as a radio receiver, or the radio receiver which is receiving on a completely wrong frequency. (The chances are that the radio isn't even receiving the interfering signal through its aerial.) The transmitter can be transmitting a signal which is perfectly contained within its allocated band, and still generate this effect. A lot of modern electronics could be made radio immune, but isn't, to save a small fraction on the price. The complex digital logic in a GSM mobile is immune to its signals from only a few inches away. The generalisation is the assumption that audio frequency interference in an AC coupled device will have the same impact on a DC coupled device working at 1000s of times the frequency. In fact, a radio signal which produced no audible effect at all, might still cause misoperation of a computer. The other side of the coin is that computers which are susceptible to radio transmissions, are usually very good radio transmitters themselves. Even PCs, which are designed for domestic use, can cause severe interference to shortwave receivers, which cannot be cured by modifications to the receiver (remote aerials apart). The Sun in this case, probably wasn't designed to the same standard, so would generate even more interference. It is possible that GSM transmissions are more likely to jam susceptible electronics, but this is not directly related to the audible effect on faulty amplifiers, but might be the result of using higher peak powers, although both may be the consequence of using time division multiplexing. David Woolley, London, England david@djwhome.demon.co.uk ------------------------------ Date: Mon, 15 May 1995 21:53:09 +0200 From: roeber@cern.ch Subject: Re: Cellular disturbances (Lif, RISKS-17.12) Oh, wonderful! At CERN we're replacing our beeper system with GSM phones. This has some nice side effects, especially when you drive in merely to discover a machine needs rebooting. But of course, most of the folks with beepers or phones are going to be the ones on piquet duty -- the ones who have to go in and fix the balky computers, networks, delicate equipment, or (best of all) those enormous, incredibly sensitive, bleeding-edge particle detectors. And of course there's always some idiot who calls you up half an hour into a tricky procedure to ask, "How's it going?" "Well, it *was* going great, but now that you ask..." Frederick Roeber roeber@cern.ch ------------------------------ Date: Sun, 14 May 95 20:50:45 EDT From: mamros@ftp.com (Shawn Mamros) Subject: Re: Internet Addiction (Goldberg, RISKS-17.12) If one admits to the existence of "Internet addiction" as a real problem (and it very well might be for some people), it would seem to me that putting together a support group using an *Internet mailing list* (thus encouraging continued use of the 'net, as opposed to therapy involving spending time *away* from the 'net) would be precisely the *wrong* way to help these people out... -Shawn Mamros mamros@ftp.com ------------------------------ Date: Mon, 15 May 95 09:28:10 EDT From: rkc@xn.ll.mit.edu Subject: Re: Internet Addiction (Goldberg, RISKS-17.12) In the most recent RISKS-17.12, Dr. Ivan Goldberg helpfully announced a support group for Internet Addiction. Am I the only one who finds it ironic that one needs access to the Internet to participate in this support group? It seems that even if this group is successful in reducing other Internet use, the user will continue to use the Internet via e-mail to this account. Is this similar to announcing a support group that gets together to drink beers and discuss their addiction to alchohol? -Rob [merlyn@stonehenge.com (Randal L. Schwartz) and "F. Barry Mulligan" both likened it to holding an AA meeting in a bar. PGN] ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.13 ************************ 19-May-95 18:59:57-GMT,31705;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA11734 for ; Fri, 19 May 1995 14:59:54 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id OAA23455 for ; Fri, 19 May 1995 14:59:52 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id OAA01212 for ; Fri, 19 May 1995 14:59:46 -0400 Received: by chiron.csl.sri.com id AA16703 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Fri, 19 May 1995 11:50:53 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 19 May 95 11:50:52 PDT Subject: RISKS DIGEST 17.14 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Friday 19 May 1995 Volume 17 : Issue 14 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ************ Probably NO RISKS ISSUES NEXT WEEK ************ Contents: Positive-Ion Dangers: Computers and stress / depression (Dan S) Automated Loan Applications (Rick Russell) The Risks of random PINs (Bill Fenner) Denial of Service attack at AOL (Ben Blout) Computer-controlled lock failure in hotel (Rick Simpson) Same scam, new venue (Bob Frankston) Name matching, again... (Bob Frankston) Nielsen, others to rate Internet, related RISKS (Mark Seecof) Integrity of archived data, standards for media retirement (Patrick Casey) Re: Year 2000? Don't forget 1752! (Melvin Klassen) Date and time and MS-DOS (Erling Kristiansen) RISKS in Microsoft's Windows95 (Steve Loughran) Re: Microsoft plans corporate espionage (Raymond Chen) SAFECOMP 95 (Martyn Dowell) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: 17 May 1995 15:53:24 -0400 From: daniels222@aol.com (DanielS222) Subject: Positive-Ion Dangers: Computers and stress / depression As an engineer who spent 12 hour days programming Fortran in college, and who now sits in front of a computer all day at work, I thought this would be of great interest to you. On 2/14/95 CBS Evening News with Connie Chung, Dr. Bob Arnot did a story about negative ions and their effect on mood. They talked about a study done at Columbia University where exposure to a high density negative ion generator was as effective in treating winter depression as medication. I became very interested because I have suffered from depression and anxiety for years, and I did extensive research on the benefits of negative ions. This research turned out to be especially interesting to me because I found a newspaper article discussing the fact that computer monitors emit positive ions - the opposite of negative ions. In the article, a consultant to the FDA says that computer monitors give off large amounts of positive ions and can actually cause depression, stress, fatigue, etc. in people who sit in front of computers a lot - like all of us Netters - and that we need negative ion replenishment. After reading the newspaper article, I realized that I always felt especially irritable, stressed, and depressed after long days in front of my computer. In doing the research, I found that negative ions have shown to be therapeutic for stress, irritability, fatigue, depression, etc. So I purchased a small, high density generator and it has given me substantial relief from my symptoms. If any of you would like me to e-mail you that newspaper article, the transcript of the CBS news story, as well as the other research that I have compiled, just e-mail me at DanielS222@aol.com. -dan ------------------------------ Date: Thu, 18 May 1995 14:54:55 -0500 (CDT) From: wrr3118@h2o.tamu.edu (Rick Russell) Subject: Automated Loan Applications Headline News reported today (18 March 1995) that the nation's two largest home mortgage underwriters, Fannie Mae and Freddie Mac, will shortly be deploying computer systems that will allow for instantaneous analysis of one's loan application. It appears that, given a user's name, recent paycheck stub, W-2 form, appraisal etc, the system will perform automated checks and approve mortgages without the intervention of a human underwriter. "The machine never says no," we are told, if a loan application is "questionable" it is referred to a human underwriter for review. I guess the RISKS are obvious, but I'll state them anyway -- if business is good, and the human underwriter feels like playing golf instead of reviewing loans, the loan application may be "referred" to the circular floor-mounted file cabinet with no substantive explanation to the applicant. The news story didn't mention whether the algorithm used some simple set of minimal requirements, or if a neural net or expert system was involved. If the latter, an even larger and potentially nastier set of RISKS are apparent. Rick R. rick-russell@tamu.edu ------------------------------ Date: Tue, 16 May 1995 10:59:30 PDT From: Bill Fenner Subject: The Risks of random PINs I received a letter in the mail the other day from my credit card company, kindly informing me that I can get cash with my credit card from any ATM, and that they had selected a nice random PIN for me. Lo and behold, the randomly-selected number was my birthday! I called the credit card people up, and the operator was somewhat amused, as she claimed that the number was "picked by a computer" and it was an "amazing coincidence" that it was my birthday. I asked them to pick me a new random PIN, and just yesterday received a new letter from the bank with my new random PIN, which was exactly the same as my old random PIN. Would it really cut the random number space down too far to remove all "obvious" dates? Heck, in this day and age, they probably *know* my birthday... Bill ------------------------------ Date: Tue, 16 May 1995 01:59:12 -0400 From: Blout@aol.com Subject: Denial of Service attack at AOL I learned the hard way that one can apparently cancel the account of any AOL (America On Line) member with a simple phone call. About two weeks ago I suddenly could not log on to AOL. Following the on-screen directions, I called the 800 number for customer service. A nice gentleman there explained that someone had called in earlier in the day and asked for my account to be canceled. It was! This was even though the person calling could not (according to AOL's own records), provide the credit card number used to pay for the account as verification of their identity. The gentleman helping me also volunteered that an account could be canceled by leaving after-hours voice mail at the customer service number. My woes were exacerbated by an error made when my account was reactivated. My account was reactivated 10 minutes after my phone call, but my incoming mail service was not turned on for an additional week. I had to make a second (30 minute) phone call to correct this, and wait another day. The total lack of verification of who is calling seems to be a poor policy. What if I had not logged in for three weeks? I would have lost three weeks of RISKS! I tried to suggest that they leave incoming mail enabled for a few weeks after an account is cancelled without complete verification. The people I spoke to didn't seem too interested. -Ben Blout ------------------------------ Date: Tue, 16 May 95 11:08:05 -0500 From: "Rick Simpson" Subject: Computer-controlled lock failure in hotel When I checked into my hotel on a recent business trip, I was told that the hotel was "having a problem with the locks" and that my room would be re-keyed sometime the next day. The room locks in this particular hotel use plastic cards with magnetic stripes rather than traditional metal keys. Sure enough, when I came back the next evening my key wouldn't work; the room had been re-keyed. The hotel sent a security person up to let me in and give me a new key. He was unable to open the door: the new key didn't work, nor did any of his master keys. More security people came, more master keys, same result; the door would not open. Next to arrive were the maintenance people with the lock re-keying device. This turned out to be a lap-top computer with a special adapter attached to the serial port. The locks, it seems, contain battery-operated microcontrollers. Re-keying consists of inserting a special master key, then a second special master key, and then the lap-top computer's re-keying adapter. The lap-top then communicates with the processor in the lock and causes it to register a new key code. All this was to no avail -- the lock failed to open regardless of what key was inserted, whether ordinary room key or master key. Eventually the maintenance people had literally to break into the room. In discussions with the security people, I learned that what started all this off was a head crash on a disk. The hotel had lost track of which key codes went with which rooms because of the unreadable disk. As a result, the front desk couldn't just "write" new keys as guests checked in. The hotel started the process of re-keying all the locks in order to create a new key code file. This worked OK for all but a couple of the 600+ rooms, mine being one of the failures. Risks? Obviously, not having a usable backup for the crashed disk is the first risk. This cost the hotel lots of employee-hours and some ill will from frustrated guests, not to mention the physical damage to the door of my room caused by breaking in. The more subtle risk is in the locks themselves. I had stayed in this hotel many times before, but I had not noticed that the locks operated ONLY on magnetic stripe cards. Many such mag-stripe locks in hotels also have a traditional, mechanical lock that can be used by the cleaning and security people even if the mag-stripe mechanism fails completely. These locks had no such redundancy. I'm surprised that the hotel would ever allow itself to be in the position of being unable to enter a room in an emergency due to the simple failure of a battery-operated lock controller, other than by breaking down the door. Rick Simpson, IBM T. J. Watson Research Center, P.O. Box 704, Yorktown Heights, NY 10598 +1 914 784 6712 simpson@watson.ibm.com ------------------------------ Date: Sat, 13 May 1995 19:49 -0400 From: Bob_Frankston@frankston.com Subject: Same scam, new venue >From the New York Times One 29-year-old woman in Brooklyn in the Home Relief welfare program was sent more than 200 checks totaling $350,000 over seven months, prosecutors said. Five other got $96,950 to $246,925 each, according to the authorities, who said the welfare recipients then shared the money with the clerks. By yesterday evening, 62 welfare recipients were under arrest and more than 30 were being sought. [...] "It was very easy for the data entry person to do this because there were absolutely no controls or checks on the computer system," said Howard Wilson, the Commissioner of the City's Department of Investigation, which began the inquiry 18 months ago. "That corrupt employee being at that critical point in the process was able to literally push the button and out came the money." Prosecutors would not discuss many aspects of the scheme, including how the clerks and the welfare recipients started working together. The risks are obvious, but how much is it a risk of technology vs standard procedure? Would a supervisor have been more likely to check in a manual system? Is there more leverage for fraud in the computer-based system? Or is it just one more example of lax procedures. One can, in fact, argue that much of the value in computerizing a system is doing a critical evaluation of existing and new procedures. This step seems to have been omitted in this case. ------------------------------ Date: Wed, 10 May 1995 16:35 -0400 From: Bob_Frankston@frankston.com Subject: Name matching, again... US News & World Report, May 15th had a story about a known terrorist being granted a visa because there wasn't a match on his name in the State Department's database. To quote the article: "The State Department, which issued Khalifa his visa, declines to discuss the case. A knowledgeable official says that when the U. S. Embassy in Riyadh ran a check to see if its computer would flag Khalifa's name on the State Department's terrorism watch list, it failed. The problem is the English rendering of Arabic names. One State Department official explains, "Mohammad has several different spellings in English." (My spelling checker had Mohammed). The risks are obvious especially when compared with the small costs for better (but not perfect) matchin. The more interesting question is the process by which these things happen. There has been lots of government-sponsored research into far more difficult problems. Why does this knowledge not extend to critical systems outside the well funded security services? Perhaps for the same reasons that our air traffic control system is a creaky antique. Usual caveat: the news article might be wrong and maybe there are entirely different issues here. With very nonEnglish common names and mixed standards for identification, the problem is more difficult than just soundex. ------------------------------ Date: Thu, 18 May 1995 17:05:20 -0700 From: Mark Seecof Subject: Nielsen, others to rate Internet, related RISKS In an article by Susan Carey headlined "Three Market Researchers Team Up to Provide Data for On-Line Services" the Wall Street Journal reported on page B7, Wednesday 17 May 1995, that ``Three of the nation's leading market-research concerns have teamed up to develop research services for the on-line world.'' (Errors in the following summary may be M. Seecof's fault.) Since measuring ``hit rates'' on WWW pages and like resources isn't a very effective or very informative method of measuring interest or usage (especially with large ISP's planning to cache data from popular servers to improve response time to their customers--effectively masking such usage from the real providers--and, BTW, the copyright and other issues here deserve a separate discussion to which I hope to contribute at another time), Neilsen Media Research (yes, the TV ratings folks), Yankelovich Partners, and ASI Market Research plan to develop and deploy means of measuring first WWW and later other kinds of Internet resource usage and provide such information to clients. Their joint venture is called ANYwhere Online. (The article did NOT say...) I think this is interesting. Ideally, one wants data not just from servers instrumented by ANYwhere Online (hereinafter ANY-O) but from other servers as well. In the TV world, Neilsen measures usage of all servers (TV stations/videotape) by a sample of the client population and extrapolates by statistical inference to usage by the whole client population. One could certainly do this in the Internet world. But consider another tactic. One could instrument Internet routers or links and measure traffic to various destinations. I suspect that Bill Gates intends to instrument UUNET/AlterNet's backbone to gather data on his competitors. For a fee, he could provide a digest of such information to ANY-O (or anyone). Other commercial ISP's could do likewise. This kind of traffic analysis could be exploited for commercial or other purposes. I look forward to learning from ANY-O whether they will use TV/ radio-measuring tactics, data from selected servers, data from backbone traffic analysis, or some combination. I would like to point out what I see as a big RISK for people who don't want their traffic analyzed (whether for personal, or commercial-competitive reasons): no current commercial ISP promises NOT to collect and sell information about net usage by customers. We can use end-to-end encryption (e.g., PGP) to limit content snooping by ISP's but typical public-access or commercial services, via e.g., WWW protocols use cleartext. Even if we expect the quantity of such traffic to hamper content-snoops, traffic analysis by or with the cooperation of ISP's could have grave competitive or privacy implications. I think that commercial Internet users should demand privacy clauses in their contracts with ISP's *NOW*, because tomorrow it'll be too late. Mark Seecof My employer may not share my opinions. ------------------------------ Date: Mon, 15 May 1995 10:23:44 -0600 From: jpcasey@indiana.edu (Patrick Casey) Subject: Integrity of archived data, standards for media retirement A few months ago, our computing organization invited our EDP auditors in to have a look at backup procedures. One of the findings in the auditor's report was "there are no established procedures for preservation of magnetic media to provide assurance of the long-term integrity of archived data. Also, no written standards exist that denote when specific types of magnetic media are to be retired. The only procedure observed is that generally magnetic media are not reused if a read or write error has occurred." We are wondering what other organizations have in the way of established procedures to provide assurance of the long-term integrity of archived data, and standards on when specific types of magnetic media are to be retired. Any comments or suggestion would be greatly appreciated. Patrick Casey, Indiana University, University Computing Services, 750 North SR 46 Bypass, Bloomington, IN 47405 (812) 855-8745 jpcasey@indiana.edu ------------------------------ Date: Tue, 9 May 95 17:11:12 PDT From: klassen@sol.uvic.ca (Melvin Klassen) Subject: Re: Year 2000? Don't forget 1752! (RISKS-17.11) Switch to the SAS(r) software. It correctly calculates back to 1582 AD, nearly 200 years "better" than Sybase(r) software. ------------------------------ Date: Tue, 9 May 95 09:50:23 +0200 From: erling@wm.estec.esa.nl (Erling Kristiansen) Subject: Date and time and MS-DOS I was recently plotting some data originating from a measurement and data logging program on a PC under MS DOS. To my surprise, the time on my plot was not increasing monotonously; rather, it was occasionally jerking backwards by a considerable amount for a single data point. I took a look at the raw data file to try to discover what happened. It appeared that the first data point after each midnight (the test was running for several days) still had the date of the previous day. I consulted the author of the software who gave the following, rather alarming explanation: In DOS, the time and the date are updated by separate interrupts. The time update has higher priority than the date update (I wonder what the logic behind the different priorities is?? The only explanation I can think of is: The date is updated less frequently, so it has less priority, which is not a very sound reasoning). It is, therefore, possible to read out the date and time at a moment just after midnight where the time has been updated, but the date is still the old one. In our application, a measurement is triggered at given times, one of which is exactly midnight. The measurement generates a lot of activity for a few seconds, preventing the date interrupt from getting served for some time. As a result, the first measurement of each new day consistently has the time 00:00:06, and the date of the previous day. Our application is probably rather exceptional in allowing the wrong day to persist for seconds. More common applications may only see this for milliseconds or microseconds, so not many people are likely to ever see the problem. (We could get into a long discussion, similar to the Pentium arguments, whether this is good or bad. I will spare you this). I will also spare you a discussion of possible work-arounds. What remains is the amazing fact that anybody can dream up a system in which the updating of date and time is not an atomic operation. ------------------------------ Date: Fri, 19 May 1995 12:01:31 +0100 From: "Steve Loughran" Subject: RISKS in Microsoft's Windows95 I've been using win95 for over year now, so can probably make some fairly accurate comments. Firstly, I don't know about the "Registration Wizard", but that's because I can't connect to the Microsoft Network. It seems that whoever entered the table of area codes got Bristol's revised code wrong. Secondly, the latest beta releases are a lot easier to install than the early builds, and a lot of legacy hardware and software does work -more than with Windows NT for example. It is of course useful to have a sheet of paper listing your IP address, subnet mask and DNS server, because you will be asked these questions near the end of the installation, when it is too late to look at the old files to find these facts out. Finally, Autorun does seem a nice concept, and certainly for home users it makes sense in terms of ease of use. It's cool for audio disks. It is claimed to work on any "disk drive" which supports removable media and automatic insertion notification. That means CD-ROMS, PCMCIA Cards and perhaps floppy drives on "Windows 95" PCs which can indicate the presence or absence of a floppy disk. Now personally I like the idea of scanning a new disk for viruses, even if it does take forever on a large CDROM, so was a bit unhappy about the concept of autorun disks. After a bit of research I found that there is an entry in the Registry which lets you choose which program gets run, or possibly disable autoplay altogether. So in fact it may be possible to configure autoplay to run a virus scanner over every new disk... -Steve References (relevant quotations on request): Windows 95 guide to programming Microsoft Developer Network CD, April 1995 [Disclaimer: Windows 95 is still only in Beta, so any details which I or anyone else provide about it may not be valid by the time the product is released.] Steve Loughran Hewlett-Packard Laboratories, Bristol, UK slo@hplb.hpl.hp.com +44 (117) 922 8717 ------------------------------ Date: Thu, 18 May 1995 18:09:15 -0700 From: raymondc@microsoft.com (Raymond Chen) Subject: Re: Microsoft plans corporate espionage "In Short" column, page 88, _Information Week_ magazine, May 22, 1995: : Microsoft officials confirm that beta versions of Windows 95 include a : small viral routine called Registration Wizard. The word `viral' here is quite inappropriate. Moreover, the column makes it seem as if this information is collected covertly and secretly uploaded. Here's what happens, or at least, what happens today. (Things might change before the final release.) When you select "Online Registration", the "Registration Wizard" fires up and asks you the same sorts of questions that would be asked by a paper registration form: name, address, etc. It then does a hardware scan, displays its findings, and asks you, "Do you wish to include this information with your registration?" Then it does a software scan of the local machine (not "every system on a network" as originally reported), displays its findings, and asks for the same confirmation to upload. This is all quite explicit, and users are required to confirm whether or not to include the information in the registration. There is no default response, so an inattentive user cannot just keep hitting Return and end up uploading the information by mistake. After the questions are answered, additional prompts and confirmations appear before the phone is dialed. Other points for debate/discussion: There is no way to edit the hardware or software inventory. So if the hardware or software list is incorrect or contains information that you'd rather not upload (e.g., beta hardware or software), your only recourse is to suppress the information entirely. [As is customary here, Raymond's extensive disclaimers have been deleted by PGN, but are globally implied by the standard RISKS info item.] ------------------------------ Date: 19 May 95 15:04:15 +0000 From: Martyn.Dowell@jrc.it Subject: SAFECOMP 95 The 14th International Conference on Computer Safety, Reliability and Security Villa Carlotta, Belgirate, Italy 11-13 October 1995 Sponsors: European Workshop on Industrial Computer Systems Technical Committee 7 (EWICS TC7) and European Commission Joint Research Centre - Institute for Systems Engineering and Informatics (JRC-ISEI) Co-Sponsored by IFIP Technical Committee 5 WG 5.4 and OCG, the Austrian Computer Society. Organized by the European Commission - Joint Research Centre, and Institute for Systems Engineering and Informatics. Safecomp is an annual event which reviews the state of the art, experiences and new trends in the areas of computer safety, reliability and security. Safecomp was initiated by EWICS TC7 (European Workshop on Industrial Computer Systems, Technical Committee 7) in 1979 and since then has been held in Germany (Stuttgart, Fulda), UK (Cambridge, Manchester, Gatwick), USA (West Lafayette, Anaheim), Italy (Como), France (Sarlat), Austria (Vienna), Norway (Trondheim), Switzerland (Zurich), Poland (Poznan). The conference focuses on critical computer applications. It is intended to form a platform for technology transfer between academia, industry and research institutions. Safecomp is a one-stream conference and typically attracts up to 150 participants. ADVANCE PROGRAMME (preliminary) Wednesday, October 11 09:15 Invited presentation : A. Servida (EC) : Dependability of safety-critical applications in the IT Programme of the European Commission. 09:45 GENERAL ISSUES, GUIDELINES E. Schoitsch (A): Software Best Practices in dependable systems: The European Research Projects: ENCRESS, OLOS, ESPITI from the partners' perspective. H. Krebs (D) : Assessment on the basis of standards - Gaps and how to bridge them 11:15 SAFETY ANALYSIS A. Saeed, R. de Lemos, T. Anderson (UK) : Safety Analysis for requirements specifications: Methods and techniques M. Chudleigh, J. Catmur, F. Redmill (UK) : A guideline for HAZOP studies on systems which include a Programmable Electronic System J.M. Voas, K. W. Miller (USA) : An automated code-based fault-tree mitigation technique 14:15 FORMAL METHODS C. Fencott, B. Hebbron, K. Chan (UK) : Formal support for the safety analysis of requirements model J. Gorski, J. Magott, A. Wardzinski (PL) : Modelling fault trees using timed Petri Nets I. D. R. Shannon, A.J. Harrison (UK) : The application of formal methods to railway signalling systems specification and the ESPRIT III project CASCADE 16:15 HUMAN & LEGAL ASPECTS R.J. Tiezema (NL) : Eliminating the unexpected S.J. Westerman, C.M. Crawshaw, G.R.J. HocKey, N.M. Shryane (UK) : Cognitive diversity: A structured approach to trapping human error- D. Davis (UK) : Legal aspects of safety critical systems Thursday, October 12 09:00 Invited presentation : B. Littlewood (UK): How I learned to start worrying and fear the computer.... 09:30 DESIGN M. Heisel (D) : Six steps towards provably safe software W. A. Halang, B. Kramer, N. Volker (D) : Formally verified building blocks in functional logic diagrams for emergency shutdown system design 11:00 ASSESSMENT G. Picciolo, P. Giannino (I) : Programmable electronic controllers (PEC) performance assessment - An approach for reliability quantification W. Schynoll (D) : BOOTSTRAP: Europe's software process assessment & improvement method, experiences and further developments K. M. Hobley, P. H. Jesty (UK) : Analysis and assessment of advanced road transport telematic systems 14:00 SAFE SOFTWARE J. Blieberger (A) : Loops for safety critical applications M. Viola (CAN) : Ontario Hydro's experience with new methods for engineering safety critical software 15:20 APPLICATIONS I E. Ruiz Morales (EC) : A software development approach for robotics control systems J. Christmansson, Z. Kalbarczyk, J. Torin (S) : An attempt to evaluate functional diversity employed in a reactor protection system A. Coombes, J. A. McDermid, J. Moffett (UK), P. Morris (EC): Requirements analysis and safety: A case study (using GRASP) 17:10 APPLICATIONS II A. J. C. Sharkey, N. E.Sharkey, O. C. Gopinath (UK) : Neural nets and diversity C. Rabejac (F) : On-line software error detection by executable assertions: from theory to practice Friday, October 13 09:00 Invited presentation : J Heckmann, S. Shirlaw (F) : An industrial view on requirements engineering and safety. 09:30 CASE STUDIES F. Fenelon, J. A. McDermid (UK) : Safety cases for software application reuse P. G. Bishop, R. E. Bloomfield (UK) : The SHIP case study - A combination of system and software methods 11:00 VALIDATION & VERIFICATION R. Tiusanen, M. Hietikko (FIN) : Practical approach for the evaluation of safety related programmable electronics A. Anselmi, C. Bernardeschi, A. Fantechi, S. Gnesi, S. Larosa, G. Mongardi, F. Torielli (I) : An experience in formal verification of safety properties of a railway signalling control system A. Bondavalli, Chiaradonna, F. Di Giandomenico (I) : Dependability of iterative software: A model for evaluating the effects of input correlation Request for full registration information should be addressed to Safecomp'95, c/o M. Dowell, TP 361, Joint Research Centre, I-21020 Ispra (VA) Italy, safecomp@jrc.it . Telephone and fax contact: Dorit Schlittenhardt JRC-Public Relations and Publications Unit Tel:+39-332-789370 - Fax:+39-332-782435 Martyn Dowell JRC-Institute for Systems Engineering and Informatics Tel: +39-332-789478 - Fax:+39-332-789991 E-mail: safecomp@jrc.it ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.14 ************************ 1-Jun-95 1:46:01-GMT,30778;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id VAA28894 for ; Wed, 31 May 1995 21:46:00 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id VAA05319 for ; Wed, 31 May 1995 21:45:57 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id VAA09801 for ; Wed, 31 May 1995 21:45:51 -0400 Received: by chiron.csl.sri.com id AA23962 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Wed, 31 May 1995 18:25:35 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 31 May 95 18:25:34 PDT Subject: RISKS DIGEST 17.15 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Weds 28 May 1995 Volume 17 : Issue 15 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator >>>>> I'm back on-line for a while. PGN <<<<< ***** See last item for further information, disclaimers, etc. ***** Contents: Prodigy Held Liable (Dave Banisar) Stuyvesant High School Hackers (Mich Kabay) J. Schwartz on Decency and Democracy (Mich Kabay) Defamation by BBS (Mich Kabay) Defying pitfalls of a cashless society (Brian Randell) Flightdeck automation problems (Kenneth Funk) A slightly more global look at time and date issues (Robert J Horn) "Calling the Ahperator"(William Newman) Denial of Service attack on ISP (Simon Lyall) Drug-Addicted Geniuses Built Cyberspace (Daniel Frankowski) Re: Positive-Ion Dangers: Computers and stress / depression (Lindsay F. Marshall, Jonathan I. Kamens) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 26 May 1995 23:12:00 -0400 From: "Dave Banisar" Subject: Prodigy Held Liable A New York state trial court ruled on 24 May 1995 that Prodigy is responsible for the libelous statements of its users because it exercises editorial control over their posts. In the case, an anonymous Prodigy user made statements against New York Investment firm Stratton Oakmont accusing it of criminal and fraudulent acts. Stratton Oakmont sued Prodigy and the volunteer moderator of the forum where the statements were published. The Court found that Prodigy was acting as a publisher and therefore was responsible for the content of the posts. The Court distinguished the case from the earlier Cubby v. Compuserve decision, which found that Compuserve was subject to the standards of a bookstore or library. It that case, the US District court ruled that Compuserve had no editorial control over the text. According to the New York state court: In contrast, here Prodigy has virtually created an editorial staff of Board Leaders who have the ability to continually monitor incoming transmissions and in fact do spend time censoring notes. Indeed, it could be said that Prodigy's current system of automatic scanning, guidelines, and Board Leaders may have a chilling effect on freedom of communications in Cyberspace, and it appears that this chilling effect is exactly what Prodigy wants, but for the legal liability that attaches to such censorship. Let it be clear that this court is in full agreement with Cubby and Auvil. Computer bulletin boards should generally be regarded in the same context as bookstores, libraries and network affiliates...It is Prodigy's own policies, technology and staffing decisions which have altered the scenario and mandated the finding that it is a publisher. The court also attempted to downplay the significance of its decision on the greater area of electronic networks: Prodigy's conscious choice, to gain the benefits of editorial control, has opened it up to greater liability that Compuserve and other computer networks that make no such choice. For the record, the fear that this Court's finding of publisher status for Prodigy will compel all computer networks to abdicate control of their bulletin boards, incorrectly presumes that the market will refuse to compensate a network for its increased control and the resulting increased exposure. The Court also found that the volunteer "Board Leader" of the Prodigy Bulletin Board was acting as an agent of the company. The Court found Prodigy exercised control over the Board Leaders though the the Bulletin Board Leader Agreement and the actions of Prodigy's employees. Prodigy has said that it will consider appealing the decision. EPIC has materials on free speech available at http://epic.org/free_speech/ We will be making a copy of the decision available in the next few days. David Banisar Electronic Privacy Information Center 666 Pennsylvania Ave, SE, Suite 301 Washington, DC 20003 202-544-9240 HTTP://epic.digicash.com/epic ------------------------------ Date: 29 May 95 15:38:14 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Stuyvesant High School Hackers >From the Associated Press news wire via CompuServe's Executive News Service: Hacker High, by RAYNER PIKE, Associated Press Writer NEW YORK (AP) -- Some of New York's best and brightest set out to show that they can rush in where high schoolers are not supposed to tread -- the computer systems of Ivy League colleges. They succeeded. Their principal was not amused. Their victims were not impressed. The systems of Columbia and Princeton, as well as Bucknell University, were targeted by hackers from the elite Stuyvesant High School. Key points: o Principal said, "No harm was done and none was intended." o School adding ethics classes to computer courses. o Bucknell University staff said the hack was a prank and not slick. o "...students got a couple of Bucknell passwords and used them to send E-mail. They left one note without removing coding that tracked the sender back to Stuyvesant, a public school for academically gifted children." o Students used one Columbia University ID but no obvious damage. o Princeton IDs and passwords obtained but apparently not used. M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: 30 May 95 14:47:07 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: J. Schwartz on Decency and Democracy >From the Washington Post news wire via CompuServe's Executive News Service: WP 05/29 NETWORKINGS Making the On-Line Community Safe for Decency -- and Democracy By John Schwartz Washington Post Staff Writer Sen. James Exon sounds for all the world like a man who's ready to make a deal. Sitting in his Capitol office, the Nebraska Democrat puffs amiably on his pipe and discusses the bill that has made him anathema to many people in the on-line community, the Communications Decency Act. Exon's bill, part of the Senate version of a broad telecommunications bill, would impose jail terms and fines on those who create or solicit on-line material that is deemed "obscene, lewd, lascivious, filthy, or indecent." Key points: o Massive opposition from all sectors, including the Dept of Justice. o "For the record, Exon has no personal experience on-line, but says he finds the positive uses of the networks exciting." o Christian Coalition's http://www.cc.org home page has support for such restrictions. o Sen. Dianne Feinstein (D-CA) wants to clamp down on anarchist files. o The author writes: ...a Justice Department memo ... describes the bill as an enforcement nightmare that would criminalize constitutionally protected speech. The memo concluded it would clash with other laws and "hamper the government's ongoing work in stopping the dissemination of obscenity and child pornography and threaten law enforcement's continued ability to use court-authorized wiretaps." o The Exon bill would make materials which are legally available in print illegal if obtained online. o Sen. Patrick J. Leahy (D-VT) proposes to help parents exercise greater control over their children's access to cyberspace using technology--"lockout boxes" like devices being made available to cable-TV subscribers. o The author quotes Sen. Leahy: "To say that everyone using the Internet is going to be held to the standard of my neighbor's 7-year-old child is wrong -- and is going to cripple the Internet," said Leahy.... Overly restrictive legislation, he said, "will make one of the best free-enterprise experiments a hollow shell." o The article ends with signposts for further information: The Exon bill is a hot topic on-line. You can find World Wide Web sites devoted to the bill at http://www.cdt. org and http://www.eff.org/pub/ Alerts maintained by the Center for Democracy and Technology and the Electronic Frontier Foundation, respectively. Folks whose Internet access is limited to e-mail can get information by sending a message to cda-infocdt.org in which the text area is left blank and the subject line reads send-events. Sending the same message to cda-statcdt.org will get you the current status of the bill. M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: 30 May 95 14:47:33 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Defamation by BBS [An example of Level I Information Warfare] >From the Australian Associated Press news wire via CompuServe's Executive News Service: AAP 05/25 1443 QLD: CALL FOR CONTROLS ON DEFAMATION SUPERHIGHWAY BRISBANE, May 25 AAP - A Labor MP whose name and address were posted on a computer billboard as the contact for buying stolen telephone cards, today urged the federal government to legislate to prevent high tech defamation. MP Stephen Robertson was cleared of all wrong-doing or involvement in the scandal after investigation by the Criminal Justice Commission. The MP may nonetheless have suffered damage to his reputation. M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Tue, 30 May 1995 16:55:55 +0100 From: Brian.Randell@newcastle.ac.uk (Brian Randell) Subject: Defying pitfalls of a cashless society Defying pitfalls of a cashless society Victor Keegan (The Guardian, Economics Notebook, 30 May 1995) The kingdom of cash is starting to be attacked in a pincer movement: from in front, by electronic, or digital, cash, and from behind, by the growing popularity of the barter system Letts - artificial local currencies (rather like a baby-sitting points system), which people use instead of real money to pay each other for services rendered. [...] The world's central banks -- including the Bank of England -- are beginning to wake up to the fact that digital money could pose a threat to their hegemony. This is particularly true of the so-called "electronic purses" (like Mondex, which Midland Bank and others are pioneering) and, much more so, the digital (and untraceable) cash being-pioneered by DigiCash, the Amsterdam-based company. [...] As long as these are issued by banks-like Midland's Mondex-then it is nothing more than another bank deposit, albeit in electronic form. [...] Central banks have been sufficiently worried about the provision of electronic purses getting into the wrong hands to set up a working group of the European Monetary Institute. The conclusion was predictable: they are all right-so long as they are restricted to approved credit institutions (that is, banks), so that they can be properly monitored. Enter DigiCash, whose founder, the proselytising David Chaum, wants to create a digital system which could assume a life of its own. He has even patented a process whereby a bank or a company could validate a secret number which could be used as a unit of currency even though the issuing authority could not trace it. The place just waiting for such anonymous digital money (which would also be rather useful for kidnappers and launderers of drug money) is the Internet, the worldwide electronic cobweb of computer data bases. [...] Should the Net be provided with its own currency, it would suddenly become not only a global market place, but a virtual economy as well. It could become the first economy without a government or even a central bank at the centre. But if there is no government, no one will pay taxes. [...] We are not talking science fiction. Mr Chaum has already distributed a million digitised dollars to 5,000 pioneers taking part in a trial. Their Cybercash can be spent purchasing goods and services from 50 companies taking part in the trial. At the other end of the scale, the growth of Lett schemes is not yet a problem, if only because most of the schemes are small-scale and the people involved are probably earning below the threshold at which they would be required to pay tax. In a typical scheme one member might help another build a wall, thereby earning himself currency points, to be exchanged for work by someone else or for buying goods. If such a scheme went nationwide and electronic (so that the participants carried their points on a micro-chip on a plastic card), this could quickly evolve into electronic money effectively outside the control of the banking system and on which the participants would be reluctant to pay tax. The transactions might even take place through the Internet. Of course, central banks will move quickly if they feel their supervisory role and their divine right to print money is being challenged. The point is that the financial world is moving into uncharted waters. The change could be as far-reaching as the transition from metals to money in the last century. [What I found interesting was the way this article tied together (hi-tech) developments related to digital cash and the rise in popularity, at least here in the UK, of (typically low-tech) barter schemes. BR] Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk +44 191 222 7923 ------------------------------ Date: Fri, 19 May 1995 11:09:47 -0700 (PDT) From: Kenneth Funk Subject: Flightdeck automation problems With a grant from the US Federal Aviation Administration, scientists at Oregon State University, America West Airlines, and Honeywell have compiled over 2,300 citations of perceived problems with and concerns about commercial transport aircraft flightdeck automation. These citations are summarized in a paper available by anonymous FTP from engr.orst.edu. The paper (in ASCII) is in /pub/funkk/problems.txt. Ken Funk, Asst. Prof., Ind. & Mfg. Engr., Oregon State Univ., Corvallis, OR 97331 503-737-2357 funkk@engr.orst.edu FAX: 503-737-5241 [Also forwarded by horning@pa.dec.com (Jim Horning). PGN] ------------------------------ Date: Sat, 20 May 1995 21:01:45 +0059 (EDT) From: Robert J Horn Subject: A slightly more global look at time and date issues The date/time discussion illustrates two more global risks related issues. 1) There is a risk from overconfidence and lack of proper analysis when the subject matter is something you have known "completely" since childhood. People often get very excited or upset when they realize that there is significant hidden complexity. Most of us have achieved our full understanding of time by the age of ten. It has no more mysteries (except perhaps time zones). Discovering just how much more there is to time and its measurement is a surprise. QUIZ: For a more timely example than 18th century calendars, when does Sunday become Monday? (See below) 2) There is a significant misunderstanding around the relative merits of integer vs floating point notation in general. If your real world process can be represented as a finite field mapped onto the integers, then you can eliminate concerns regarding representation error. This makes an integer representation attractive because it reduces your error analysis problem to: a) Prove that the finite field mapping is correct. If your application involves division, you don't have a finite field. You also better be sure that the finite field mapping is understood the same way by all involved. It can be a big problem if well into your project you discover that you need additional resolution. So don't skip this step. b) Analyze the error characteristics of your algorithms in the confident knowledge that the errors have been reduced to: initial error = measurement error, and results error = numerically propagated measurement errors. Lots of people seem to think that you can skip the numerical analysis just because your operations are on a finite field. This is not the case. Measurement error is still present and it still propagates. I've seen too many instances where people omit the error analysis because "integer computations are error free". You may have a finite field, but measurement error must still be analyzed. Still, the analysis is simpler and integers are often an excellent representation for measured data. With floating point representation, you have different advantages: a) Much greater dynamic range b) Much more uniform error characteristics (always present, but lacking the sudden lurch that occurs when your finite field mapping fails.) c) The psychological pressure to analyze errors because some error is always present. The difficulty is that your error analysis is harder: initial error = measurement error + representation error results error = propagated measurement error + propagated representation error + representation error. This can be more work, although I have found that in most real world situations the measurement errors have dominated. Usually I could completely ignore representation error because the measurement errors were orders of magnitude larger. Oh, and the answer to the quiz: It depends upon what part of the world you are in. In some areas, the day ends at sunset. So during some parts of the year, 1730 (local) Sunday occurs before 1800 (local) Sunday, and in other parts of the year it occurs after. And you need to know the latitude and longitude to figure out when sunset occurs. Is it any wonder that people who care about time quickly end up using UTC for everything. But this is a lurking trap for the unwary who want to make a properly internationalized application that allows the use of local time. R Horn rjh@world.std.com ------------------------------ Date: Mon, 22 May 1995 05:53:30 PDT From: Newman@europarc.xerox.com Subject: "Calling the Ahperator" My attempts to reach the long-distance operator from my Washington DC hotel instead connected me to a voice-activated interface instructing me to say "Operator" to get through, but my British pronunciation clearly didn't sound right. I found I could get through with a phony American "ahperader" but only on the second attempt, the first attempt always getting a lengthy recorded apology and a repeat of the (even lengthier) instructions. Out of frustration, I resorted to dialling the number direct, for which my hotel charged me $95 for a call that would otherwise have cost $52. It seems strange to require long-distance callers from DC hotels, many of whom are presumably foreigners trying to reach overseas, to speak with an American accent. No alternative means of reaching the operator is offered, and this could be a source of risk in emergency situations. When I got through to the supervisor to point this out, she agreed, but said, "You could have dialled zero instead." Why didn't I think of trying this? But the recorded instructions say nothing about this option. William Newman newman@europarc.xerox.com ------------------------------ Date: Tue, 23 May 95 09:11 NZST From: simon@darkmere.midland.co.nz (Simon Lyall) Subject: Denial of Service attack on ISP The following was posted to a Local (New Zealand) group. Both iprolink and Cybernet are ISP's servicing the Auckland market and targetting similar customers. Cybernet was in the papers a few weeks ago after someone there NFS mounted a disk (read & write) at Auckland University (This disk included /bin directories according to some reports). The mserve machine is the workstation of a Cybernet staff member. >From: Craig Anderson Newsgroups: nz.netstatus Subject: Network Attack Mars Internet Show Date: 22 May 1995 13:51:29 GMT Organization: Internet ProLink NZ, Auckland Last week (15-20 May) Internet ProLink NZ, along with InfoTech Weekly, TUANZ, Megascreen, Atrium on Elliott, and Dymocks, sponsored a week long series of free Internet demonstrations at the Atrium in Auckland. The event was marred by an attack on our system during the first three days of the show. The intent appears to have been to deny us the use of our Internet connection during the show. This posting should serve as a warning to system administrators. Note that eliminating these types of attacks requires filtering at the site to whom you are connected, and that similar attacks with the traffic destined to routers can be difficult to monitor. Monday: Thousands of ICMP echo packets each minute from 202.36.227.10 (mserve.cybernet.co.nz) saturate our link in both directions. These high priority packets almost completely prevent us from using our link at all. The packets initially were sent to iprolink.co.nz, but later to router1.iprolink.co.nz. The attack lasted approximately two hours from about 2:15 pm and stopped when we unplugged our link for several minutes. Tuesday: ICMP packets sent to our router again completely saturate our link. Attack begins around noon and ends when the University of Auckland temporarily disconnects Cybernet's link. Wednesday: TCP packets (again from mserve.cybernet.co.nz) were sent to ports 7, 8, 2, 3, 4, 5, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, and finally port 19 on iprolink.co.nz, where our outbound link was saturated with traffic for more than one hour. No further attacks were seen after Cybernet was contacted by the University of Auckland. Our apologies to those who turned up for the show during these attacks only to find that the Internet link was too slow to be used. Thanks to the University of Auckland Computer Center staff who did a tremendous job in helping to monitor and stop this attack. -Craig ------------------------------ Date: Mon, 22 May 1995 17:49:15 -0500 (CDT) From: Daniel Frankowski Subject: Drug-Addicted Geniuses Built Cyberspace I have the pleasure of presenting one of the most absurd claims I've read in the mainstream press in a long time. In the Minneapolis Star Tribune, Monday, May 22, 1995, on page 10A, yet another inflammatory article about the Internet appeared, titled ``Cyberstoned''. The article is adapted from Boston Magazine, written by Stephen Rodrick at Boston Magazine and Vladimir Edelman, a Boston-based freelance writer. The point of the article was that there is drug dealing on the net, and that there are net-specific problems for law enforcement. I agreed with parts of the article, e.g. that law enforcement needs to learn about the net, that freedom of information and anonymity make law enforcement more difficult, etc. The writers give away their position when they report that ``after Internet zealots howled about the loss of privacy, the fate of the Clipper chip remains in doubt,'' but I forgive them. Then they make an absurd pronouncement backed up by scant evidence: In fact, much of the cyberspace revolution of virtual reality, the Internet and other high-speed technology burst out of the minds of computer geniuses spaced out on drugs such as acid and ecstasy. In his book *Cyberia: Life in the Trenches of Hyperspace*, Douglas Rushkoff traces the creation of the drug culture's special place on the Internet. `Developments in the computer industry and on the Internet are being made by the same people who made the counterculture of the '60s possible. Those willing to explore hallucinatory dreamlike realms that didn't exist before -- never-before-navigated turf of consciousness,' Rushkoff says. I have a master's degree in computer science from the University of Minnesota, and I read newspapers with regularity if not often. I cannot recall a single story about the arrest for drug possession of a computer scientist familiar to me from their academic work. Abramson, Tannenbaum, Liskov, Stonebraker, Lazowska, not to mention my own professors and numerous others have all thus far managed to hide their dirty little secret. The risks? Reporters who are not knowledgeable about computer science. This risk generalizes easily: lawyers who are not knowledgeable about computer science, patent clerks, politicians, bureaucrats, .. If the two quoted paragraphs about "much of the cyberspace revolution" coming from druggies annoyed you as much as it did me, please email the Op-Ed page of the Minneapolis Star Tribune at opinion@startribune.com. Ptooie! Dan Frankowski dfrankow@winternet.com http://www.winternet.com/~dfrankow ------------------------------ Date: Mon, 22 May 95 09:58:43 0100 From: "Lindsay F. Marshall" Subject: Re: Positive-Ion Dangers: Computers and stress / depression Using a negative ion source is definitely beneficial, however be careful. I cannot use an ioniser in my office as whenever it I switch it on I get SCSI errors that result in me not being able to access the external disc on my Sun. (Could this be a plot by intelligent silicon to keep the world depressed?) Lindsay Dept. of Comp. Science, U of Newcastle, Newcastle upon Tyne, UK NE1 7RU UK +44-191-222-8267 http://catless.ncl.ac.uk/Lindsay.html ------------------------------ Date: Mon, 22 May 1995 14:18:31 -0400 From: "Jonathan I. Kamens" Subject: Re: Positive-Ion Dangers: Computers and stress / depression It appears that PGN was duped in RISKS-17.14 by what one poster in news.admin.net-abuse.misc calls "the slow spammer." The user who submitted the message about "positive-ion dangers" was not doing it out of the goodness of his heart or because he felt it was an appropriate, current topic for RISKS. He was doing it, I believe, because he sells negative-ion emitters. He has been slowly spamming his message to many newsgroups for some time now. Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com [... and to think that all these years we have put up with SpammoVision. There is also some moron who has been spamming usenet readers of comp.risks. I have no control over that, but apologize anyway. PGN] ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.15 ************************ 2-Jun-95 23:55:53-GMT,31558;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA18371 for ; Fri, 2 Jun 1995 19:55:52 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id TAA19461 for ; Fri, 2 Jun 1995 19:55:50 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id TAA27347 for ; Fri, 2 Jun 1995 19:55:45 -0400 Received: by chiron.csl.sri.com id AA25669 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Fri, 2 Jun 1995 16:46:29 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 2 Jun 95 16:46:28 PDT Subject: RISKS DIGEST 17.16 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Friday 2 June 1995 Volume 17 : Issue 16 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: New Yorker Article on Potential Building Collapse: The 59-Story Crisis (Andy Huber) ``Woodpeckers could delay shuttle'' Ariane-5 test aborted Military (hi-res) GPS to be opened up? (Cris Pedregal Martin) Bogus PKZIP 3.00 Trojan horse (Sidney Markowitz) British man convicted as malicious virus writer (George Smith) Internet Security -- Oxymoron or Actual Fact? (Edupage) Pay-Phone Price Gouging (Mich Kabay) Cellular Roaming broken (Bob Frankston) Re: Microsoft plans corporate espionage (ASaunders) MS SMS product, others pose risks (Mark Seecof) Re: Prodigy held liable (Bob Morrell) Re: "Nautilus foils wiretaps" (Adam Back) Re: Ahperader (Paul Andrew Olson) Re: Negative Ions (Winn Schwartau) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: Thu, 01 Jun 95 10:02:50 EDT From: Andy Huber Subject: New Yorker Article on Potential Building Collapse: The 59-Story Crisis "If they built buildings they way we build software...." There's a fascinating article in the current issue of The New Yorker ("The Fifty-Nine-Story Crisis", Joe Morgenstern, The New Yorker, vol. LXXI, no. 14, May 29, 1995, pp. 45-53) that should be of great interest to all with an interest in software engineering. It's the story of the discovery and patching of a design/implementation flaw in a 59-story building in New York City (the Citicorp Center) that had the potential to cause the building to collapse disastrously under high winds. The parallels with software are uncanny, because the reasons the problem occurs are exactly the things that occur in so many software projects: 1. An unusual or novel aspect to the problem. (Building around an existing structure, a church). 2. A creative, innovative solution that required new design & analysis. (Putting the main support columns in the middle of each side of the building, rather than at the corners.) 3. Not quite getting all the implications & analysis of the innovation right. (The reviewers of the design treated some special, new diagonal wind braces as trusses rather than columns, thereby disregarding a required standard and exempting them from a safety standard.) 4. A critical change in the specification made by the contractor during construction to save time & money that was not reflected back to the designers and/or re-analyzed/reviewed for its impact that greatly weakened the design. 5. A resulting flaw that would only show up in heavy load, and not under normal use/test. Anyone interested in making software engineering a profession will also find the article of interest. Everyone involved exhibited a high degree of professionalism throughout the discovery, analysis, and fixing of the problem. (Even the lawyers!) Another amazing thing is that there's been little if any publicity of this before (at least to my knowledge; this is the first report I remember seeing). Part of that may be due to the fact there just happened to be a newspaper strike going on in New York City at the crucial time.) WARNING: Do not start reading this until you have time to finish it; I found it a case of "can't put it down" reading. [Note: I'm unable to always follow the risks forum closely, but haven't seen anything on this in there, either recently or in the past. It will certainly appeal to risks readers. Apologies if others have submitted this or it's been covered in the past & I just missed it, in which case simply hit the delete key. Might note also that if people find this interesting, an interesting book on similar things that I read a couple of years ago while doing some investigating on operating system reliability is: "Why Buildings Fall Down", by Matthys Levy & Mario Salvador, New York, W.W. Norton, 1992. One of the conclusions is that many buildings fail due to a lack of redundancy, which I find very interesting since very few operating systems (or software of any kind) has any kind of redundancy designed or built into it.] Andy Huber Data General (919) 248-6072 huber@dg-rtp.dg.com ------------------------------ Date: Fri, 2 Jun 95 10:11:54 PDT From: "Peter G. Neumann" Subject: ``Woodpeckers could delay shuttle'' Our risks-to-technology annals have another case of animal-kingdom behavior. For the past several days, yellow-shafted flicker woodpeckers have been chipping away at the insulating foam on the space shuttle Discovery's external fuel tank, causing at least 71 holes, from half-inch to four inches in diameter. [Source: AP item, San Francisco Chronicle, 1 June 1995, p. C2] [Poly(styrene?), wanna crack 'er? Oh for the old days of silent flickers.] ------------------------------ Date: Fri, 2 Jun 95 10:02:08 PDT From: "Peter G. Neumann" Subject: Ariane-5 test aborted After the failure of the main cryogenic motor earlier in May resulted in the death of two technicians, another test on 30 May (in Cayenne, French Guiana) was aborted by the computer control system several seconds after ignition of the new European rocket. I suppose this case counts as a success story for computers, but a failure for the rocket motor. PGN [Source: A Reuters item, San Francisco Chronicle, 1 Jun 1995, p. A10.] ------------------------------ Date: Thu, 1 Jun 1995 11:48:21 -0400 (EDT) From: Cris Pedregal Martin Subject: Military (hi-res) GPS to be opened up? On 31 May 1995, I heard a story about GPS on NPR-All Things Considered of interest to RISKS readers. Apologies for any omissions, I didn't take notes so the following is from memory. A "blue-ribbon" panel just issued a report on whether to open all of the satellite-based Global Positioning System (GPS) to civilian use. As it works now, GPS transmits a low-resolution signal for civilian use, which has random errors added to it (resolution: about 100m), and an encrypted signal for military use that's much more precise. The civilian capability was made available worldwide after the KAL 007 downing over Soviet Airspace during the Reagan administration, and it is now widely used not just by ships and planes, but also by hikers and tourists (a palmtop GPS locator sells for about $300 in the US). The panel concluded that the hi-res signal had to be opened to use by all. The military's objection is that enemies could use it to e.g. guide missiles (one of their own applications) to US targets. They're proposing that the error may be increased, or the system turned off altogether, at the discretion of the US President, in "time of war". Civilian aviation authorities aren't thrilled about using a system on which they don't have their "hand on the switch," as an official from the British aviation authority said. The cat may already be out of the bag. FAA is testing a system that uses the civilian GPS on an aircraft in concert with a ground-based civilian GPS, through a radio link. Since the ground based GPS knows its coordinates, it can listen to the signal from satellites, figure the error, and inform its airborne partner. Precision is in the 1 meter range now, enough to put a plane on a glide path and land it in dense fog. The various RISKs are left as an exercise to the reader. Cris Pedregal Martin pedregal@cs.umass.edu Computer Science Department UMass / Amherst, MA 01003-4610 [Also reported by Fred Ballard <72400.1525@compuserve.com>, who added ``As our dependence on GPS increases, so do the risks. It might be wise to check the international scene as well as the weather before flying or boating when GPS is being relied on.'' PGN] ------------------------------ Date: Fri, 2 Jun 1995 11:50:44 -0700 From: sidney@apple.com (Sidney Markowitz) Subject: Bogus PKZIP 3.00 Trojan horse I saw the following notice on PKWARE's support forum on CompuServe and have more recently seen it forwarded via the COOL mailing list. The RISK involved is obvious, but I'm forwarding it in case any of RISK's readers still use DOS :-). For those who don't: PKZIP is a widely used file compression/archiving program that is sold as shareware. It's been at version 2.04G for quite a long time, so people would be quite likely to grab up a new version quickly. sidney markowitz Some joker out there is distributing a file called PKZ300B.EXE and PKZ300B.ZIP. This is NOT a version of PKZIP and will try to erase your harddrive if you use it. The most recent version is 2.04G. Please tell all your friends and favorite BBS stops about this hack. Thank You. Patrick Weeks Product Support PKWARE, Inc. ------------------------------ Date: Thu, 1 Jun 1995 18:38:49 -0500 (CDT) From: Crypt Newsletter Subject: British man convicted as malicious virus writer Finally, after months of delay and postponement, a 26 year old unemployed computer programmer, Chris Pile, pleaded guilty Friday, May 26, to eleven charges related to computer virus writing. The case at Plymouth Crown Court was the first of its kind in British legal history since passage of the Computer Misuse Act in 1990. Pile, known as the Black Baron, pleaded guilty to hacking into business computers and planting the computer viruses known as SMEG/Pathogen and SMEG/Queeg. The case followed an investigation by fraud squad officers and experts from Scotland Yard. The eleven charges stemmed from a period between October 1993 and April 1994 when the Black Baron obtained unauthorized access to computer programs and seeded them with viruses he'd written. He also pleaded guilty to one charge of inciting others to plant his viruses. Authorities state that tracing the viruses and repairing damage caused by them cost "well in excess of half a million pounds." Pile was released on bail and the trial adjourned for two months to allow the defence to prepare a pre-sentencing report. Pile, a Devon man, wrote the SMEG viruses which quickly gained the attention of anti-virus developers worldwide in mid-1994. Due to publicity on the nets and in the computer underground, they were rapidly distributed around the Internet at approximated the same time Pile was arrested in connection with the charges on which he was tried. Sentencing will probably depend upon the interpretation of Pile's intent to incite others to write viruses using his "SMEG" encryption kernel which was distributed internationally to virus exchange underground bulletin board systems in mid-1994. It is an arcane issue which calls for the examination and tracking of a computer archive containing a detailed technical "how-to" on installing Pile's "SMEG" virus encryption kernel into new viruses, the encryption software and a sample demonstration virus. In 1993, another English virus writer, Stephen Kapp, was arrested in connection with telephone fraud charges. Kapp was known as the "President of ARCV," or ARCV virus writing group which stood for Association of Really Cruel Viruses. It is worth noting that in 1992 at the height of the Michelangelo virus scare, few virus writers were easily identified. This is no longer the case. Due to the growth in computer networks and an increasing desire for underground network celebrity, many of the most prominent virus writers in the world live in plain sight. Australia's Clinton Haines, a student at the University of Queensland, is responsible for writing and putting the Dudley and NoFrills computer viruses into the wild in his country. At various times since 1992, these viruses have infected SunCorp, a large Australian insurance firm; Australian Telecom and the Australian Taxation Office, which is similar to the IRS. Haines has been interviewed at length by the Australian newsmedia. In America, James Gentile, a teenager living in San Diego, has written a number of viruses, all of which have emerged in the wild. His Satan Bug crashed US Secret Service networks in 1993. Since then another of his creations, known as Natas - Satan spelled backwards - has become one of the most common computer viruses in North America. It has been reported as far south in the hemisphere as Argentina. George Smith crypt@sun.soci.niu.edu On the World Wide Web: URL: http://www.soci.niu.edu:80/~crypt ------------------------------ Date: Thu, 1 Jun 1995 21:09:03 -0400 From: info@ivory.educom.edu (Edupage) Subject: Internet Security -- Oxymoron or Actual Fact? (Edupage 1 June 1995) William Cheswick, a senior researcher at Bell Labs, thinks the Internet is risky business and "a bad neighborhood," in which "hackers can eavesdrop on the packet flow... It is past time for the deployment of encrypted sessions." But investment banker and consultant Ted Prince says: "What we have is a tiny number of hacker incidents that have been blown out of proportion by the tabloid technoliterati... You have more chance of getting your credit-card number stolen in a restaurant or on a phone in Grand Central Station than you do of having it stolen on the Internet." (Computerworld 5/29/95 p.96) [Perhaps Prince is correct at the moment, but Cheswick seems to be thinking further ahead. Someday Prince will come . PGN] ------------------------------ Date: 30 May 95 14:47:14 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: Pay-Phone Price Gouging >From the Associated Press news wire via CompuServe's Executive News Service: Pricey Pay Phones,, By JEANNINE AVERSA, Associated Press Writer WASHINGTON (AP, 29 May 1995) -- Between appointments, Mary Viar dashed to a pay phone in Hagerstown, Md., to wish her daughter in Pittsburgh a happy birthday. A week later, she got the bill: $21.39 for her 22-minute call. For the same amount, she could have called Paris and talked for half an hour. Key points: o FCC handling growing number of complaints about unexpectedly high prices for calls made through pay-phones: 4,280 complaints in the last 12 months. o Beware of phones controlled by "MD-based Oncor Communications, whose rates are three to four times as high as those of the big phone companies." o Users have filed 800 complaints to the FCC about Oncor's rates. o Hotels and pay-phone owners charge the high rates even if user requests connection to their own lower-cost carrier. o Users can bypass the automatic charges by rogue phone companies by dialling directly to use their own 800 or 950 access codes for more reasonable phone carriers. o Some companies add a surcharge to each call and share the revenue/ with "the hotel, bar or other establishment where a public phone is located...." o "The FCC said Oncor's surcharges alone have totaled as much as $10 per call." In a related article, the author included the following information: If you believe you have been unfairly charged for a long-distance call, you can file a complaint to the FCC, which oversees interstate service. For local calls, contact the state's public utility commission, which oversees local phone service. You may also want to send a letter to the state attorney general, many of whom have raised concerns about rate gouging. Complaints may be sent to the Federal Communications Commission, Enforcement Division, 2025 M Street, N.W., Washington, D.C., 20554. Additional information also can be obtained by calling the FCC at 202-418-0190. M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Tue, 23 May 1995 22:50 -0400 From: Bob_Frankston@frankston.com Subject: Cellular Roaming broken Last week I was trying to use my cellular phone in Seattle. I couldn't get it to work because it is a Boston based phone and the Boston database was being upgraded last week and, basically, got screwed up. I didn't now about this till Thursday evening but apparently it was a week long problem according to the Boston Cellular One. The Seattle people said that they couldn't do anything about it. The first time I called customer support the suggested solution was to power off and try again in a little while since they were clueless as to the cause of the problem. Later I spoke to someone who was more familiar yet was still unable to help. Perhaps no one really roams on these phones, but one would think a major outage like this would get more attention and be taken more seriously. But then, the reality of the cellular network is that it is not a reliable service. Before automatic roaming you'd have to register locally but that was only available on a 9 to 5 basis. Perhaps this is a nonrisk. By not providing a really reliable service, people are not going to be overly dependent upon the network. Actually, they will be dependent upon it for emergency services until the first emergency ... ------------------------------ Date: Wed, 24 May 1995 15:02:16 -0400 From: ASaunders@aol.com Subject: re: Microsoft plans corporate espionage cnorloff@tecnet1.jcte.jcs.mil writes: " Microsoft officials confirm that beta versions of Windows 95 include a small viral routine called Registration Wizard. ... Unfortunately Information Week got it wrong. The registration wizard is nothing more than an electronic version of the ordinary reg card that ships with every software product today. Its use is optional, it does not interrogate every PC on a network, and the user chooses what information will be transmitted. I have enclosed a copy of a response we wrote on this, which you can get from ftp.microsoft.com/peropsys/win_news/regwiz.txt if you wish. Alec Saunders, Microsoft Corporation, alecs@microsoft.com -- A recent trade publication article contained inaccuracies regarding the purpose and operation of the Registration Wizard, the on-line registration application in Windows 95. The purpose of the Registration Wizard is to offer an electronic version of the paper-based Registration Card that traditionally comes with all Microsoft products. The Registration Wizard asks for similar information to that listed in the paper-based registration card, such as your hardware configuration and applications usage. Just like with a traditional registration card, providing this information is optional. A customer using the Registration Wizard receives dialog prompts asking them whether they would like to send this information. They must actively click 'send' for any information to be sent. There are lots of benefits to customers that provide this information - such as product update mailings and improved product support because the product support engineer can refer to your exact system configuration information on-line. In the end, though, sending this information is optional and a conscious decision by the user. Microsoft traditionally does not make information gathered during the registration process available to third-parties. If the customer chooses to send system and software information to Microsoft with the Registration Wizard, it is a one-way, one-time occurrence and takes place at the time the customer selects 'send.' ------------------------------ Date: Fri, 26 May 1995 16:45:33 -0700 From: Mark Seecof Subject: MS SMS product, others pose risks The June 5 Information Week has a big product review story about network- distributed PC management products which using software on PC's and on servers to let administrators inventory PC contents, update PC files, distribute software, monitor usage, and so-on and so-forth. Two of the products, including most notably Microsoft's SMS, will put any PC into promiscuous mode to sniff packets from the LAN's to which it may be attached and forward the data to another machine for analysis. I feel disappointed that the story doesn't even mention the possibility that these products may pose security risks. Three such occur to me instantly: that people can place bad data onto PC's using the distribution facilities; that people can retrieve confidential data from PC's using the inspection and monitoring facilities; and that people can steal confidential data from the network using the remote packet sniffing facilities. I'm sure there are many more problems. Not only does the story ignore risks, but consequently it does not mention or rate any product features which might mitigate such risks (e.g., schemes by which PC's could authenticate purported management server commands before responding to them). Doesn't anyone out there in the software business give a hoot about these issues? Mark Seecof ------------------------------ Date: Fri, 2 Jun 1995 11:25:32 -0400 (EDT) From: Bob Morrell Subject: Re: Prodigy held liable So, let me get this straight: Prodigy, by exercising even a modicum of control is completely liable for whatever appears, while other forums, which allow anything, no matter how vile, outrageous and slanderous, get off scott free. I know I should never be surprised at stupidity, but it does appear they are encouraging exactly the behavior that the laws are meant to discourage. Bob Morrell bmorrell@isnet.is.wfu.edu [It also bodes ill for even the most carefully moderated newsgroups! PGN] ------------------------------ Date: Sun, 21 May 95 17:53:44 +0100 From: aba@atlas.ex.ac.uk Subject: Re: "Nautilus foils wiretaps" (Vincent, RISKS-17.13) Malcolm Vincent from a UK email address writes: > [...] but I do have an account on a FreeNet site in the US which for > the moment will remain nameless. Now really, what is to prevent me > downloading nautilus to my free-net and from thence to home. It may not even be necessary to have a US based account. The mechanism used is to do a DNS name lookup on your IP number. However there are plenty of non-US sites with DNS names which look American (end in .com for instance). Some of the sites have weaker checks, merely requiring you to agree by virtue of downloading that you are a US citizen. There are plenty of routes whereby crypto software can leave the US with very low risk of detection. Consider, for instance, that the software could be encrypted with PGP, and mailed through a chain of encrypting anonymous remailers. In fact something of this nature must already have happened for it is available for ftp in the UK from Oxford University: ftp://ftp.ox.ac.uk/pub/crypto/misc/nautilus-0.9.0.tar.gz Also, ITAR only clearly holds if you are a US citizen, currently living in the US. I don't believe this situation (ftp from outside the US of US export controlled software) has ever been explored in court, but it is not immediately obvious that a US law which makes an action illegal in the US could be held to apply outside the US. Particularly as the physical jurisdiction in question does not have a similar law. The whole question rests on the legal interpretation of the action of ftping a file, which jurisdiction is ftp initiator considered to be in. A non-computer based example which could be used as a metaphor: obtaining information from a foreigner on the phone. Say that a US citizen had made a phone call to the former Soviet Union and had requested KGB classified information, information which was freely available in the US, would the US person have committed an offense on Russian soil and hence expect to be extradited? The telephone example is very similar to the modern computerised example, ftp is merely an automated information retrieval system. Another somewhat related risk, is people outside the US posting crypto code to USENET, for instance my sig file below implements RSA encryption in 3 lines of perl. If you are not familiar with encryption schemes, RSA is one of the most secure public key encryption schemes, and is the one used in PGP. It is also very firmly on the ITAR export control list. Information on the sig is at: http://dcs.ex.ac.uk/~aba/rsa/ Some US folks are printing a T-shirt with this code on it, in honour of ITAR, to produce an export controlled "munitions" T-shirt. Also on the web page is postscript for a 1x4" mailing label with the code as handed out by New York lawyer Duncan Frissell at Computers, Freedom and Privacy '95 - for an export-controlled mailing label. A picture of one of these labels was printed on the front page of the business section of the New York Times (April 10th). [As I recall, the left margins were (intentionally?) fuzzied. PGN] In using this sig, there is the risk that news distribution paths cross the US borders a few times on the way, does this constitute "export"? What about a mailing list, members will receive copies via the US list server. Some unsuspecting US usenet reader might quote the sig by accident. Living in the UK, I feel fairly confident of the safety, and legality of using my sig, but what about larger programs posted by those outside the US. I mean if a non-US citizen living outside the US were to fetch nautilus from the Oxford ftp site and post it (speaking hypothetically here of course) uuencoded to sci.crypt, would that person be in trouble? I am not sure that this would be a good idea, but it is an interesting question from a legal point of view. But the perl rsa implementation is okay at 3 lines? The question arises about where the cut off point is: 10 lines, 1000? Adam Back HAVE *YOU* EXPORTED A CRYPTO SYSTEM TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------------8<------------------------------------- #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX **CENSORED** - export controlled software XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -------------------------------------8<------------------------------------- TRY: echo squeamish ossifrage | rsa -e 3 7537d365 | rsa -d 4e243e33 7537d365 [Somewhat similar sentiments were also expressed by Stuart Smith . PGN] ------------------------------ Date: Thu, 1 Jun 95 13:25 EDT From: Paul Andrew Olson Subject: re: Ahperader This reminds me of something a colleague told me a few years ago, when her employer first installed voice mail. Mysteriously, the system would often prevent her from leaving messages. After the beep, she would start leaving a message, and then at some point (usually near when she was almost finished) it would cut her off, saying "That is not a valid code, please re-enter your message", for no apparent reason. Naturally, this drove her up the wall. It did not behave this way for anyone else. It turns out that since her voice is pitched relatively high, the voice mail system mistook her voice for one of the phone number tones. I guess it wasn't zero or one, or she would have gotten further instructions. Last I heard, she started leaving messages with her best James Earl Jones-impression, and that worked. I don't know if the problem was ever fixed. Again, the RISK is assuming certain things about the human voice. ------------------------------ Date: Thu, 1 Jun 1995 14:04:41 -0400 From: winn@Infowar.Com Subject: Re: Negative Ions This talk about positive and negative ions is really nothing new. If you go through the literature, especially the medical literature of the 60's and 70's on the subject, early research suggested (perhaps empirically in some cases) that negatively ionized environment promote health, accelerated healing, and an overall sense of well being. I have had negative ion generators at home for years, but never too near computers because `crashes' became too common. In the late 70's and early 80's, companies were attempting to market humongous negative ion generators for use in the air conditioning systems of new buildings to neutralize the `positive ion effects of computer equipment.' I've not yet seen a study of whether wholesale ionization of air-conditioned buildings with no ventilation is a justified investment or not; some have claimed that increased worker productivity and fewer sick days were an immediate benefit. But that assumes the computers still work. I'd like to see more of the recent work on the subject, as my file cabinets full of these files are `antique' - more than 15 years old. Winn Schwartau Interpact, Inc., Information Security & Warfare V:813.393.6600 F:813.393.6361 Winn@Infowar.Com ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.16 ************************ 8-Jun-95 1:04:48-GMT,28009;000000000000 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id VAA06319 for ; Wed, 7 Jun 1995 21:04:46 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id VAA22503 for ; Wed, 7 Jun 1995 21:04:44 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id VAA25765 for ; Wed, 7 Jun 1995 21:04:36 -0400 Received: by chiron.csl.sri.com id AA29387 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Wed, 7 Jun 1995 17:53:54 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 7 Jun 95 17:53:53 PDT Subject: RISKS DIGEST 17.17 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Weds 7 June 1995 Volume 17 : Issue 17 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator <<<<< The annual RISKS Summer Slowdown has begun. >>>>> ***** See last item for further information, disclaimers, etc. ***** Contents: [Also working on big backlog] Placing the blame, Part N+1: New York City subway crash (PGN) Former IRS employee indicted (PGN) The Internet is a Dangerous Place (Mycal Johnson) Telecom records non-privacy at Ameritech (Lauren Weinstein) *California Lawyer*, June 1995 (Martin Minow) Copyright infringed via WWW? (Gregor Ronald) User-friendly E-mail systems () Re: Ariane-5 test aborted (Erling Kristiansen) Re: Drug Addicted Geniuses Built Cyberspace (Carlton Hogan) Re: New Yorker Article on The 59-Story Crisis (Bob Frankston) Compuserve addresses and a sparse name-space (Erik Corry) Europe - Central Air Traffic Control (Mike James) Re: The standard notion of a `field' (Peter Ladkin, Rob Horn) Telematic Sculpture 4 (T.S.4) Privacy Digests (PGN) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 7 Jun 95 9:07:09 PDT From: "Peter G. Neumann" Subject: Placing the blame, Part N+1: New York City subway crash A NYC subway train on the Williamsburg Bridge crashed into the rear end of another train on 5 June 1995. The motorman apparently ran through a red light, and was still applying power at the time of the crash. The safety system is supposed to apply emergency brakes whenever a train runs a red light, but it seems that did not happen. (Subway officials said they had never seen that failure mode before.) So, we must add to the RISKS annals yet another case in which human error and system failure acted in combination. Here, neither of the two sets of safety measures was able to rely on the other. [Source: various news services on 6 and 7 June 1995.] ------------------------------ Date: Wed, 7 Jun 95 11:45:11 PDT From: "Peter G. Neumann" Subject: Former IRS employee indicted A former employee of the Internal Revenue Service, Walter C. Higgins of Salem, NH, has been indicted on wire-fraud charges for illegally browsing through IRS computers to gather information on Thomas Quinn, a candidate in an election for the House of Representatives. (Quinn lost the election to Martin Meehan, D-MA from Lowell; Meehan says he knew nothing about Higgins.) A current IRS employee, consumer representative Richard W. Czubinski, of Dorchester, MA, was indicted for misusing his computer access privileges to obtain information on 30 taxpayers, including members of the campaign committee of South Boston City Council President James Kelly. He apparently also accessed the tax files of a Suffolk County assistant district attorney who had unsuccessfully prosecuted Czubinski's father. Disciplinary action is being considered by the IRS. (Czubinski was also described as a sometime political candidate and a member of the Ku Klux Klan.) [Source: The Boston Globe, 3 June 1995, pp. 1 and 15.] [Recognizing the importance of preventing and monitoring both browsing and improper data modification, the IRS is making a considerable effort in its Tax Systems Modernization efforts to base the new system designs on stringent privacy and security requirements. I wish them luck! PGN] ------------------------------ Date: Wed, 7 Jun 1995 09:27:50 From: mycal@netacsys.com (Mycal!) Subject: The Internet is a Dangerous Place I just learned yesterday that the Internet is a dangerous place. It seems someone up in Canada posted a message about a bomb and made it look like I wrote the message. Well, guess what happened, I got a visit from the U.S. Secret Service. It seems that they don't quite understand the Internet and think that, just because my name and E-mail address appeared in the text of the document, I wrote it. If anyone knows of any `bomb' files that have my name on them, would you please tell me what archive they are stored at, because I didn't write them and I want my name off them? Thanx, Mycal Johnson mycal@netacsys.com ------------------------------ Date: Tue, 6 Jun 95 21:38 PDT From: lauren@vortex.com (Lauren Weinstein) Subject: Telecom records non-privacy at Ameritech In a recent issue of the TELECOM digest, it was reported that Ameritech now allows anyone to obtain bill payment information for any Ameritech line (unless blocked by specific subscriber request)--a true bonanza for snoops in general and for folks trolling for big bill customers to target for marketing. Obviously, this is a terrible policy. It is unfortunately not a unique situation. Ameritech's explanation (as reported in TELECOM) has been spouted by numerous other utilities, banks, and other entities. If a subscriber complains, they are frequently told that "hardly anyone else has complained about the system". If 1000 people complain, they may each individually be told that they're essentially the "lone wolf". The "solution" is obvious. Ameritech should return to a "random" passcode system, and allow customers who have a problem remembering the code to either choose something simple ("0000") or opt for no code at all. But such a choice of no security should be made by the individual customer--to make it the default condition for all customers is very bad policy. Experience has shown that the only effective way to deal with these types of situations is to complain loudly to the highest level you can reach. In the case of Ameritech, complaints (and suggestions for "fixing" the problem, as mentioned above) should be made to the billing supervisor level at least--better yet, speak to the managers. And while it means taking the time to put it down in written form, letters to state PUCs are *extremely* important with such matters. I'm sure there are just a *few* Ameritech subscribers reading this now. If each of you expressed your opinion (one way or another) to the PUC and Ameritech regarding their system, I suspect you could have considerable impact. --Lauren-- ------------------------------ Date: Wed, 7 Jun 1995 12:09:13 -0700 From: minow@apple.com (Martin Minow) Subject: *California Lawyer*, June 1995 *California Lawyer*, June 1995 is a "High Tech" issue that RISKS readers might find moderately interesting, if for no other reason than to see another view of the computer field. Here's a brief summary of the contents: -- An article on how software games developer Electronic Arts learned about Hollywood dealmaking. -- An article on the First Amendment and the Internet. -- How a midsize law firm incorporated computers into its "culture." -- Cybercrime "police worry about savvy criminals." -- A map of Silicon Valley with law firms identified. -- Worries about digital piracy (copying laser disks, copying documents). -- A lawyer's viewpoint of the Intel Pentium problem. -- Repetitive-motion injury problems. -- Techno Tools. Readers may also find the proliferation of computer-based legal tools interesting: as usual the advertisements are often more fascinating than the articles. A few random quotes: Electronic Arts: ``Securing the rights [to rock music] took almost as long as producing the game.'' Hate speech: ``The first time you get a first-run film sent over the Internet, you'll get lots of lawyers involved." "The First Amendment allows hate speech [on the Internet] to persist.'' Cybercrimes: ``For the most part, the computer has not introduced any new types of crimes, but it has introduced new methods, time frames, and languages for committing theft, manipulation, destruction, and espionage.'' Digital Piracy: ``Today's ability to create perfect copies over the Internet has frightened people.'' Intel: Disclosing bugs gains advantage in public-relations, but that doesn't take into account the business ramifications, including product replacement, numbers of customers, .... ``Legal ramifications are often secondary to corporate concerns.'' ``The Intel case study offers more public-relations lessons than legal ones, attorneys agree.'' ``The legal effect ... is about nil, Vendors have protected themselves with so many warranty clauses ... that they can get away with anything.'' >From California Lawyer, June 1995. 1390 Market St., Ste 1210, San Francisco, CA 94102. (415) 252-0500. The issue may be difficult to find, as I obtained the last one available at my doctor's office. Martin Minow minow@apple.com ------------------------------ Date: Wed, 7 Jun 1995 13:22:32 +1300 From: "Gregor Ronald, Wanaka, New Zealand" Subject: Copyright infringed via WWW? New Zealand Press Association carried this story on Wed 7 June 1995: INTERNET COPYRIGHT FEARS Internet users could be breaking the law every time they transfer a file from the global computer network to their own computer, said Ross Johnston, a copyright lawyer of Kensington Swan, speaking at a seminar in Wellington. He said that as well as printing copies or storing them on a computer disk, simply browsing articles on the Internet using a computer screen could be infringing the law. He described the World Wide Web part of the Internet as a giant copying machine. New Zealand's Copyright Act defines copying to include "storing the work in any medium by any means". When a computer user browses information on the Internet, an electronic copy is temporarily created in the computer's memory. Mr Johnston said a copy did not have to be permanent. Copyright specialist Ken Moon, of A.J.Park & Son, in Auckland, echoed this view: "I believe that transient copying is an infringement," he said. ------------------------------ Date: Wed, 7 Jun 1995 12:00:10 (xxT) From: [identity withheld by request] Subject: User-friendly E-mail systems Our organization has a mail system which permits a "user-friendly" addressing scheme. Mail can be addressed to either a userid or part of a user's full name. If there are multiple users with the same last name, mail to that last name will be bounced, with the bounce message listing the names, departments, and userids of all matching users. The following [sanitized] message was recently posted by someone in the Payroll department to an internal group for departmental administrators. I request that all administrators sending me XXX E-mail specifically list my user ID (XXXXX) on the E-mail address. Several E-mail messages addressed to my last name have gone to other XXXX's on the XXX system. Because both my wife and son have E-mail addresses, some of the messages have gone to them. If your request contains specific data relating to an employee, please be sure it is addressed properly. [...] ------------------------------ Date: Wed, 7 Jun 95 08:36:55 +0200 From: erling@wm.estec.esa.nl (Erling Kristiansen) Subject: Re: Ariane-5 test aborted (RISKS-17.16) The accident that caused the death of two technicians was not exactly "failure of the main cryogenic motor". I excerpt from the ESA press release: - The accident happened on May 5 in the Ariane 5 launch area at the Guiana Space Centre. - The cause of death was asphyxiation through inhalation of air having an excessively low oxygen contents. - The reduced oxygen contents was due to a major nitrogen leak into the confined structure of the umbilical mast on the launch table. - The nitrogen leak originated in a nitrogen/iced water exchanger, whose drainage plug was found to be missing. I have not seen any announcement of a delay of tests, so I cannot comment on whether, and how, that may be related to the mentioned accident. ------------------------------ Date: Mon, 5 Jun 1995 15:20:15 -0500 (CDT) From: Carlton Hogan Subject: Re: Drug Addicted Geniuses Built Cyberspace In RISKS-17.15, Daniel Frankowski comments on the moronic thrill-piece "Cyberstoned", Originally from Boston Magazine, and reprinted in the Minneapolis Star Tribune. I too noticed this offensive piece of fluff, and sent the following letter to the editor: To the Editor: "Cyberstoned", in Monday's opinion section is just the latest attempt to demonize the Internet for all of Mankind's pre-existent woes. In the last couple of months, people with no great liking or understanding of the net have cited such spectres as kiddie porn, drug dealing, and even the Oklahoma bombing as compelling reasons to dramatically limit the operation of the net, often in a ham-handed manner. Senator James Exon's (D-NE) recently defunct "Digital Decency Act" would have required all Internet providers to read and censor each of millions of messages a day. Early denizens of the Internet created a benign anarchy, where free speech was it's own best remedy. Ironically, pressure to change the net comes from newcomers, who bought a modem specifically because they heard that there was something new happening on the net. This dynamic reminds me of the process of gentrification, where artists and other fringes types will reclaim urban wasteland. Once the quality of the neighborhood improves, more genteel types move in, and systematically erase all signs of bohemia. Our response to the possibilities offered by the net should not be the neanderthal reflex of killing it because we don't understand it. Carlton Hogan, Editor, PWAlive Community Programs for Clinical Research on AIDS Statistical Center, School of Public Health, University of Minnesota, Minneapolis MN 55414 1-612-626-8899 ------------------------------ Date: Mon, 5 Jun 1995 00:33 -0400 From: Bob_Frankston@frankston.com Subject: Re: New Yorker Article on The 59-Story Crisis (RISKS-17.16) I do recommend reading the Citicorp article. The scary part is that this problems were only uncovered by accident. Also, while the idea of a 1 in 700 year event is considered far-fetched, the midwest floods, which partially recurred this year, Mt St Helen's and imply that somewhere, a very unlikely event will occur. And then there's the World Trade Center. The John Hancock building in Boston, AKA The Plywood Palace, is another example. It got that nickname because its windows were falling out and had to be replaced with plywood. Eventually the problem was solved by simply making the glass a little thicker. But the problems caused some additional attention to be paid to the building including further wind tunnel testing. The building is a flat rectangle (almost) and designers assured it wouldn't fall over on its short side. The surprise was that the building was in danger of collapsing on its long axis! Considering the height, it does make sense that the center of gravity can go far out of alignment, at least, in hindsight. The solution was to be put an active damping system at the top -- pioneered in the Citicorp building. The Citicorp article noted that the damping provides stability but not safety since the power supply is a point of vulnerability. The main lesson is that despite all the writing in this forum about proper procedures, things will go wrong. The question is not so much how to prevent problems but how to respond and recover. Prevention is only an optimization of this process and shouldn't overwhelm the process. A full discussion of this topic is a large topic in its own right, but I'll limit my self to riling the audience in this missive. As a PS, there was an article in the Sunday New York Times (May 29th) about lawyers descending upon Norplant, a long term contraceptive. The article noted that these are the same lawyers who got rich on Silicone (not to be confused with Silicon!) implants. While the Citicorp article emphasized the exemplary behavior of all those involved, reality, if anything, is becoming more problematic. Responsible behavior is often severely punished. If you take any responsibility, you might be liable for punitive damages. It is better not to investigate an area at all, than to learn of a problem and calculate the tradeoffs of dealing with it. Again, this is another topic which would take too much space to fully address in a short not. I've also got to add that I'm not a lawyer and probably don't look much like one either. ------------------------------ Date: Mon, 5 Jun 95 22:33 MET DST From: erik@kroete2.freinet.de (Erik Corry) Subject: Compuserve addresses and a sparse name-space Don Faatz relates that his boss regularly gets E-mail at his Compuserve account that is destined for somebody else whose account differs by only digit. This is another case of a namespace not being sparse enough. It is too simple to hit another real Compuserve address by hitting one wrong number. The risk could be reduced with checksum digits like those used for ISBN and credit card numbers. Other small-namespace culprits include the telephone system (especially when used by semi-automated systems like faxes) and some computer languages (changing a random piece of punctuation in a C program has a chance of resulting in a different, valid program. APL is probably much worse.) To make matters worse, he probably has to pay for the incorrectly sent mail (I have heard this is how Compuserve works, but am not sure). Erik Corry, Freiburg, Germany, +49 761 406637 erik@kroete2.freinet.de ------------------------------ Date: Mon, 05 Jun 1995 22:15:35 GMT From: Mike James Subject: Europe - Central Air Traffic Control Here in Europe we have had central Air Traffic Control for a couple of months. A few weeks back , I was on a flight from Preveza (Western Mainland Greece to London Gatwick). First the flight was delayed by an autopilot that refused to permit the flight from London earlier in the day from climbing above 10000 feet (something to do with fuel load trimming), so they had to turn back, and change the 757 for a Lockheed L1011 (impressive landing on short runway - almost aircraft carrier performance, as the runway wasn't really long enough). Then we sat in the L1011 and waited while the crew tried to: Contact Athens ATC - couldn't give a slot to take off, as Brussels was uncontactable. Contact Brussels Central ATC direct by phone - no answer. Contact London , and get their airline headquarters to phone Brussels - no answer. So we sat for 3 hours until the crew nearly ran out of hours in charge of the plane, until Brussels ATC came back on line. Question : What happens if the ATC goes off-line while you are in the air ? How does the system fall back ? Does it go off-line regularly ? -- Mike James G6IXE ------------------------------ Date: Tue, 6 Jun 1995 19:05:05 +0200 From: ladkin@techfak.uni-bielefeld.de Subject: Re: The standard notion of a `field' (Re: Horn, RISKS-17.15) Rob Horn's article in RISKS-17.16 misuses the concept of `field'. Horn was talking about commutative rings with unit. The standard definition of `field' trivially entails that a division operation is available. The integers don't form a field. However, the integers modulo p, for p a prime number, under addition and multiplication, do. Fields have been studied in mathematics for a long time, well over a century. The standard terminology is at least a half-century old. The definition is given in the following widely available texts: B. van de Waerden, Algebra, a standard reference for a half century and still in print (the oldest reference I could find today is to the 3rd edition in 1950; see p39 of the Springer German edition); S. Lang, Algebra (3rd edition p93); S. Maclane and G. Birkhoff, Modern Algebra (1967, p133); and T. Hungerford (1973, Springer edition 1980, p116). Peter Ladkin ------------------------------ Date: Tue, 6 Jun 1995 21:19:34 +0059 (EDT) From: Robert J Horn Subject: Re: The standard notion of a `field' Sorry, you're right. Somewhere along the years I did a mental slip. I should have been using the term commutative ring. I've probably left behind a few years of confused people. Actually computer integers are suffer further in that they are not actually a ring either, because there is a maximum value beyond which addition or multiplication fail. I should not have been using the term finite field, it should have been commutative ring. And my apologies to the readership. R Horn ------------------------------ Date: Thu, 07 Jun 95 19:35:55 GMT From: ts4@piis10.joanneum.ac.at Subject: Telematic Sculpture 4 (T.S.4) A mobile sculpture (length 21,8 meters, weight 1800 kg) by R. Kriesche is physically positioned in the Austrian Pavilion during the Venice Biennale. T.S.4 is driven by the data flow in the Internet, according to the ratio of the worldwide COMPUTER newsgroups versus worldwide ART newsgroups. According to this relation, T.S.4 is expected to transcross the Austrian pavilion during the time of the biennale and might even break through the wall of the pavilion. You are invited to become part of T.S.4 by: o visiting its www homepage http://iis.joanneum.ac.at/kriesche/biennale95.html o discussing T.S.4 on usenet news o sending E-mail to T.S.4 (mailto:ts4@iis.joanneum.ac.at) Your participation will slow down the movement of T.S.4 and prevent it crashing. [The risks of such an event are left as an exercise for the reader. PGN] ------------------------------ Date: Wed, 7 Jun 95 12:05:09 PDT From: "Peter G. Neumann" Subject: Privacy Digests Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing detailed discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 16, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. ------------------------------ End of RISKS-FORUM Digest 17.17 ************************ 15-Jun-95 19:06:07-GMT,29187;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id PAA03194 for ; Thu, 15 Jun 1995 15:06:02 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id PAA05637 for ; Thu, 15 Jun 1995 15:05:59 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id PAA01395 for ; Thu, 15 Jun 1995 15:05:54 -0400 Received: by chiron.csl.sri.com id AA04617 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Thu, 15 Jun 1995 11:56:28 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 15 Jun 95 11:56:27 PDT Subject: RISKS DIGEST 17.18 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Thursday 15 June 1995 Volume 17 : Issue 18 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Flash: Netflashing unflashionable [Exon ...] Another TCAS incident (Stephen L Nicoud) Re: Europe - Central Air Traffic Control (Jim Wolper) Sun's "talk" program (Steve Kilbane) Multo ante natus eram (Bernard S. Greenberg via Donna Woodka) U.K. Lottery Computers Hit by Gremlins (Mich Kabay) ``Fatal Defect: Chasing Killer Computer Bugs'' by Ivars Peterson (PGN) "Computer error" not a basis for suppressing evidence (Curt Karnow) Gambling on the Internet (Samuel Edward Greenfield) Re: "Nautilus foils wiretaps" (D.J. Bernstein) The risk of not caring about Prodigy (Bob Morrell) Flawed instructions for anonymous mail (Tony Harminc) Absurd New Zealand copyright violations (Bruce Johnson, J. Wilson, Chuck Karish, Mike Hocker) One Week Course on Internet Security, July 24-28, at Stanford (Arthur Keller) People, Networks and Communication... an invitation (Robert Mathews) ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] ---------------------------------------------------------------------- Date: Thu, 15 Jun 95 11:22:41 PDT From: "Peter G. Neumann" Subject: Flash: Netflashing unflashionable [Exon, Exoff; Exrated, Execrated?] For the benefit of the RISKS archives, if nothing else, let me note that the U.S. Senate voted 84 to 16 yesterday for the Exon amendment to the telecommunications bill. Senator Exon's measure imposes fines up to $100,000 and prison terms up to two years for knowingly transmitting indecent material over a computer network accessible to minors. It also applies to "obscene lewd, lascivious, filthy or indecent" comments, requests, or suggestions intended to annoy or harass. Decidedly in the minority of senators on this issue, Senator Leahy produced a stack of petitions from some 35,000 people (presumably most of whom used E-mail) who believe that Exon's measure is a serious threat to constitutional rights, free speech, and the Internet. ------------------------------ Date: Thu, 8 Jun 95 07:59:26 PDT From: Stephen L Nicoud Subject: Another TCAS incident *Aviation Daily* reports in its "Intelligence" section 8 Jun 1995 that an erroneous command in TCAS (Traffic Alert and Collision Avoidance system) nearly resulted in a midair collision Sunday involving a United 737 and a Viscount Air Services 737, both on approach. After both aircraft received a TCAS warning, the United airplane began to climb from 10,000 feet to 12,000 feet while the Viscount plane started to descend to 10,000 feet. The aircraft came within 200 feet of each other before controllers instructed the Viscount flight to return to 11,000 feet. The incident occurred in the ``Northwestern portion of the U.S.'' Stephen L Nicoud [Disclaimers] ------------------------------ Date: Thu, 8 Jun 95 10:42:51 -0600 From: Jim Wolper Subject: Re: Europe - Central Air Traffic Control (James, RISKS-17.17) Mike James asked "What happens if the ATC goes off-line while you are in the air?" I am an instrument flight instructor, and this is one of the major points of instrument training. There are very specific rules about which routes and altitudes a pilot must use, as well as when s/he can begin the landing approach to the airport. Basically, the pilot must follow the clearance given by ATC, at the altitude to which the aircraft has been cleared (there are exceptions that enable the aircraft to safely climb for higher terrain). The landing approach should begin at the Estimated Time of Arrival computed from the actual time of departure and the time enroute specified in the flight plan. The primary purpose of the ATC system is to separate aircraft operating under Instrument Flight Rules (IFR), and the _assumption_ is that ATC knows the pilot's intentions so they can clear out the necessary airspace. Clearances are formulated to prevent potential collisions in the event of widespread communications outages (for example, I was once approaching a busy airport under IFR and the approach controller accidentally turned off his transmitter). The system is by no means perfect, but there are backup modes in place, and all operators (pilots and ATC) are trained in their use. The human-in-the-loop aspect also makes the system more robust. Pilots and controllers know to try to contact each other over many different frequencies and methods (eg, in the approach control incident above, we used the local controller's frequency to call someone in the same building. It is also common for ATC to have Flight Service, a different agency, contact aircraft with lost communications over navigational frequencies, private frequencies, and the like.) The worst case scenario -- complete outage of ATC radio communications -- would probably be handled by pilots using air-to-air communications. (This is in fact the standard for separation of IFR traffic in more remote sections of Australia.) Jim Wolper, CFII Department of Mathematics Idaho State University ------------------------------ Date: Tue, 13 Jun 1995 14:56:41 +0100 From: Steve_Kilbane@cegelecproj.co.uk (Steve_Kilbane) Subject: Sun's "talk" program I don't know whether this applies to many variants of "talk", but this hit me on a SunOS 5.3 box. Talk allows direct interaction with another user elsewhere on the network. Each user types text into a "window" on the screen, and the other user sees the text appear on the other window on their own screen. The problem is that when one user breaks the connection, the program also terminates for the other user. In my case, I was just finishing off a line ("bye") and hitting return when the other user disconnected. "by" had been read by talk, leaving "e\n" to be read by my shell. The RISK, of course, is that users can accidentally invoke potentially damaging commands by doing this. All I did was run a line editor, but supposing I'd been giving advice: "whatever you do, don't type [exit] rm -rf $HOME"... Steve ------------------------------ Date: 8 Jun 1995 22:45:59 GMT From: "Bernard S. Greenberg" Subject: Re: Multo ante natus eram [A woodka tonic forwarded to RISKS by Donna Woodka , who probably knows my penchant (or even pun-chant) for Multics tales. Thanks to Bernard for having fortifived our archives and providing evidence that Multics still lives! PGN] Ward Anderson at ACTC just reported an interesting crash on Multics (10.2) at ACTC -- Collection 1 initialization discovered that I became 45 years old Tuesday past, an event which was extremely unlikely, and crashed the system before the clock did damage to the file system, or so it feared. The code in scs_and_clock_init is perfectly clear - the time "06/06/95 18:31 est Tuesday" is hard-coded in, in characters, with the comment that it is "Bernard S. Greenberg's 45th birthday". It has been there for twenty years in plain text visible to anyone reading the code! (I loved to read code in my day, especially initialization - perhaps I was the last?) Maybe Tom Van Vleck remembers, but it is extremely likely that twenty years ago at CISL our operator at the time for the nth and last time forgot to set the clock, or set it poorly, and damaged the file system (which looks quite askance on "back to the future" jaunts), and Tom and I said "This has to end. We have to put a gullibility check in the clock init code", and I did this. Probably saved a lot of file system damage over the years. If I had it to do over again, I'd do it over again! This code did the -right-thing-! At 25, I could not imagine I'd ever be 45, let alone that scs_and_clock_init.pl1 would be there along with me! Somehow, though, 65 doesn't seem that far away any more... As Ward said, this is a -real- Multics story. Bernie bsg@basistech.com -------------------------------- Date: 12 Jun 95 18:24:33 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> Subject: U.K. Lottery Computers Hit by Gremlins >From the Press Association (U.K.) news wire via CompuServe's Executive News Service, 10 Jun 1995 LOTTERY COMPUTERS HIT BY GREMLINS, by Sarah Vincent, PA News National Lottery computer outlets throughout the UK crashed today -- ahead of tonight's expected record [pounds] 20 million jackpot prize-draw. Terminals across the country failed just after 11.30am when part of the satellite network broke down. Engineers traced the failure to a piece of equipment at the Camelot headquarters which was replaced and the system was running within 15 minutes. Other points in the article: o Breakdown definitely not due to resource saturation; was not busiest time in their history. o 51 terminals affected country-wide. M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA) ------------------------------ Date: Wed, 14 Jun 95 15:19:53 PDT From: "Peter G. Neumann" Subject: ``Fatal Defect: Chasing Killer Computer Bugs'' by Ivars Peterson Fatal Defect: Chasing Killer Computer Bugs Ivars Peterson Times Books (Random House) 1995 ISBN 0-8129-2023-6 Ivars Peterson is a fine writer who is well-known for his articles in _Science News_ on physics, math, and computers. His fourth book (``Fatal Defect ...'') is a wonderfully readable work that threads its way gently through some computer-system problems that will be familiar to those of you who are old-time RISKS readers. Peterson does this with a fresh view of the problems and their origins, so that the book is worth reading by everyone -- experienced and novice, young and old, technologists and nontechnologists, optimists and pessimists. Peterson also brings to life many of the people behind the scenes, some of whom are quite familiar to RISKS readers. ------------------------------ Date: Thu, 8 Jun 95 12:27:44 PDT From: karnow@cup.portal.com Subject: "Computer error" not a basis for suppressing evidence Original-Subject: Unlawful arrest based on computer error does not lead to exclusion of evidence The United States Supreme Court in Arizona v. Evans (March 1, 1995) discussed an illegal arrest precipitated by a "computer error." A man was arrested based on what police officers thought was an outstanding warrant for his arrest; in fact the warrant had been quashed; court clerical personnel had failed to clear the warrant from their computer system. The police thus had no legal basis for the arrest. Following the arrest, the police found a bag of marijuana. The issue was whether the marijuana evidence should be suppressed (which would have the effect of dismissing the case). The state court threw out the evidence under the old suppression rule -- holding that the "fruit" (drugs) of the poisonous tree (the illegal arrest) should not come into evidence. The U.S. Supreme Court reversed, and held that the purpose of the exclusionary rule -- to encourage proper police procedures -- would not be furthered by tossing the evidence. The Supreme Court found that excluding the evidence would not have a significant effect on the actions of court personal, and thus that errors by court clerks were not a basis for excluding evidence. The Court did not address whether court personnel's outright misconduct, and such personnel's deliberate efforts to violate peoples' constitutional rights, would lead to the exclusion of evidence, but the reasoning in this case strongly suggests that such misconduct would *not* lead to exclusion. ------------------------------ Date: Tue, 6 Jun 1995 17:36:14 -0400 (EDT) From: Samuel Edward Greenfield Subject: Gambling on the Internet A Clarinet brief, news:newsbriefUR992_5u6@clarinet.com, if you have Clarinet, stated that a group of people would like to "bring the thrill of casino gambling to the Internet." There are clearly many risks to this. First, there is no way to verify that the person gambling is who they say they are. That is, I can easily steal someone's credit card and spend money at a digital casino without them knowing. Of course, if I win, the other person might be happy if their credit card is credited, but chances are, I will lose their money. Second, there is no way to verify the age of the player. There are already problems with minors gambling in real casinos and there will certainly be a problem with minors gambling in virtual ones. Third, there is absolutely no way to tell if the house is cheating or not. At least in a real casino, there are video tapes of the dealer or operator and independent auditors. I am curious who the digital gambling houses will hire to audit their systems. Fourth, what happens when bugs are discovered in the code? This can cut both ways: the computer might give away too much money, or the computer could never let anyone win. The brief on Clarinet said the Justice Dept. said gambling via the Internet may break many laws. However, even if it doesn't, I think people would really be taking a big risk by gambling on the Internet. (Of course, that is really the point of gambling anyway, isn't it?) Sam [1st, crypto-based authentication technology is progressing, but will never be completely foolproof. 2nd, NO WAY is perhaps too strong. 3rd, NO WAY, perhaps; you could have bonded/trusted third-parties -- although the casinos would object. 4th, bugs? Gee, you think there might be bugs? BTW, see Home Gambling Network (Kabay), RISKS-16.86, and my April Fools' semispoof in RISKS-17.02 for some further background on this topic. PGN] ------------------------------ Date: Thu, 8 Jun 1995 15:43:16 -0700 From: "D. J. Bernstein" Subject: Re: "Nautilus foils wiretaps" (PGN comment on Back, RISKS-17.16) PGN comments on the cryptographic mailing label shown in the New York Times: > As I recall, the left margins were (intentionally?) fuzzied. Strangely enough, the same mailing label was published the same day in the Washington Post, with the _right_ margins fuzzied. Anyone who picked up both papers could easily piece together the whole label. Which paper has violated the export control laws? Okay, I'm kidding about the Washington Post, but the question remains. ---Dan ------------------------------ Date: Tue, 6 Jun 1995 15:11:39 -0400 (EDT) From: Bob Morrell Subject: The risk of not caring about Prodigy In RISKS-17.17, I worried out loud about the broader possible implications of the recent ruling against Prodigy. My concern was, and remains, that by viewing Prodigy as a newspaper because it exerts =some= editorial control, the courts failed to make distinctions both of degree and technology. Like the moderator of this forum, I worried about forums which may be edited (by post rejection) to increase signal noise ratios, or to eliminate off topic posts. Such forums, could, if the Prodigy ruling reflects a lack of discernment by the courts, be forced to discontinue or begin much more controlled editing. I found this somewhat incredible, since it meant that the ruling could well lead to more censorship, and worse, less forums. To my surprise, my mailbox began filling with mail from individuals quite happy about the ruling, most specifically, happy about any discomfort to Prodigy. Now, I am neither a friend to censorship nor to Prodigy, but I found the enmity towards this private business puzzling. After all, anyone is free to subscribe or not subscribe. While I oppose censorship, I also oppose interfering with what private businesses offer to their customers. Since, to my knowledge, Prodigy never guaranteed that the facts in any post appearing on their system were true, to hold them liable is to force them to do something for their customers that was not in the contract voluntarily agreed to by both Prodigy and its subscribers. The RISK I am perceiving is this: the popular net bias against filters, censors, and restricted info access, (however justifiable) has created such hatred against Prodigy, which appears to be practicing the most control of any provider (though still nothing like a newspaper) has people cheering over its loss in the courts despite the fact that the ruling holds grave risks to the internet and its culture as a whole. Bob Morrell bmorrell@isnet.is.wfu.edu ------------------------------ Date: Tue, 13 Jun 95 13:37:00 PDT From: HARMINC Tony Subject: Flawed instructions for anonymous mail Frank Magazine, an Ottawa based satirical/gossip magazine solicits assistance (leaks) on various hot topics via their Web page http://www.achilles.net/~frankmag/ : "FRANK is currently conducting inquiries into the subjects listed below. Any assistance you could render in this regard would be greatly appreciated. To let us know about without tipping off your electronic-surveillance-happy superior, just delete the name and e-mail address in your browser's mail preferences file." ... Later they have more detailed instructions for temporarily removing one's name and address from Netscape. Whether Frank actually believes that this will defeat corporate/government mail snoops isn't clear, but there are probably going to be some people who act on their advice and get burned. Tony Harminc Antares Alliance Group Toronto Software Development Centre tzha0@toraag.com ------------------------------ Date: 13 Jun 1995 17:59:42 GMT From: johnson@tonic.pharm.arizona.edu (Bruce Johnson) Subject: Absurd New Zealand copyright violations (Re: Ronald, RISKS-17.17) Here is a prime example of the idiocy (IMHO) of non-technically oriented lawyers expounding on copyright infringement on the internet... these are the same people that say, technically, you need two legal copies of any form of software, because it is read off the disk into memory, so you have two copies at once. Both lead to situations where the law is completely unenforceable. Given the growing popularity of the Web as a internetworking paradigm, the only way to avoid your copyrights being violated is to keep your material off the Web...a dandy way to ensure that a significantly smaller audience (market?) has anything to do with your work. Carried to it's logical, if utterly absurd conclusion, reading anything is a copyright violation, because we certainly store significant quantities of the information in our brains. When a user browses ANY sort of information on a computer, a temporary copy is made, even if only in a screen buffer. When opinions like this get floated about, unfortunately, the real issues of maintaining copyright protections in a distributed network environment like the Web get buried in the silly stuff, which in the present (at least in the US) legal climate leads to 'ban everything' stupidity. Bruce Johnson Information Technology/College of Pharmacy The University of Arizona johnson@tonic.pharm.arizona.edu ------------------------------ Date: Sat, 10 Jun 95 06:17:00 UTC From: j.wilson23@genie.geis.com Subject: Absurd New Zealand copyright violations (Re: Ronald, RISKS-17.17) Similar thinking allegedly prevails in the committee appointed to study copyright law under US Vice President Al Gore's "Reinvention of Government" program, as reported in the April, 1995 issue of SCIENTIFIC AMERICAN. Literal interpretation of the New Zealand Act's language as quoted above would prevent many uses in the classroom as well as boardroom. A simple overhead projector would produce a "transient" copy on the silvery screen, to name one instance. One may presume that "fair use" or a general license for educational purposes would allow the overhead projector use, but how does this differ from using a web browser to allow all of the audience to view the same document? Quibbling with the definition of "medium," I could argue that the virtual images created by eyeglasses constitute a copy. Should we wish to pursue the matter ad absurdum, an image of the material is stored in the colloidal medium of the viewer's central nervous system, though this may be considered an abstract only, at least given this RISKS reader's memory. The RISK is of course making sweeping provisions in law that at the time of legislation seem to encompass very little, while human innovation tiles those sparsely-settled plains more quickly with each passing year. ------------------------------ Date: 12 Jun 1995 07:06:26 GMT From: karish@mindcraft.com (Chuck Karish) Subject: Absurd New Zealand copyright violations (Re: Ronald, RISKS-17.17) I've seen and heard a number of "warnings" of this sort. They strike me as belonging in the same category as Chicken Little's concern that the sky is falling, for two reasons. First, the fact that someone who owns the rights to a piece has published it to the World Wide Web can be construed as permission to make a transient copy for the purpose of viewing and/or listening to the piece. Someone who wishes to prevent others from keeping more persistent copies of such works should protect the relevant rights by causing a statement of reservation of rights to be presented alongside the works to be protected. Second, the people who own the copyrights and the people who make the laws that govern them (a) are not all idiots and (b) do talk to each other. The problem on this level is easy to fix. There are much more difficult problems concerning intellectual property on the Web and the Internet. Let's not spend too much effort worrying about the trivial ones. -- Chuck Karish karish@mindcraft.com 415 323 9000 x117 ------------------------------ Date: Tue, 13 Jun 95 14:57:41 EDT From: horse7@VNET.IBM.COM Subject: Absurd New Zealand copyright violations (Re: Ronald, RISKS-17.17) >New Zealand's Copyright Act defines copying to include "storing the work in >any medium by any means". ... Any medium/any means? How about if the work is memorized? _Reductio ad absurdum_ perhaps... a new way to avoid schoolwork: the assignment to memorize the passages requires illegal behavior! Mike Hocker (horse7@vnet.ibm.com) ------------------------------ Date: 13 Jun 1995 06:14:39 GMT From: ark@Office.Stanford.EDU (Arthur Keller) Subject: One Week Course on Internet Security, July 24-28, at Stanford The Western Institute of Computer Science announces a Practical Week-long Course for Consultants, Educators, Government and Industry Scientists and Engineers on INTERNET SECURITY, at Stanford University July 24-28, 1995. This course is taught by leading researchers and practitioners in the area of internet security: Arthur M. Keller, Dave Crocker, Tina M. Darmohray, Whitfield Diffie, Mark Eichin, Gail Grant, Lance Hoffman, Sushil Jojodia, Peter Neumann, Allan M. Schiffman, and William Wong. Participants will receive a grounding in internet security, familiarity with current concepts and issues, and exposure to the most important research and development trends in the area. Connecting to the Internet brings both unparalleled information resources and unparalleled security dangers. Protecting computer systems and networks from attacks is a critical and ongoing process. Equally important is protecting corporate intellectual property assets from inappropriate access. This course will examine a variety of network security topics, including protecting against intrusion, detecting and tracking intruders, and repairing damage after intrusion. The course will begin with a survey of basic security concepts, followed by a detailed description of cryptography. We will then cover Internet security architecture and identification and authentication. The course will then cover specific security technologies. These include network firewalls, which provide perimeter security, intrusion detection systems, Kerberos and addition of security to existing network applications, secure messaging, secure payments, and World Wide Web security, including Secure HTTP and SSL. This course will also analyze security issues for electronic commerce, such as viruses and cryptographic policy. We will also show a videotape presentation on SATAN by Dan Farmer, one of its developers. FOR INFORMATION: Call Western Institute of Computer Science at (916) 873-0575; OR E-mail to barnhill@hudson.stanford.edu; OR WRITE to P.O. Box 1238, Magalia, CA 95954; OR FAX (916) 873-6697. [Tell them RISKS sent you, and see if they know what that means.] ------------------------------ Date: Tue, 13 Jun 1995 18:23:10 -1000 (HST) From: Robert Mathews ICICX-PNC Subject: People, Networks and Communication... an invitation For our academic, scientific and educational colleagues who are participants in the IT, CS, IRM, Computer/Information/Network Security, Integration, Interoperability, Network Services, Network Metrics or Policy fields, please consider this your PERSONAL invitation to PNC - People, Networks and Communication '95.. TITLE: " PNC - People, Networks & Communication '95 " (C) THEME: " Turning 21 - A Journey to Maturity in Communications" (C) TOPIC: " The Emergence of Application, Information Technology & Policy for the 21st Century." DATES: October 30 - November 3, 1995 VENUE: Mid-Pacific Conference Center, Hilton Hawaiian Village Resort. Honolulu; Island of Oahu - " The Gathering Place ", Hawaii. For information, send E-mail to: bm189@po.CWRU.EDU Sponsored by ICICX - International Community Interconnected Computing eXchange / The Pacific Network Consortium Ltd., involved in Information Technology Research, Planning & Practice. Dr. Ernest Kho, Jr. Mr. Robert Mathews. Conference Chairman Conference Coordinator University of Hawaii. ICICX Telephone: + 808.933.3383 Telephone: + 808.921.2097 Telecopier: + 808.933.3693 Telecopier: + 808.921.2097 E-mail: ekho@uhunix.uhcc.hawaii.edu E-mail: bm189@po.CWRU.EDU ------------------------------ Date: 24 April 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED Info on RISKS (comp.risks) [See other issues for full info] The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] REQUESTS to (which is not yet automated). [...] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [...] RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] ------------------------------ End of RISKS-FORUM Digest 17.18 ************************ 19-Jun-95 22:33:59-GMT,28469;000000000001 Received: from aramis.rutgers.edu (root@aramis.rutgers.edu [128.6.4.2]) by klinzhai.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id SAA05771 for ; Mon, 19 Jun 1995 18:33:58 -0400 Received: from RUTGERS.EDU (RUTGERS.EDU [128.6.21.9]) by aramis.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id SAA05924 for ; Mon, 19 Jun 1995 18:33:55 -0400 Received: from chiron.csl.sri.com (chiron.csl.sri.com [192.12.33.73]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id SAA10690 for ; Mon, 19 Jun 1995 18:33:52 -0400 Received: by chiron.csl.sri.com id AA07485 (5.67b/IDA-1.4.3 for McGrew@RUTGERS.EDU); Mon, 19 Jun 1995 15:24:12 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 19 Jun 95 15:24:11 PDT Subject: RISKS DIGEST 17.19 Reply-To: risks@csla.csl.sri.com To: RISKS-1:; Message-Id: RISKS-LIST: Risks-Forum Digest Monday 19 June 1995 Volume 17 : Issue 19 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Summer Slowdown for RISKS (PGN) Bank computer develops costly crush on Fiona (Peter Ilieve) The Royal Majesty (Bob Frankston) For DOS/Windows users: Trojan Alert- PKZ300B.EXE (Patrick Weeks via Fred Gilham) Re: The New York subway crash (Mark Stalzer) Re: 59-Story Crisis: The Risks of Unions (Chuck Weinstock) Internet gambling (Andrew Koenig) The media & risks (Justin Wells) CFP: ISOC Symposium on Network & Distributed System Security (Clifford Neuman) Re: Multo ante natus eram (Mike Alexander, Mike Crawford) Prodigy paranoid reaches Tasmania? (Richard Murnane) Re: not caring about Prodigy (Jim Hill, Bob Morrell, Jim Hill) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 19 Jun 95 08:01:17 PDT From: "Peter G. Neumann" Subject: Summer Slowdown for RISKS RISKS will be more or less off the air from now until July 24. I will probably not be able to answer many of your queries and requests during that period even when I am on-line. Continuations of recent ongoing discussions are likely to cease as of this issue. However, please send in all interesting NEW items that you encounter. For our 10th anniversary RISKS issue on 1 August 1995, I would be very happy if a few of you would submit (by 24 July) concise and well-reasoned think-pieces on what we might have learned in the past 10 years, with respect to some aspect of the RISKS experience. Have things improved? Or are we collectively treading water -- or being washed out to sea? What is missing? Are the real problems technological or otherwise? (The best reflective contributions might even wind up as Inside Risks columns in the CACM!) I hope you all have a pleasant summer. PGN ------------------------------ Date: Sun, 18 Jun 95 20:51:25 BST From: peter@aldie.co.uk (Peter Ilieve) Subject: Bank computer develops costly crush on Fiona That was the headline on a piece in *The Times* (London) on 15 June 1995 about a Barclays Bank computer system that deals with loans and mortgages to bank staff. It was running a new accounting system, and it refused to generate monthly repayments for more than 100 staff named Fiona. Nobody else was affected, including a Ffyona. Numerous Fionas were sufficiently honest to contact the bank and ask why their repayments hadn't been deducted. It isn't clear how long the lucky Fionas would have had their repayment holidays if some of them hadn't owned up. The bank is adamant no hacking was involved. A spokeswoman blamed `a blip' and added, `Our systems people say that they knew how to solve the problem even if they could not explain what precisely had caused it.' Peter Ilieve peter@aldie.co.uk ------------------------------ Date: Mon, 19 Jun 1995 14:25 -0400 From: Bob_Frankston@frankston.com Subject: The Royal Majesty The Royal Majesty is the cruise ship that ran aground off Nantucket. There is a good article in *The Boston Globe* 19 Jun 1995 by David L Chandler entitled "Embarrassing lessons for navigators". It is a good "risks style" article that covers various issues including the question of whether the GPS system indeed failed and was 17 miles off. It discusses issues of the user interface -- is navigation information presented in such a way as to actually be usable during hectic periods? It brings up question of whether it is safe to turn off Loran, the Valdez accident, and other pertinent issues. Nothing particularly new for Risks readers, but it is worthwhile to note reasonable articles in the newspapers. ------------------------------ Date: Mon, 19 Jun 1995 10:34:05 -0700 From: Fred Gilham Subject: For DOS/Windows users: Trojan Alert- PKZ300B.EXE ------- Forwarded Message *** Subject: TROJAN ALERT: PKZ300B.EXE / PKZ300B.ZIP *** **************************** Important Notice ************************* Some joker out there is distributing a file called PKZ300B.EXE and PKZ300B.ZIP. This is NOT a version of PKZIP and will try to erase your harddrive if you use it. The most recent version is 2.04G. Please tell all your friends and favorite BBS stops about this hack. Thank You. Patrick Weeks Product Support PKWARE, Inc. *********************************************************************** ------------------------------ Date: Fri, 16 Jun 95 08:30:38 EDT From: mstalzer@etsd.ml.com (Mark Stalzer) Subject: Re: The New York subway crash (PGN, RISKS-17.17) As reported in the June 16 New York Times, further investigation of the 5 Jun 1995 NY subway crash (which killed the motorman and injured 54 people) indicates the distance between signals is shorter than the stopping distance of a modern train. Speculation right after the accident had focused on a possible emergency brake failure. However, even with the brake engaged, tests showed it takes approximately 360ft for the train to stop. Unfortunately, the rear of the forward train was only 288ft from the signal. It now appears that the motorman ran the red signal, which tripped the emergency brake and slowed the train from about 32mph (the maximum speed after climbing the hill leading to the crash area) to 14-18mph at the time of impact. The signal spacing was set in 1918 when trains were shorter, lighter, and slower than modern trains. The Transit Authority has been upgrading the trains without upgrading the control system. A familiar RISK. The immediate response has been to limit speeds on the section of track where the accident occurred. When a TA official was asked if speeds will be reduced in other areas, the official said "we don't know where the potential trouble spots are." I guess we're just going to wait for more accidents to find the areas that need fixing. Another familiar RISK. Mark Stalzer, mas@acm.org ------------------------------ Date: Mon, 12 Jun 95 12:10:30 -0400 From: Chuck Weinstock Subject: Re: 59-Story Crisis: The Risks of Unions One of the risks that continues to haunt me from that article (and apparently others as well since my mother mentioned it to me when we discussed the article) is this: (The people in charge of repairs to the building had installed strain gauges connected by wire to readouts in the main office.) One time, the readings went off the chart, then stopped. This provoked more bafflement than fear, since it seemed unlikely that a hurricane raging on Lexington and Fifty-third Street would go otherwise unnoticed at Forty-sixth and Park. The cause proved to be straightforward enough: When the instrumentation experts from California installed their strain gauges, they had neglected to hire union electricians. `Someone heard about it,' LeMessurier [the building designer] says, `went up there in the middle of the night, and snipped all the wires.' Chuck Weinstock ------------------------------ Date: Thu, 15 Jun 95 20:01:01 EDT From: ark@research.att.com Subject: Internet gambling I remember once reading a paper with a synopsis something like this: This paper is in two parts. In Part 1, we prove that it is impossible to play a fair game of telephone poker. In Part 2, we give an algorithm for playing a fair game of telephone poker. The apparent paradox, of course, was that the algorithm in Part 2 was actually unfair with a probability that could be made as small as desired by making the crypto keys long enough. I wish I remember the title or author of the paper. Anyway, such things leave me with the distinct impression that Internet gambling is no less feasible than any other kind of electronic commerce. Andrew Koenig ark@research.att.com [For the short-term future, we will see many small-scale efforts such as this one, whether or not they are soundly based. In the long-term, we still need a secure infrastructure and trusted servers and trustworthy individuals and more laws (and lawyers) to give it a real semblance of "fair". (We might refer to this as "secure infostructure".) PGN] ------------------------------ Date: Mon, 19 Jun 1995 01:23:24 -0400 From: rjwells@undergrad.math.uwaterloo.ca (justin wells) Subject: The media & risks It occurred to me that the stories in comp.risks are often sensationalistic enough to warrant widespread media coverage. In fact, a good chunk of stuff posted here is drawn from the media, with commentary added. One risk commonly mentioned here is that "the public" or "the media" haven't got enough understanding of computer risks, and that we're all going to suffer as a result -- recently there's been discussion of lawyers who don't understand computers, etc. Well -- Has anyone tried convincing some television producers to add a computer risk segment to their news programs? There's easily enough material that's interesting enough that's already part of their program -- to make it a proper segment all that would be required is the addition of a brief editorial highlighting for the public the general nature of the particular risk. I think it would be interesting enough to sell (but then as a regular reader of comp.risks I'm biased :) I don't have the background or the experience or the connections or anything else to try and make something like this actually happen, but I'm sure that somewhere out there in RISKS land, someone does... Imagine the benefits of having computer risks dealt with sensibly on CNN. Here in Canada the late night news just ran an extensive segment on the risks of cellular phones and radios interacting with medical equipment, so it's not like the media is opposed to the idea. What with all the hype about the Internet these days, I think there's a major window of opportunity... Justin rjwells@undergrad.math.uwaterloo.ca ------------------------------ Date: Sun, 18 Jun 1995 06:49:34 -0700 From: Clifford Neuman Subject: CFP: ISOC Symposium on Network & Distributed System Security CALL FOR PAPERS The Internet Society Symposium on Network and Distributed System Security February 22-23, 1996 San Diego Princess Resort, San Diego, California GOAL: The symposium will bring together people who are building hardware and software to provide network and distributed system security services. The symposium is intended for those interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. We hope to foster the exchange of technical information that will encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. Symposium proceedings will be published by the IEEE Computer Society Press. Topics for the symposium include, but are not limited to, the following: * Design and implementation of communication security services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Design and implementation of security mechanisms, services, and APIs to support communication security services, key management and certification infrastructures, audit, and intrusion detection. * Requirements and designs for securing network information resources and tools -- WorldWide Web (WWW), Gopher, archie, and WAIS. * Requirements and designs for systems supporting electronic commerce -- payment services, fee-for-access, EDI, notary -- endorsement, licensing, bonding, and other forms of assurance. * Design and implementation of measures for controlling network communication -- firewalls, packet filters, application gateways, and user/host authentication schemes. * Requirements and designs for telecommunications security especially for emerging technologies -- very large systems like the Internet, high-speed systems like the gigabit testbeds, wireless systems, and personal communication systems. * Special issues and problems in security architecture, such as interplay between security goals and other goals -- efficiency, reliability, interoperability, resource sharing, and cost. * Integration of security services with system and application security facilities, and application protocols -- including but not limited to message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. GENERAL CHAIR: Jim Ellis, CERT Coordination Center PROGRAM CHAIRS: David Balenson, Trusted Information Systems Clifford Neuman, USC Information Sciences Institute REGISTRATIONS CHAIR: Donna Leggett, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Deadline for paper submission: August 14, 1995 Notification sent to authors by: October 16, 1995 Deadline for camera-ready copy: November 13, 1995 Submissions must be received by 14 August 1995. Submissions should be made via electronic mail. Submissions may be in either of two formats: PostScript or ASCII. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions should arrive well before 14 August. If electronic submission is difficult, submissions should be sent via postal mail. All submissions and program related correspondence (only) should be directed to the program chair: Clifford Neuman University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695 Phone: +1 (310) 822-1511 FAX: +1 (310) 823-6714 Email: sndss96-submissions@isi.edu Dates, final call for papers, advance program, and registration information will be made available at the URL: http://nii.isi.edu/info/sndss Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 16 October 1995. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 13 November 1995. [Program committee and a few others deleted. PGN] ------------------------------ Date: Thu, 15 Jun 1995 19:45:13 -0400 From: Mike.Alexander@umich.edu (Mike Alexander) Subject: Re: Multo ante natus eram I, too, am glad to see that Multics is still used. It is a system that was far ahead of its time in many respects. In MTS (the Michigan Terminal System), a system contemporaneous with Multics which is also still in use, we solved the problem of the operators entering a bad time in a slightly different way. During initialization, the system compares the current time with the time in the last billing record recorded. If the current time is earlier or too much later (more than 12 hours, unless the day is Sunday in which case 18 hours is ok) it complains and asks the operators to confirm that the time is ok. This has several advantages: it doesn't use hard-coded dates, it is a more precise check, and it never makes the system unusable. Of course this has become less important as modern machines maintain the time of day even when not running and the clock rarely needs to be set at all. Mike Alexander, Univ. of Michigan Mike.Alexander@umich.edu MAlexander@aol.com ------------------------------ Date: Fri, 16 Jun 95 19:14:26 -0700 From: Mike_Crawford@quickmail.apple.com (Michael D. Crawford) Subject: Re: Multo ante natus eram Last fall I worked on the 2Market home shopping CD. This is a CDROM catalog with pictures of products from many popular mail-order catalogs, with QuickTime movies of TV commercials, and sound clips of record albums. One of the features of 2Market is that items go on sale. Of course the sales have to be prepared in advance, and the user will only get it right if their clock is set. Knowing my own habit of living in the year 1904, the Macintosh beginning of history (for no reason I can really fathom), I convinced the designers to let me put in a warning that your clock is off. The warning is placed in the message box that is normally used to inform the users that items are on sale. Any date that is before we shipped the CD, or after (I think) a year after the CD shipped warns the user to reset their clock. Shorter times afterwards give the user the number to order the next CD. Let's hope they always remember to update the code when they ship new versions... I'm not with Medior anymore to remind them. Mike Crawford Mike_Crawford@QuickMail.Apple.Com ------------------------------ Date: Sun, 18 Jun 1995 12:56:27 +1000 (EST) From: Richard Murnane Subject: Prodigy paranoid reaches Tasmania? The following recent news release from the Wireless Institute of Australia suggests that some people are getting very nervous, following the Prodigy defamation case in the USA: The name of the gateway is just one of those ironic little twists. :-) PACKET GATEWAY DEMANDS STAT. DEC. FROM AMATEURS The Launceston Institute of TAFE [Technical and Further Education] in northern Tasmania, which runs an amateur radio packet-to-Internet gateway known under the acronym of LITGATE, is requiring radio amateur users to file a statutory declaration with them. The relevant wording of the declaration says: "That I agree to take full personal responsibility for any information or data which is sent from my station, or from a station operating under my callsign. "That I will not hold the Launceston Institute of TAFE responsible for the content of data received through the LITGATE, whether such data is of an offensive, improper, illegal or other unacceptable nature." Basically, what the Launceston TAFE requires is that radio amateurs wanting access to LITGATE must say they will accept responsibility for all messages under their callsign, whether pirated or not, and agree they will absolve the Launceston TAFE from responsibility for any material placed on its system. Whether such a statutory declaration is legally binding would be a matter of conjecture. (Thanks to Victorian Division President, Jim Linton VK3PC, for details on that item). [end] I hope somebody can convince these people of the stupidity of their decision, as they clearly don't understand some of the technical issues. For those not involved in Amateur Radio, we "hams" operate our own computer network, using our radios as the physical layer. In some places, known as "wormholes" or "gateways", operators transport message over long distances via Internet, replacing the slower chain of short-range VHF or UHF radio links. The traffic leaves the net again at some remote point and rejoins the Amateur packet radio network. It's important to realise that the wormholes and Internet are merely being used as a medium for conveying this traffic from one part of the Amateur packet network to another; the Amateur traffic is effectively "quarantined" from other Internet traffic because Amateur Radio licence conditions forbid non-Amateurs (e.g. other Internet users) from conveying message by Amateur Radio. So, it would be very hard to argue that LIT is a "publisher" of any Amateur packet radio traffic passing through its gateway. I might add that it is a trivial matter to "pirate" another Radio Amateur's callsign. -Richard Murnane (Amateur station VK2SKY) ------------------------------ Date: Fri, 16 Jun 1995 21:00:42 GMT From: jthill@netcom.com (Jim Hill) Subject: Re: not caring about Prodigy (Morrell, RISKS-17.18) >hatred against Prodigy, which appears to be practicing the most control of >any provider (though still nothing like a newspaper) has people cheering ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think the risk is overstated, because (and only because) the underscored assertion is contradicted by Prodigy's own words: > "We make no apology for pursuing a value > system that reflects the culture of the > millions of American families we aspire to > serve. Certainly no responsible newspaper ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > does less when it carries the type of ^^^^^^^^^ > advertising it published, the letters it > prints, the degree of nudity and unsupported > gossip its editors tolerate." >(Exhibit J.) If Prodigy chooses to back off on their editorial control to, say (and the decision does say), Compuserve's or AOL's level, they won't be liable for the content they carry. Until then, they're providing a specific and valuable -- no irony intended, for any who might think newspapers aren't valuable -- service, and can be held responsible to the standards of that service. Jim Hill jthill@netcom.com ------------------------------ Date: Fri, 16 Jun 1995 16:06:34 -0400 (EDT) From: Bob Morrell Subject: Re: not caring about Prodigy I see your point, and hope you are right that the ruling will not have the broad effect I fear (though I have already heard it cited in exactly the manner I have described in a NPR report on another cyber-case) However, it is worth noting that your exhibit does not prove that Prodigy wanted to be a newspaper. It merely shows that Prodigy cited as an example of controlling content, newspapers. They could have cited restaurants that control dress codes, that would not have made them a restaurant. To say, when one is tired, that even horses get tired if you work them too long, does not make one a horse. To say that you have some rights, similar to one entity does not make you that entitity. This is the kind of square pegs in round hole legal thinking that I think harms the emerging character of the net. Bob Morrell bmorrell@isnet.is.wfu.edu ------------------------------ Date: Fri, 16 Jun 1995 13:42:57 -0800 From: jthill@netcom.com (Jim Hill) To: Bob Morrell Subject: Re: not caring about Prodigy "Certainly no responsible newspaper does less" in terms of controlling content -- "the letters it prints" -- says to me that they are *at least* as responsible as any newspaper. It's not just an example, it's an explicitly stated minimum standard. One doesn't have to be a prodigy (sorry ;-) to infer liability. I do agree with you that "rabid" is on target for too much of the anti-Prodigy froth. I will also say I was wrong to suggest earlier that moderated groups and lists should be held to that standard. Only the ones that claim it for themselves. Jim Hill jthill@netcom.com ------------------------------ Date: 24 March 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. Issue J of volume 17 is in that directory: "get risks-17.J". For issues