Subject: RISKS DIGEST 17.11 REPLY-TO: risks@csl.sri.com 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 ************************