CANON CITY--They said it about Alcatraz, and they're saying it about Colorado State Penitentiary. (Excerpted from The Denver Post, Saturday, July 31, 1993, pp. 1A, 7A) Nobody'll ever bust outta this place. "Can't happen," said George Sullivan, deputy director for operations of the Colorado Department of Corrections. "If there is such a thing as an escape-proof prison, this is as close as you'll get." From the outside, the new $44.9 million maximum-security penitentiary--which was dedicated on Thursday--actually appears less secure than some of the other prisons in the state system, such as Limon Correctional Facility. There's no guard tower, for one thing. And there's no perimeter fence yet. But even when a 12-foot cyclone fence is completed in September, it will be designed to keep outsiders away from the building, not insiders from running away. The building is so secure, Sullivan said, that type of precaution isn't necessary. [...] Locks, lights and video cameras throughout the prison can be turned on and off at the touch of a computer screen in a bullet-proof central control room. Two doors separate each of four living units, or "security envelopes," one door controlled by a correctional officer inside the unit and the other controlled by an officer in the control room. Lance Gatrell email@example.com
The RISK of trusting in software to save confidentiality has recently been exposed in a German newsgroup. On a debate whether DES is illegal in Germany (it is not, by the way) someone posted a tarred, compressed, uuencoded archive of DES code via an anonymizing service. (No discussion on the topic of anonymization, please.) Not only that he forgot to delete the object code before tarring (thus giving an indication which kind of hardware he uses). The next day someone else posted an explanation why this action was stupid, giving the anonymous poster's full real name and address. He found it out because the tar he used leaves user names (not only UIDs, which would suffice to restore file permission settings) in the tar file. Of course, this fact is not mentioned explicitly in the man page rsp. info file (but the average user wouldn't expect it in the first place...) where an explicit warning could be considered appropriate. Olaf Titz - firstname.lastname@example.org - email@example.com
>From today's (August 4, 1993) Wall Street Journal, pg. B1: "Merck to Eploit Medco's Database" The article goes on to explain that Merck, the world's largest pharmaceutical manufacturer, recently purchased Medco, a chain of discount pharmacies to gain access to the Medco database of pharmacy purchases. Merck plans to use this information in a variety of ways to promote Merck products. Examples in the article include: - a patient is taking a more expensive drug from a competitor so Merck would suggest a competitive Merck product to the physician - based on his other medications a patient is likely to have a condition that could be treated pharmacologically by a Merck product so suggest it to the physician The use of pharmacy purchase records as a de facto window into a patient's medical record, and the commercial exploitation of that information is a very unfortunate development. The examples noted above seem benign enough, and the article states that Merck does not plan to actually identify patient names when they contact physcians, but this opens the door to commercial exploitation of medical records data. Many other uses of this data are very worrisome. A tremendous amount of information can be inferred from pharmacy transactions. Both dosage and duration of therapy can be determined from the purchase data, and most people tend to stick with a small number of pharmacies. There are many thousands of drugs now on the market, and most of them carry very specific indications for use. For example, a young adult who purchases certain antibiotics is likely to be treating a case of the clap; a previously healthy parent who begins buying insulin is likely to have a child just diagnosed with diabetes; a single male in his 30's who starts buying AZT almost certainly has been diagnosed as HIV positive. How would you feel about Merck selling information about your recent case of VD to Trojan so they could start direct mail advertising to you? There is even some medical justification for doing so. How about if they sold it to Playboy/girl? Or the local televangelist looking for sinners to convert? Is there anything to stop Merck from selling a list of patients at high risk for expensive medical care to insurance companies (who probably have the information anyway) or to prospective employers? David States, M.D.
The SAAB JAS 39 "Gripen" crashed on Sunday, August 8, during an air display over central Stockholm. The following very preliminary account of the accident is based on commentaries and video recordings of the accident that I've seen on Swedish TV. Better information should be available in a few days. The aircraft was flying straight and level at low altitude and moderate speed. It began a gentle rocking motion in roll, then the nose pitched up rapidly, passing the vertical in a manouver resembling Pugachev's cobra. When the nose was well past the vertical - the pitch-up angle appeared to be about 120 degrees (!) - the pilot ejected and landed unhurt. After some further manouvres, the aircraft settled in a vertical descent in about level attitude. From what I could see, the aircraft did not break up in the air. The aircraft struck a small hill on an island (Laangholmen), exploding on impact. The crash site was only tens of metres from a major bridge (Vaesterbron) packed with spectators. Miraculously no one on the ground was killed. Three people got slight burns, one sprained his ankle while running away. The only damage on the ground was that a tree was struck down. JAS39 is a statically unstable aircraft controlled by computers (called "fly-by-wire", or FBW). The FBW system was immediately suspected to be the reason for the crash. Indeed, the behaviour of the aircraft is about what you would expect after a major failure of the FBW system. A person listening on the radio frequency used by the aircraft during the display claims that the immediately before he lost control, the pilot reported that a circuit breaker had tripped. This is in contrast with the previous JAS 39 crash where the FBW system was functioning correctly according to the control laws in force, but where these control laws were incorrect causing the aircraft to overreact to the pilot's control inputs when the aircraft was hit by a wind gust during landing. The aircraft that crashed was the first one to be delivered to the Swedish Air Force. It was flown by the same SAAB display pilot that flew the first accident aircraft! Lars-Henrik Eriksson, Swedish Institute of Computer Science, Box 1263, S-164 28 KISTA, SWEDEN firstname.lastname@example.org +46 8 752 15 09 [Also noted by Martin Minow <email@example.com> and Jacob Palme DSV <jpalme@DSV.SU.se>. PGN]
The August 1993 Airline Pilot (p. 19) warns pilots to watch the flap/slat handle on MD-11's. This was in reference to the much-publicised incident involving a China Eastern Airlines MD-11 on April 6, which experienced uncommanded slat extension and a series of violent oscillations. The plane lost 5000', and spooked the crew enough that they made a diversion to an air base in Alaska to inspect the airplane. Subsequent commentary in RISKS and elsewhere speculated that the digital cockpit in the airplane might have been responsible for the deployment. Comments on sci.aeronautics.airliners tended to indicate that this aspect of the flight control system was conventional in nature, however. The article notes: "NTSB cautioned, in its safety recommendation issued June 29, that 'The cause of the slat deployment has not been determined However, preliminary evidence strongly suggests that the flap/slat handle became dislodged from the slat-retract position... because of inadvertent contact with the handle by a flightcrew member.' "At least 10 other cases of inadvertent or uncommanded inflight slat deployments have occurred on MD-11's since April 1991 (!!!). NTSB said Douglas Aircraft Company has advised operators of those incidents, "is aware of the continuing nature of the problem, and is... working with FAA and MD-11 operators to redesign the [MD-11] flap/slat actuating system." [ Snide personal note: cargo doors, anyone? ] The article notes that the NTSB urges: 1. That the FAA establish an interim measure to prevent inadvertent slat extension. 2. MD-11 operators to inform crews of the danger. 3. That the revamped system be installed ASAP. "The Safety Board said the incidents continued to occur 'despite several attempted fixes' by Douglas. The China Eastern Airlines airplane had been modified to meet all Douglas service bulletins and applicable slat system [airworthiness directives]. "The day after the first incident, [Douglas told operators about the problem] "[...] 'Sharply striking the aft side of the handle [it is normally at the furthest-forward position when flaps are retracted] will allow the handle to move upward if a very light vertical force is applied,' Douglas said. 'Normal spring and cable tensions will move the handle aft once disengaged from the FLAP UP/SLAT RET detent and allow the slats to extend.' "In August 1992, Douglas designed a protective cover for the zero-degree detent gate. FAA later mandated that air carriers use the cover." "[...] Douglas will replace the current flap/slat handle and its cable system with an electrically operated system designed to eliminate the cable tension forces that bias the slat system to the extend position. [...] The electrically operated flap/slat handle system should be available in mid- 1994; the interim system, within several months. "Meanwhile, don't bump that flap/slat handle." [And stay away from DC-10's and MD-11's, as a guiding philosophy in life :-). --rdd] Robert Dorsett firstname.lastname@example.org ...cs.utexas.edu!cactus.org!rdd
>uncommanded [or, rather, inadvertent] slat extension [causes a] series of >violent oscillations. The [MD11] lost 5000', and spooked the crew enough that >they made a diversion to an air base in Alaska to inspect the airplane. It was not just crew spook. Two passengers were killed, and all passengers were injured, some severely. >Subsequent commentary in RISKS and elsewhere speculated that the digital >cockpit in the airplane might have been responsible for the deployment. I sent a query to ata-watchers asking if anyone knew if digital systems were involved. Mary Shaw responded that the report will eventually cross her desk. I don't recall seeing anything in RISKS. I found the MD-11 that I flew on (Swissair) a year ago very comfortable, but .. > [And stay away from DC-10's and MD-11's, as a guiding philosophy in life :-) why the smiley face? :-) Peter.
An article in the Chicago Tribune (8/2/93, sec. 2, p. 7, by Terry Wilson) will make you want to check your next phone bill more carefully. A summary follows. A Chicago man named Jeff Baird was concerned because his phone had been acting funny for days, ringing once and then stopping. One day last month he was able to answer it in the middle of a ring, and he heard a recorded message saying that the call was collect from an inmate named Bill in the Illinois Department of Corrections [IDOC--the state prison system] and that the call was being recorded and monitored. The recorded voice told him he could say "yes" and accept the charges or hang up. Although Baird was curious about how Bill, whom he did not know, had gotten his phone number, he did not accept the charges. The odd rings continued. Eventually the Bairds discovered that an IDOC inmate had ordered call forwarding for their telephone along with a remote access code, a new feature offered by Illinois Bell. With the remote access feature, you don't have to be home to change the number your calls will be forwarded to. Just dial your home number and type in the code, followed by the number you want your calls to be forwarded to! The inmate had apparently been given the three-digit code over the phone by an Illinois Bell employee. When the inmate wanted to make a call, he simply started forwarding the Bairds' calls to the number he wanted to call. Then he dialed the Bairds' number. The person to whom the call was forwarded would hear the recorded message and accept the call. The call was billed to the Bairds because it was their number which was originally dialed. More than $200 worth of collect calls were made in a week, by several inmates. In spite of the fact that all the calls were supposedly recorded, IDOC officials claim they cannot identify any of the inmates. Presumably the inmate un-forwarded the phone when he was through or the Bairds would not have received any calls at all. Once, however, Jane Baird called home and found herself talking to a complete stranger who declined to identify herself or explain why she was answering the Bairds' telephone. Illinois Bell eventually discovered that the Bairds had not ordered call forwarding. The Bairds will not have to pay for the calls. Illinois Bell has decided to mail out the code number to the address where the phone is located. Well, folks, it looks like the phone company has come up with something more aggravating than call waiting. Seriously, though, call forwarding was originally designed *without* remote forwarding to avoid precisely this problem. Reva Freedman <email@example.com> Dept. of EECS, Northwestern University, Evanston, IL
This may be the first "Novel on the Net" (though the Gutenberg project may have some comments on that), but it is not the first book published as Shareware or commercially published through computer networks. "Computer Shock", an anthology of pieces about how computers and technology affect our lives and work, was published in 1987. Quite a few well-known writers were in it (Jacques Vallee, Robert Johansen, Barbara Garson, about 10 others.) The book was edited by Roger Bullis, professor at University of Wisconsin. The thing came in a ZIP (or rather ARC) file with the text files in a COM format (when you executed the program, the text was shown on the screen). A couple of the chapters were about privacy, by the way, as well as the nature of computerized communication. My involvement in this was when I worked for the computer center at a business school in Norway, and we made a chapter of this book a part of the curriculum in the introductory computer course. Transferred the thing to Mac under Hypercard and also to an IBM VM/CMS mainframe with a small reading program in REXX. We explained the concept of ShareWare to the students, and suggested some amount of payment (I don't remember how much, but we cleared with the editor up front). Sad to say, not much money came out of it, but I still owe Roger a beer if he ever makes it to Norway..... Espen Andersen (hbs.harvard.edu)
A recent posting to RISKS points out the undesirability of rebooting all the computers via cutting all power on the island in "Jurassic Park". Such power resets are a time-honored SF movie technique for trying to solve problems. For example, in "Westworld" (1973), not only was cutting the power unsuccessful in stopping rampaging robots ("They're running on stored charge out there!"), it also, when power couldn't be restored, locked the control staff in a hermetically sealed room with doors which could only be opened electrically. No overrides, so everyone suffocates. Conceptually similar technical silliness can be observed in "The Andromeda Strain (1971)", "The Terminal Man" (1974), and "Looker" (1981). In all these cases, elementary technical points, unlikely to be overlooked in the real world, are used as major plot development elements. By now, many of you have already discerned the pattern in the above. All of the films listed were written by Michael Crichton, and in somes cases directed by him. Michael is the king of what I call "pop-pseudo-technology" writing--which generally revels in making as many technical folks as possible look like complete idiots and incapable of even the most obvious observations. Given his recent contractual expansions in the wake of "Jurassic Park", there will be a lot more of the same attitudes coming down the line soon. --Lauren--
I wouldn't be too concerned about the *modem* being exposed--at least not from a data integrity standpoint (whether or not the modem will last long before being removed by sticky fingers is another matter). Virtually all modern ATM terminals use data encryption (typically DES-based) for end-to-end communications. The encryption is done within the terminal, so all of the data that reaches the modem, from either side, should already be "secured." --Lauren--
1994 IEEE Symposium on May 16--18, 1994 Research in Security and Privacy Oakland, California Sponsored by IEEE Computer Society Technical Committee on Security and Privacy in cooperation with The International Association for Cryptologic Research (IACR) The Symposium on Security and Privacy is the premier forum for the presentation of developments in computer security, and for bringing together researchers and practitioners in the field. The focus of this, the 15th symposium in the series, will include technical aspects of security and privacy as they arise in commercial and industrial applications, as well in government and military systems. The symposium will address advances in the theory, design, implementation, analysis, and application of secure computer systems, and in the integration and reconciliation of security and privacy with other critical system properties such as reliability and safety. Topics in which papers and panel session proposals are invited include, but are not limited to, the following: Secure systems Privacy Issues Access controls Security verification Network security Policy modeling Information flow Authentication Database security Data integrity Protocols Viruses and worms Auditing and intrusion detection Commercial and industrial security Security and other critical system properties Distributed systems INSTRUCTIONS TO AUTHORS: Send six copies of your paper and/or proposal for a panel session to John Rushby, Program Co-Chair, at the address given below. Papers and panel proposals must be received by November 15, 1993. Papers, which should include an abstract, must not exceed 7500 words. The names and affiliations of the authors should appear on a separate cover page only, as a ``blind'' refereeing process is used. Authors must certify prior to December 31, 1993 that any and all necessary clearances for publication have been obtained. Papers must report original work that has not been published previously, and is not under consideration for publication elsewhere. Abstracts, overlength papers, electronic submissions, late submissions, and papers that cannot be published in the proceedings will be rejected without review. Authors will be notified of acceptance by February 1, 1994. Camera-ready copies are due not later than March 15, 1994. Panel proposals should describe, in two pages or less, the objective of the panel and the topic(s) to be addressed. Names and addresses of potential panelists (with position abstracts if possible) and of the moderator should also be included. The Symposium will also include informal poster sessions where preliminary or speculative material, and descriptions or demonstrations of software, may be presented. Send one copy of your poster session paper to Cristi Garvey, at the address given below, by January 31, 1994, together with certification that any and all necessary clearances for presentation have been obtained. PROGRAM COMMITTEE Ross Anderson, Cambridge University, UK Tom Berson, Anagram Laboratories, USA Leslie Chalmers, Bank of California, USA Oliver Costich, CSIS, George Mason University, USA Frederic Cuppens, ONERA/CERT, France James Gray, University of Science & Technology, Hong Kong Sushil Jajodia, George Mason University, USA Dale Johnson, MITRE Corporation, USA Steve Kent, BBN, USA Sue Landauer, Trusted Information Systems, USA Teresa Lunt, SRI International, USA John McHugh, Portland State University, USA Doug McIlroy, AT&T Bell Labs, USA John McLean, Naval Research Laboratory, USA Jon Millen, MITRE Corporation, USA Sylvan Pinsky, National Security Agency, USA Michael Reiter, AT&T Bell Labs, USA Karen Sollins, MIT Laboratory for Computer Science, USA Stuart Stubblebine, University of Southern California, USA Gene Tsudik, IBM Research Laboratory, Switzerland Yacov Yacobi, Bellcore, USA Raphael Yahalom, Hebrew University, Israel For further information concerning the symposium, contact: Cristi Garvey, General Chair John Rushby, Program Co-Chair TRW, MS R2-2044 SRI International, EL254 One Space Park 333 Ravenswood Avenue Redondo Beach, CA 90278, USA Menlo Park, CA 94025, USA Tel: +1 (310) 812-0566 Tel: +1 (415) 859-5456 FAX: +1 (310) 812-4310 FAX: +1 (415) 859-2844 Garvey@zoo.sdd.trw.com firstname.lastname@example.org Carl Landwehr, Vice Chair Catherine Meadows, Program Co-Chair Naval Research Lab., Code 5542 Naval Research Laboratory, Code 5543 4555 Overlook Ave., SW 4555 Overlook Ave., SW Washington DC 20375, USA Washington DC 20375, USA Tel: +1 (202) 404-8888 Tel: +1 (202) 767-3490 FAX: +1 (202) 404-7942 FAX: +1 (202) 404-7942 email@example.com firstname.lastname@example.org Frederic Cuppens, European Contact James Gray III, Asia/Pacific Contact ONERA/CERT Department of Computer Science 2 Avenue E. Belin Hong Kong Univ. of Science & Technology 31400 Toulouse, France Clear Water Bay, Kowloon, Hong Kong Tel: +33 61 55 70 75 +852 358-7012 FAX: +33 61 55 71 32 +852 358-1477 email@example.com firstname.lastname@example.org ---snip here----------------------------------------------------- Obtaining the Call For Papers for the 1994 IEEE Symposium on Security and Privacy by anonymous ftp The CFP is available from ftp.csl.sri.com--note the ftp on the front--(126.96.36.199) in directory /pub in the following forms Plain Ascii text: sec-priv94.txt Single-page for US-size (8.5x11) paper LaTeX source: sec-priv94.tex LaTeX output: sec-priv94.dvi (needs binary transfer) Postscript: sec-priv94.ps Single-page for A4-size paper LaTeX source: sec-priv94-a4.tex LaTeX output: sec-priv94-a4.dvi (needs binary transfer) Postscript: sec-priv94-a4.ps Two pages, big font, suitable for faxing LaTeX source: sec-priv94-big.tex LaTeX output: sec-priv94-big.dvi (needs binary transfer) Postscript: sec-priv94-big.ps Send questions or problems to John Rushby (email@example.com).
Please report problems with the web pages to the maintainer