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]
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" <PMW1@PSUVM.PSU.EDU>
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]
[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
© 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.
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 // firstname.lastname@example.org // email@example.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.
Tenth Annual Conference On Computer Assurance
Systems Integrity, Software Safety, and Process Security
June 26-30, 1995
National Institute of Standards and Technology
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"You can get the program and other details as follows.
"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"
[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]
Abstract deadline: 15 May 95
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]
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
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 firstname.lastname@example.org Compuserve 100315,3453
> 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]
[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
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 (email@example.com)
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
[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
>... 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.
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 firstname.lastname@example.org email@example.com
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. /RSRichard Soderberg, MD, The Karolinska Institute, Libr. and Med. Info. Center, Doktorsringen 21 C, S-104 01 Stockholm SWEDEN +46 8 728 80 00
Please report problems with the web pages to the maintainer