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…
The following appeared in the Thursday, Aug. 7, 1992, NJ Star Ledger.
"Bug" Backfires on Computer Consultant
NEW YORK (AP) — A computer consultant must pay $25,000 to a Manhattan
law firm whose computer system crashed because he put a "bug" in it.
Donald R. Lewis hoped the bug would cause the law firm of Werner,
Zaroff, Slotnick, Stern and Askenazy to call him for repair work after the
system collapsed, according to Civil Court Judge Richard F. Braun. Lewis was
hired in 1985 to upgrade the firm's computer system, which tracks medical
payments of auto accident victims to health care providers. The patients,
under the state's no-fault insurance law, assign their awards to the health
care professionals. Lewis initially estimated the upgrade would cost up to
$5,000, but the firm eventually paid him some $21,000.
In the months that followed, Lewis periodically called the firm's
receptionist to see if the computer file had entered claim number 56789. In
July 1986, six months after the firm made its last payment to Lewis, the
computer system shut down. It had filed claim number 56789, Braun
said. Lewis had put a "conditional statement" in the computer's software
which caused it to stop functioning at claim number 56789, the judge said. The
law firm paid another consultant $7,000 to fix the problem.
[Once again this brings up the concern of people thinking that anything that
happens in a computer system that wasn't expected by the end users is a bug.
I'd like a job where I got paid $7000 to remove a "conditional statement."
John Kriens jkriens@decoy.cc.bellcore.com]
From THE SEATTLE TIMES, Wed. Aug 5, 1992, p. D1: "Ship makes list - the hard way" by Penelope M. Carrington F. Garcia had just rounded the corner ... yesterday when he saw the 300-foot fish-processing ship list to its right and crash into the neighboring dry dock. ... the vessel, the Dona Karen Marie, had been leaning since early yesterday morning. First it listed to the left --- portside. Then an engineer came to fix the problem. Workers watched as the ... ship leveled and then listed to the right --- starboard --- into the United Marine Marketing dry dock. Shipyard spokeswoman Ruth Nelson said something malfunctioned in the computer that controls the water-ballast tanks of the boat when the engineer tried to correct the original listing. As a result, all the water in the left tank "was swooshed down to the other side," said Nelson, who was unsure why the boat listed in the first place. There were no injuries, and no danger of the ship tipping over into Lake Union because it rested against the firmly anchored dry dock. Tacoma Boat, which built the Dona Karen Marie, was contacted to secure copies of the original plans to the ships ballasting system. The Seattle Fire Department hoped to find the pipes that would pump the water back to the port side. ... The Dona Karen Marie has been moored in the shipyard for weeks. Nelson said she could not identify the vessel's owner. [ I pass the scene every day on my way to and from work. It is quite a sight --- imagine a four-story building tipped over onto its neighbor. The ship is tipped about 30 degrees away from vertical, resting against the wall of the adjacent drydock. I don't know if it would have capsized if it hadn't struck the drydock, but it looks like it might have. It is lucky no one was hurt. ] - Jon Jacky, jon@radonc.washington.edu, University of Washington, Seattle
I have a long, but unfortunately, confidential article about bugs reported to me in the microcode of microprocessors, including those used in `safety-critical' systems. I would like to collect further examples. Clearly, such bugs could undermine safety-critical systems. I have a list of such bugs, but unfortunately, many are confidential. I should like to collect further examples. If I get enough non-confidential examples, I will post them to comp.risks. Please send E-mail information to me and state whether your example should be kept confidential or not. Give full details, such as the microprocessor, date, and nature of bug. Thanks. Brian Wichmann, National Physical Laboratory (baw@seg.npl.co.uk)
Recently, a couple of entries attracted my attention: rex@iqsc.com (Rex Black) talked about "Unreliable call-return phone feature...", while CMHAM01@UKCC.uky.edu (Chuck Ham) mentioned problems associated with GTE's Personal Secretary (where a friend had troubles without even subscribing). I suspect that something like my small risk has been mentioned before, but who knows.... Last year, Bell Canada had a promotion in our area to flog (among other things) Call Waiting. It was mentioned in a glossy throwaway in our monthly bill that we were having Call Waiting installed on our lines (we have two) for a free trial period. Shortly after this, I was at home and my S.O. [significant other] was out curling. The arrangement was that she would call me when she finished, I'd pick her up, and we'd go scare up something to eat. While waiting, I dialled in to work and probably read news. After a while I got occasional bursts of line noise but ignored them - the local phone lines are sometimes noisy. The other phone never rang... The other half of the story is that there was an increasingly grumpy person at the curling club trying to find me: calling home (I wasn't there, because, of course, the phone was ringing and not being answered), work, friends' places, and the like. It took a long time before she thought of using the other phone number. The risk is small, but annoying: with the increasing use of phone lines for data, it is not necessarily the best decision to use a normal "ring" when a caller dials a busy line with call waiting on it. One should also read glossy throwaways more carefully. :-)
About a year ago, I had my long distance service switched from MCI to AT&T
without my authorization--and didn't find out until the bill came from my local
phone company, Pacific Bell. I called AT&T who said they keep no record of
where a switch request comes from (they insisted that I must have filled out a
form, or that I told a telemarketer to switch me, etc). They did take down an
incident report after I insisted on speaking to a supervisor's supervisor.
Pacific Bell told me that they do no verification if a long distance carrier
requests a switch on a customer's phone line; they receive a tape with phone
numbers on it and switch every number listed on the tape to AT&T. (Pacific
Bell also wanted me to pay to switch back to MCI, which MCI ended up paying).
Kraig R. Meyer kmeyer@aero.org
[This gets us back to the problem of the meaning of "unauthorized access"
where no authorization is required, or in this case the meaning of
"authorized access" when no authorization is requested! PGN]
In RISKS 13.70 Rex Black relates a story of being "called back" via RETURN CALL
by a woman who believed he had made a harassing call.
This is yet another version of an old set of pranks that involve connecting
together unsuspecting phone users. While most of us are more familiar with the
version where a prankster with 3-way calling connects together two strangers
(while listening in), I haven't heard much about people making harassing calls
while having CALL FORWARDING activated to deflect the return call.
Unfortunately, until we can tell whether a call we make is being forwarded
(which may mean until we get ISDN, or the messiah comes, I'm not sure which is
likely to come first), there is no way to prevent a prankster from deflecting
calls to another line. Rest assured, though, that the switch does know who
placed the call, and that CALL TRACE would properly finger the prankster no
matter what forwarding was in place.
Joe Konstan konstan@cs.berkeley.edu
I would like to think that a user-interface problem, not judging incompetence or favoritism, was the cause of the shocking loss by the US boxer. In the third round of the fight, with the score tied at 2-2 (an obvious problem right there), the German threw a punch that missed, and the American landed a counterpunch that split the German's eyebrow open. The German was awarded a point! How did this happen? Each judge has a box with two levers, one for each boxer. If the boxer in red lands a punch, the judge presses the left lever; if the boxer in blue lands a punch, the judge presses the right lever. Now: The judges watch the fighters stalk each other, circle, and throw combinations. They press the left lever — no, the right! Too late. I think the judges all pressed the wrong lever.
Several RISKS contributors have correctly noted that the problem with the computerized scoring system used for Olympic boxing is not the computer but rather the button-pressing speed of the judges and the scoring rules that were implemented in the program. The computer RISK is that electronic implementation of complicated scoring systems, systems which would not be feasible without computers, allows scoring rules to be used whose consequences are not well understood. These new scoring systems often seem reasonable on paper but turn out to have surprising consequences. I'll bet boxing officials were surprised (embarrassed?) to learn that all judges could score a fight in favor of Boxer A but that the majority-rule-per-punch rule could give the decision to Boxer B. The larger RISK is that implementations of "electronic town meetings" and telephone voting will allow the use of creative scoring systems for electing candidates and making policy decisions. Without extensive forethought, such computerized voting systems will inevitably produce unexpected results with more serious consequences than who receives boxing medals. There need not be surprises. There is a large literature in the field of public choice on the formal analysis of voting and scoring rules. Kenneth Arrow won the Nobel Prize in Economics for, among other things, proving that if there are three or more options [not a problem for Olympic boxing] then it is impossible to have a scoring system without unpleasant surprises such as being manipulable and producing intransitive choices. Since then the search has been on for finding voting systems that have the fewest problems and a large array of analysis tools are available. The boxing officials ought to have consulted experts in the field of public choice as well as computer experts. Perhaps they did. The boxing rules may not be all that bad; they have a remarkable similarity to the rules NASA uses to resolve disagreements among on-board computers and NASA did consult with the public choice experts. However, in the boxing case, it is easy to show that conservative judges [these may not necessarily be the worst judges as alleged in the recent case] have a disproportionate impact because it is more likely that their votes will be decisive in forming the majority on any given punch. The punchline is that computers may allow us to get into kinds of political trouble with fancy scoring rules that would not have been possible with paper-and-pencil systems which are forced to be simple. Gary McClelland Univ of Colorado mcclella@yertle.colorado.edu
Ed Ravin (elr%trintex@uunet.uu.net) and Steve Summit (scs@adam.mit.edu) hope
that the next generations will have less problems with (the user interfaces of)
machines due to childhood training at Nintendos etc.
I doubt this: I notice that I become more impatient the older I get. I spent
countless hours learning the tricks of my programmable calculator. Nowadays I
am too impatient to read the manual of my video recorder. When in ten years
they force me to use ATMs, I will probably even be too impatient for learning
that, especially if there are people waiting in the line (and it does not
matter that learning the system is the fastest way to get it done). As an
analogy, we have had forms since the invention of bureaucracy, but they still
confuse us.
M. Anton Ertl anton@mips.complang.tuwien.ac.at
In RISKS-13.70, Geoff Kuenning tells the story of a Mr. Cabin Baggage (actually
a violoncello) having a ticket on an airline flight. Having to ticket cabin
baggage that way is a potential RISK to a search and rescue party in the event
that the airplane crashes, since if the ticket is used, the passenger list will
show one more soul on board, and the rescuers will be looking for another
potential survivor. It would be a tragedy if a rescuer someday lost his life
trying to find Mr. Stradivarius Cello.
I know that I've had cabin baggage successfully ticketed by United without
having to come up with a fictitious name; some reservation systems do it right.
But musicians seem to get into this type of trouble. The duo-pianists Stecher
and Horowitz once arrived at the airport to find that the rear row of seats had
been removed from the aircraft to accommodate the stretcher — they'd been
booked as `Stretcher patient, Horowitz!'
[When dealing with computerized systems, we must be forewarned that we
need to be forearmed. But for pianists, four-armed can be four-handed
on one keyboard or duo-piano, on two. But the absence of seats cannot
be forewarmed. PGN]
[Incidentally, since I am already drifting in relevance (too much
flying?), John Levine (johnl@iecc.cambridge.ma.us) noted that a
professional cellist friend of his regularly buys a seat for his cello,
but the airlines won't let the cello join a frequent flyer program. It
would probably do violins to their computer system. At any rate, this
is certainly enough for this topic... Thanks for your indolcence. PGN]
For those in the greater Washington DC area, I will be teaching a course in
Georgetown University's continuing education program, surveying issues
arising from our entry into the "Information Age." The course description
is below, and it runs for eight Thursday evenings. Contact the School of
Summer and Continuing Education at Georgetown for further information (and
forward this note to others if you like). Ross
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ISSUES FOR THE INFORMATION AGE
This course will address issues of the "Information Age" for a
nontechnical audience, i.e., how computers and computer-based information and
systems are transforming the world around us.
What does it mean to say that "information about money is as valuable as
money itself?" Many companies do nothing more than broker information, as an
increasingly larger percentage of the U.S. economy. But where ought the
boundary between commercial profit and personal privacy be drawn? Lotus
Development Corp. cancelled its plans to market a database on consumers in the
face of protests from those it would have monitored, and across the U.S.
"caller ID" technology is facing severe scrutiny from all sides.
In the wake of the failed Soviet coup, a U.S. communications company took
out a full-page ad to congratulate Soviet citizens who, "armed with nothing
more than information...saved the day." News of the Tiananmen Square massacre
came to us out of China by way of portable satellite dishes and the fax
machine.
Information systems are making life more efficient, but never before has
it been possible for a simple computer glitch to cause a billion dollars worth
of damage--twice in 1991 software bugs crippled large portions of the U.S.
telephone system, and a Cornell graduate student's program shut down tens of
thousands of networked computers in 1988. [WELL, Cliff Stoll estimated 2,600
of the estimated 6,000 BSD Unix systems. PGN]
The legal profession is scrambling to apply yesterday's laws to new
realities, and "artificial reality" has been used in court testimony, while the
FBI lobbies to make digital telephones easier to wiretap. What do we have to
fear from "hackers?" Does computer crime pay?
Readings will be provided, taken largely from the current press, to serve
as background and focus for discussion.
Dr. Ross Alan Stapleton is a science and technology analyst with extensive
experience studying computer and information technologies in the former USSR
and Eastern Europe.
8 sessions, Thursday evenings, 7:45 to 9:15 p.m., September 24 through
November 12, 1992.
CALL FOR PAPERS
AND PRE-ANNOUNCEMENT
The 1992 World Conference On
Network Administration and Security
November 30 - December 4, 1992
Washington, DC
THEME: Practical solutions for cost-effective network administration and
security in a UNIX environment.
ELIGIBILITY: Network administrators, system administrators, security
administrators, technology managers, computer installation managers, and their
staff. In addition, a limited number of places are available for staff members
from organizations that offer off-the-shelf software and hardware products that
support network management and security.
LOCATION: Ramada Renaissance Techworld Hotel, 919 9th Street NW, Washington,
D.C. 20019, (202) 898-9000
CONFERENCE DATES: Tutorials: November 30- December 1
Technical Sessions: December 2- December 4
INFORMATION: For pre-registration materials, send mail to:
Program Chairman, Alan Paller, Conference Office, 4610 Tournay Road
Bethesda, MD 20816
or send email to paller@fedunix.org.
HOST ORGANIZATION: The Washington Area UNIX Users Group and the Federal Network
Administration Council.
CONFERENCE SPONSOR: the Open Systems Conference Board, a not-for-profit
educational organization dedicated to removing the barriers to widespread
adoption of UNIX and Open Systems.
WHY YOU SHOULD PARTICIPATE: The demands of mission critical applications are
driving the need for network innovation at an amazing pace. New technology and
new standards promote confusion and interoperability problems while at the same
time providing much needed connectivity and increased bandwidth. Cutbacks have
forced fewer people to provide more service with less money.
These challenges are particularly apparent and frustrating in the government
agencies (both in the US and abroad), universities, and companies which have
been in the vanguard of the move to open systems and networks of UNIX
computers.
This conference is designed to identify the current state of the art for
cost-effective network administration and security so that the techniques and
tools used by the most effective managers can be adopted by those still looking
for solutions.
Peer-reviewed papers will be complemented with invited papers plus
"Ask the Experts" sessions where you'll find practical answers
to your questions.
"Best Of The Net" session where you'll learn which free programs
available from the net are most useful.
"Tips and Techniques" sessions in which conference attendees can
share, in 5-minute presentations, their favorite techniques for
solving recurring problems. These sessions are run as moderated
BOFs with all conference attendees being asked, in advance, to
contribute if they choose.
"Ask OSF" session where you can learn from the people who brought
you DCE.
Informal Birds Of A Feather sessions in the evening to expand the
sharing time. Please send your suggestions for topics with your
registration.
In addition, the Monday-Tuesday tutorials will be taught by several of
America's top-rated instructors. Tutorial topics include TCP/IP and
UNIX Network Programming, UNIX Security, OSF DCE and DME, UNIX
Fundamentals, UNIX Internals, UNIX System and Network Administration
(Basic and Advanced courses), and Perl Programming.
*********************
** CALL FOR PAPERS **
*********************
Papers are being sought for the technical conference from network
administrators, system administrators, security managers, consultants,
academics, and hardware and software developers.
You don't have to have made a major breakthrough to have your paper accepted.
The delegates will be looking for good problem definitions and practical
solutions. And your presentation does not have to be long. You may choose a 15,
30, or 45 minute time slot.
IMPORTANT DATES FOR SUBMISSION:
Abstracts Due: September 14, 1992
Notification of Acceptance: October 12, 1992
Camera-Ready Papers Due: November 16, 1992
FORMAL REVIEW: Papers that have been formally reviewed and accepted will be
presented during the conference and will be published in the conference
proceedings. The Review Committee is composed of experts on network
administration and security along with managers of large installations and
architects from the vendor community.
Among the people invited to serve on the Review Committee are Matt Bishop
(Dartmouth), Michele Crabb (NASA Ames Research Center), Richard Stevens (author
of several best selling books on Network and UNIX Programming), Marcus Ranum
(Digital Equipment Corporation), Jonathan Gossels (OSF), and Bruce Hunter and
Rob Kolstad (well-known columnists).
The committee will decide whether your abstract addresses important
challenges (large or small), whether your approach seems promising, or
whether your abstract should be accepted for any other reason.
TOPICS: Please feel free to submit abstracts on any topic. The list
provided below may help prompt some ideas:
1. Managing heterogeneous networks
2. Policies and procedures on the network
3. Security policies
4. Network security monitoring
5. Network monitoring and performance testing
6. Training and education
7. Techniques for dealing with users
8. Networked backup schemes
9. Distributed mail systems
10. Domain Name Service configuration
11. Distributed console access
12. OSF's DCE and DME
13. Off-the-shelf tools
14. Tools you don't like and why
ABSTRACTS: A good abstract will by 500 to 1,500 words in length and
include the following:
1. A description of the problem(s) and its importance.
2. Your solution including details of how it worked. If this is work
on emerging technology, try to show what the expected impact will
be. If your solution is based on commercial hardware or software
tools, name them. Abstracts from vendors are welcome, but should
not be sales pitches.
3. Data on how well it works: before/after comparisons, direct savings,
trade-offs, etc.
4. Lessons learned and what you might have done differently.
Please also provide the following information about the author(s):
name, title, organization, daytime telephone, surface mail address,
email address (please), FAX if possible.
Finally, tell whether you want a 15, 30 or 45 minute time slot for
your presentation.
WHERE TO SEND YOUR ABSTRACTS:
Technical Program Chairman
Hal Pomeranz
NASA Ames Research Center
M/S 258-6
Moffett Field, CA 94035-1000
Questions or abstracts (PostScript or ASCII) may be submitted via email
to pomeranz@nas.nasa.gov.
[Because many of our risks involve networking, it
seems appropriate to include this item. On the
other hand, as RISKS readers, you should be prepared
to ask lots of nasty questions if you attend. PGN]
Please report problems with the web pages to the maintainer