Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
My wife just purchased one of the new Oki programmable cellular telephones with a built in beeper. When it didn't beep for a day or so, we tried to originate a call and found it had not been activated by the vendor. No problem, he said, "Just bring it in and I'll change its number to the one I entered by accident." Turns out, he had accidentally transcribed a number so the incorrect number was activated. My wife objected to the trip - so the man nicely explained how to reprogram the internal memory and change the number of the telephone! The risk is obvious: tired of paying those high telephone bills and don't know where to buy one of the chips described earlier in RISKS that change your telephone number? Just buy an Oki and reprogram it to any number (within limits) you choose and off you go. Or, examine your bills very carefully. Stu Bell (713) 333-0906
Game Over For Nintendo Lottery
MINNEAPOLIS (AP) [18Oct91]
A controversial plan to introduce the state lottery into homes with the
popular Nintendo video games was dropped amid complaints it would harm children
and encourage compulsive gambling. State Lottery Director George Andersen said
more discussion of the play-at-home system the first such plan unveiled in the
nation is warranted in light of lawmakers' complaints. "I still think it's a
good idea," he said. "But we never want to operate without as broad a consensus
as we can." [...]
On October 19 I was on TWA Flight 843 from JFK to SFO which was delayed 2 1/2 hours while repair crews located and repaired a wiring harness in the intercom system used for communications through the aircraft. The intercom is essential for safe operations because it is used for communications in case of any emergency in-flight (for example, on another flight a Pan Am pilot told me of the time a flight attendant informed him that a wing-tip fuel tank was losing fuel, something he could not see from the cockpit). What I found interesting about the intercom system is that it is wired like christmas tree lights where any failure in the chain causes a complete failure and requires a check of each component. If this is truly an essential system, I would expect more redundancy--I can imagine many emergencies that would disable this system. The intercom wiring harness in the TWA L-1011 simply wore out (each time the flight attentant sits down, the harness is bent), a consequence of flying planes for so many years. What will happen to modern fly-by-wire aircraft after they have been in the air for 30 years?
Minneapolis will be introducing "Easy Reader", a computerized water meter
reading system, over the next five years. You get a new meter and an interface
unit plugged into your phone line. Once a month, a reading will be taken
automatically, and sent to a central billing computer. This will happen
between midnight and 7am. Presumably the unit in your house places the call;
they say "Your telephone will not ring".
They have anticipated several objections people might have to the service.
They promise your phone service will not be interrupted: "If you do happen to
be on the phone ... Easy Reader will get a busy signal [sic] and try again
later. If you pick up the phone while the meter is being read, [it] will
instantly disconnect."
They also reassure you that nobody will use this equipment to listen in to your
phone conversations, and perhaps most curiously, reassure people with unlisted
numbers that "Telephone numbers need only be disclosed during the installation
of the system. After the initial contact with your home phone has been made,
your number is no longer needed. The Water Works will gladly respect your
privacy by not recordeing your number anywhere in its files." Why would they
even need the number temporarily to set up service?
They don't promise that the system won't accidentally dial 911 in the middle of
the night :-)
John Sullivan, Univ. of Minnesota, sullivan@geom.umn.edu
A portable CD player I was experimenting with, features a safety switch, located on the hatch door, which turns the unit off once the door is opened. The role of that switch is to ensure that the laser in the unit will not operate with the door open. A number of other appliances (microwave ovens come to mind) have similar safety switches. One day I decided to deeply discharge the batteries of the unit (i.e., drain the them as much as possible) as a precaution against the NicCad "memory effect." The unit has an auto-power-off feature whereby when the batterie voltage falls bellow a certain level it switches itself off. Every time the unit switched itself off, I pressed "play" again to switch it on. The objective of this procedure was to drain the batteries as much as possible. After some time the unit crashed. The display had some strange segments lit and the auto-power-off feature was no longer functioning. My first conclusion was that the auto-power-off was software controlled. My next move was to check what other things were software controlled. I plugged mains power to the unit so that I would not loose this crashed state and tried opening the hatch door. As I was expecting the safety switch was also, apperently, software controled because the unit remained on. Now, I was faced with a unit turned on, with full power applied to it and with an open door hatch. Moral: Software emulation of safety interlocks is not a good idea. Even with formaly proven correct software, we would still need hardware that was formaly proven to correctly function under all probable conditions to implement a safe product. Direct control methods (such as a switch connected to the power supply in this case) are more appropriate. Diomidis Spinellis, Department of Computing, Imperial College
There seems to be a false assumption in some of the comments made by those who fear this concept. They assume that the body that issues the licenses is the government. That is not the case for other engineers. In many jurisdictions there is a professional body that is charged with this task. In Ontario it is the APEO, Association of Professional Engineers of Ontario. In Australia there is an "Institution of Engineers". Thus, it becomes the job of professionals to set the standards for their own profession and to enforce them. Why should the software field be different?
In RISKS-12.52 Richard Hanlon suggests:
> ..with a minimal intrusion by the government, [by] making it a law to
> provide free bug fixes (there's ALWAYS at least one more bug).
Such a law might have horrible consequences for software vendors.
Fred Brooks in _The Mythical Man Month_ (Addison-Wesley, Menlo Park, 1982)
reports (in Ch. 11, adducing evidence which I've elided here) that:
The fundamental problem with program maintenance is that fixing a defect
has a substantial (20-50 percent) change of introducing another. So the
whole process is two steps forward and one step back.
and
...All repairs tend to destroy the structure [of the software], to increase
the entropy and disorder of the system. Less and less effort is spent on
fixing original design flaws; more and more is spent on fixing flaws
introduced by earlier fixes. As time passes, the system becomes less and
less well-ordered. Sooner or later the fixing ceases to gain any ground.
Each forward step is matched by a backward one. Although in principle
usable forever, the system has worn out as a base for progress. [...]
Systems program building is an entropy-decreasing process, hence inherently
metastable. Program maintenance is an entropy-increasing process, and even
its most skillfull execution only delays the subsidence of the system into
unfixable obsolescence.
So I suggest that any law interfering with the allocation of resources to
maintenance or development (often of a replacement system) by the presumably
expert management of a software vendor would be unwise and ultimately
destructive. Customers exercising a legal privilege to demand that bugs in a
senescent system be fixed could force a software vendor right into the Pit of
Despair.
Mark Seecof <marks@latimes.com>
> I've listed the relevant allegations - I guess Amos Shapir or > somebody will probably send you the full article. Well, the full article is too long to post (and nothing new to most RISKS readers). I agree with most of Simon's conclusions, but there are some inaccuracies in his quotes. I understand his indignation at having *his* system exposed in public, but he'd rather leave the posting to the guy who had actually read the article. > Four years ago, he broke into her account - he claims > that by chance, her password happened to be the same at the time of the > demonstration. I have no evidence to contradict this,although it seems more > likely that he guessed her current password using the information he had from > the old one. Actually, she was asked about it and is quoted in the article as admitting to reusing the same old password. > Claim #2: He stated that the account name had a prefix which indicated that > the account was special, and that this showed how naive the system > managers were. (This is not a correction, it just reminds me of something that happened here). On CDC's NOS system, privileged accounts are the ones which begin with a C. You can guess what happened when a somewhat ignorant administrator assigned the Computer Science department accounts which begin with CS... > Claim #6: He claimed he could destroy all the back-ups. > Lie: Maybe if he stuck magnets on a few SCUD-C's and lobbed them at the > various tape archives. It's a lot harder to spoof a human being, > especially when you're a 24 year old male, and the spoofee is a 50ish > woman. Not exactly. What the cracker claimed was that he could use the administrator's account to ask operators to mount the backup tapes, then destroy them; the operators could have no way of knowing that the request wasn't legitimate. The spokesman's response in the article is along the line "if we'd get such a request we'd probably call back and ask what it's for". Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel. +972 2 585706
I am a frequent user of ATM's. As banks in The Netherlands are closed after
17:00 and in the weekends, the only way you are going to get cash after that
time is through an ATM. Unfortunately not all off them are the same, and some
display a most peculiar behaviour. Example:
ATM: INsert card
Me: I insert my card
ATM: key in your PIN code.
Me: I do so.
ATM: There are no receipts available currently. Choose the amount of cash you
wish to withdraw.
Me: I choose 100 Guilders
ATM: There are no receipts available currently. Do you want a receipt?
Me: I press the "No" key.
ATM: We're sorry, there are no receipts available currently.
ATM: Please wait.....
ATM: Retrieve cash from ATM please. There are no receipts available currently.
Me: I KNOW THERE ARE NO RECEIPTS!!! Please quit whinig and give me my money.
[withdrawal hatch opens, and my money is there, so I take it]
ATM: Please take your card out.
Me: I take my card out.
ATM: Please wait for your receipt. There are no receipts available currently.
RISKS? Well, none really, but quite frustrating..... Another example is funny
stuff is the banks apparently can edit the on-screen messages on the fly, for
once I was making a withdrawal, and the screen is flashing a bank advertisement
on the bottom two lines. Something like: "Open a new account now, and receive
this great CD with the greatest hits of 1991, PLUS a whopping 5.4% interest"
When suddenly, the cursor moved to that line, and lo and behold, they edited
the interest rate. The ATM continued my trans- action perfectly, but is was
pretty weird to see the line edited *on-screen*.
For a last weird stuff thing, I once arrived at an ATM, that looked in pretty
bad shape. Someone had apparently drank too much and decided to unload his
lunch over the keyboard. I took one look and decided to, well, not make the
planned transaction. At that point a van stopped and some service guy gets
out. So I wait and see. The guy goes through a door next to the ATM, does
something to the inside, comes out, and lifts the complete front off. Puts it
into his van, and replaces it with a new one. I asked why, and he said well,
would you like to have to poke in someone others puke. I said, but you don't
need to replace the whole *front* for that, you could just clean it! The
answer was a vague story about disinfecting the thing, and AIDS (!!) and that
he didn't fancy having to clean it.
--Ralph Moonen rmoonen@hvlpa.att.com
> Why is it that inaccurately negative credit reporting [doesn't | shouldn't]
> constitute libel under the law?
"DOESN'T":
It's (US federal) law. As I understand it (admittedly, I'm no lawyer), the
credit reporting agencies are protected unless they maliciously report the
information. If they make a mistake, that's not actionable. (The explanation
given to me also included the statement, "Well, they have so many records, you
can't expect them to have everything right, so as long as their errors aren't
deliberate, they shouldn't have to pay." Unfortunately, I don't remember WHO
gave me that explanation but I'd be interested in knowing if that is in fact
the reason behind the law shielding the agencies.)
Matt
I read recently in RISKS the serious question by a Johnson Space Center employee on the risks of rehosting a large realtime program currently on minicomputers manufactured by my company. It was some amusement that two contributers offered parochial suggestions that their favorite hardware was clearly the "right" choice for such a large problem. This misses (and yet reinforces) the point the original contributor made that cost of the rehost to IBM/workstations would be larger than understood by management. The reinforcement of the original idea is that the two followup contributors answered a software complexity unknown by asserting "it will be easy using
Avis vs. Spaf
Gene Spafford <spaf@cs.purdue.edu> Fri, 18 Oct 91 21:41:37 ESTYesterday, I flew into Chicago O'Hare airport from Vienna, Austria. I wasn't too awfully jet-lagged, and rather than wait 8 hours for the next flight to West Lafayette, I decided to cash in my ticket and rent a car one-way. (West Lafayette is a 2.5 hour drive from O'Hare.) I got to the car no problem. The agent at the counter said it was in stall J-32, and that is where the bus dropped me. So, the keys were in the ignition and the driver's side door was unlocked. I threw my coat in and tried to open the back door to toss in my portable PC. It was locked. So, I hit the powerlock button on the driver's side door to unlock all the doors, and then went to get my PC. A gust of wind blew the driver's side door shut. I then discovered I had LOCKED all the doors by pushing the button the wrong way! (This was a Chevy Lumina.) On my old 1975 car, one must hold the handle out when closing it, or lock it with the key after closing — a form of fail-safe behavior compared to this. To make matters worse, the car was to be rented one-way, so they had given me a car originally from Maryland...with no duplicate keys to be had locally. It took 2 of their mechanics working together for about 30 minutes to break into the car without excessive damage. If my coat hadn't been in the car, they would have just rented me a different one. Sigh. But wait, it gets better! On the way our of the lot, the guard checked my rental agreement against the sticker on the car. The numbers didn't match! I had to go back because I had the wrong car for the agreement, and he couldn't let it out of the lot. The woman at the counter sort of rolled her eyes when I came back in for the third time, but she forced a smile and said that rather than switch the car, she would just adjust the contract to show the car I had. Some quick keypresses, a new contract agreement off the printer, and I was on my way. This morning, I drove the car out to the airport here to return it and pick up my car in the parking lot. As I was transfering my briefcase & books from rental car to personal car, the wind must have blown the rental agreement off the car seat and into the surrounding fields. I couldn't find it anywhere. Sigh. Trudge into the airport. Give the person at the counter the keys and mumble "I seem to have lost my agreement somewhere." No problem — she'll just take the ID off the keys, enter the final mileage, and print a duplicate agreement. The benefit of having one of those marvelous computer networks, eh? So, she puts in the mileage and vehicle number, confirms that my rate was $89 with the corporate discount, and prints the receipt. As she hands it to me, she smiles and says "Have a nice day Mr. Anderson" (I don't remember the exact name). This takes me a bit aback, and I ask "Anderson?" fearing the worst. I look at the rental agreement. The name, home address, and so forth are not mine. The agreement shows that the car was rented at Dulles Airport and was not to be returned until tomorrow — back to Dulles. It had someone else's credit card number. It was the correct car, but the wrong renter. After struggling with the computer for about 20 minutes, the clerk then called Chicago and spoke to 9 different people (we counted) in 30 minutes before getting someone who could help find my rental record. It seems Avis's system does not allow (for privacy reasons?) any field agent to do a lookup based on name, based on credit card number, based on rental location, or based on anything else I had with me or could produce. It needed either the rental agreement number, which was lost, or the vehicle ID, which was incorrect. The folks in Chicago had to find the duplicate PAPER copy of the rental record in their files to get the correct number. Once my agreement was finally corrected, they had to fix the record for "Mr. Anderson" because he hasn't returned his car. However, they can't cancel a transaction in the system, I guess because it might allow employee fraud ("Mr. Spafford, our records do NOT show a checkin — either produce the car or we swear out a warrant."). Instead, they have to issue a special form of checkout that negates the effect of the checkin. Unfortunately, the computer now showed that the vehicle was checked in, because the local office had file a record to indicate they had the car. The system won't allow a car marked as present at a local office to also be marked as "rented." Between Chicago and locally, they decided to take the car "out of service" somehow, thus removing it from the ken of the system. They then did a correction checkout on Mr. Anderson. He's in for a surprise, probably, when he tries to check HIS car in tomorrow. I hope he doesn't have a flight to catch. Then again, maybe he'll do an express checkin where he simply throws the keys and the agreement envelope into a mailslot, and add even more entropy into the mix. This whole mess took almost 45 minutes to get straightened out. I bet their records are still messed up, with the car I had now marked out of service and some other car lost in the system. I wonder if they will ever get it evened out. As for me, no more rentals on windy days!
Re: Have you tested your machine lately?
<boyd@prl.dec.com> Thu, 17 Oct 91 13:14:35 +0100Two weeks ago we had a power outage which damaged various bits of hardware in some of our DECstation 5000's. I had been out of the lab for 8-10 days and I wasn't around when the outage occurred. So I wasn't really sure of the state of the world, but it didn't sound good. I log in on my 5000 (it has two big colour screens and runs X) and immediately I see some _very strange_ things happening. 1. `sunclock' paints a white icon and then exits. `sunclock' shows a map of the world with the land illuminated by the sun in white, and the dark areas in black. 2. `xman's buttons are missing the semi-circular edges on the left hand side of the buttons. `xman' is the X implementation of `man'. 3. Clicking on some of `xrn's buttons crashes my X server. `xrn' is an X based newsreader. 4. Most everthing else works. At this stage I conclude that something is seriously wrong. But just where is the problem? Is it the X clients, the server, a font problem, the display or a real machine problem? I just don't know, so I have to go looking. So I start with `sunclock' because I believe that it is probably a simple system and a sound test case. I was right, but I dismissed my conclusion because I don't trust the debugger I was using (`ups'). `ups' was telling me that the math library was returning NaN and `sunclock' would use this bogus value, compute with it, and then index off the end of an array — and dump core. I wasn't trusting `ups' because it likes to second guess the compiler on ULTRIX 4.2. It _knows_ where the SP is. When it sees the SP is not where it should be it aborts. I commented the line out, and it works, but I don't place a great deal of trust in it, given my knowledge of the MIPS archictecure/compiler is not large. So where to next? Is it in the X server? We have quite a few field test X servers here, and maybe the new wiz bang version will fix this. After trying a few I conclude that this is not the case. Is it in the display hardware? So I board swap the display hardware and then reboot. This is what I should have done in the first place. The self test tells me the FPU failed its self test, and I conclude that it's returning garbage to the math library. All the software using floating point is broken — in mysterious ways. This consumed a day of my time. The thing that really worries me is that when confonted with a problem with these `modern' systems you just have too many variables of which you have to know _a lot_ about to diagnose the problem. I can't see this trend ending. In the future I can see that 5 or 6 people with diverse, non-intersecting knowledge will be required to analyse the simplist of problems. This is a disturbing conclusion. Boyd RobertsPlease report problems with the web pages to the maintainer
xTop