Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 7: Issue 5
Tuesday 7 June 1988
Contents
Re: Auckland cable cars (in Wellington)- Mark Davies
Perfect computers- Hugh Cartwright
Assigning viruses- Ian G Batten
Programmer sabotage- Bob Devine
First Interstate disaster planning and the L.A. fire- Jeff Lindorff
Telecommunications redundancy- Joel Kirsh
Look and Feel Copyright Issue- Karl A. Nyberg
Risks of root typos- Tim Pointing
Access to DEC VMS 5.0 technical seminar- Claude Barbe
Risks of bank ATM cards- Karl Denninger
Re: Australia Card- Greg Bond
Info on RISKS (comp.risks)
Re: Auckland cable cars (in Wellington) (Richard A. O'Keefe)
Mark Davies <ames!comp.vuw.ac.nz!mark@uunet>
Sun, 5 Jun 88 14:00:01 +1200
The cable car was in Wellington (in fact a guy in an office down the hall was waiting to catch it at the time and watched it go right past the stop and into the buffers at the end of the line). I had intended to post something at the time but the newspaper reports were pretty vague. The cable car had only recently come back in service after its major yearly maintenance which apparently included a rewrite of its controlling software. The braking system failed to engage, and several people suffered minor injuries. The current status (several weeks after the accident) is that the cable car is still not running and samples of the code have been sent to the manufacturer, a European (Swedish?) firm. This is from memory, more details when/if they become available. mark
Perfect computers
<HCART%VAX.OXFORD.AC.UK@CUNYVM.CUNY.EDU>
7-JUN-1988 09:32:02 GMT
The Sunday Times in the U.K. has produced, and is offering for sale, videos on
microcomputing, because ''...there is clear evidence that British management
has not yet appreciated the benefits of the microcomputer revolution.''
One of the benefits the Sunday Times has identified (June 5) is new to
most of us reading the RISKS forum, I suspect:
''In the computerised office information, once entered, is always
available....It is impossible to introduce an error, because the
transaction is entered once only.''
The discovery by the Sunday Times of computers that can prevent entry
of faulty data (provided, evidently, the entry is attempted once only),
must be of interest to us all.
But what of those reading the article who might believe it ?
Hugh Cartwright, Oxford University.
Assigning viruses (RISKS-7.4)
Ian G Batten <BattenIG%uk.ac.bham.cs@CUNYVM.CUNY.EDU>
Tue, 07 Jun 88 17:46:49 BST
Talking of teaching virus-writing, WHMurray@DOCKMASTER.ARPA writes "The next thing you know, they will be assigning plagiarism. How about the forgery of academic credentials?" One of the UK Polytechnics (virtual Universities) assigned a student exercise that was to break into some system (I seem to recall it was an 11/44 running V7) and assign yourself an "appropriate" mark. There was quite a row about it at the time (about two or three years ago). I'm afraid I can't recall any details beyond its being a London poly. ian University of Birmingham Computer Science Department
Programmer sabotage
Bob Devine <devine%cookie.DEC@decwrl.dec.com>
Tue, 7 Jun 88 10:50:46 PDT
This is not really a "risk" but is yet-another case of increased legal
definition of programming. Bob Devine
A programmer was found guilty under a Colorado law when he destroyed a
program. A legal research company hired him to write a personal computer
application that would permit a lawyer to search for relevant case law.
When a deadline was approaching and a leave request was refused, the
programmer resigned, telling the company that they would never have the
program. When the program could not be found on the system after he left,
the company had to start over.
The programmer was found guilty of theft and computer crime.
First Interstate disaster planning and the L.A. fire (RISKS-7.3)
Jeff Lindorff <jeffl@sequent.UUCP>
6 Jun 88 21:09:37 GMT
The following is excerpted from an Associated Press article by George Garties. I can attest to the effectiveness of the measures described within as a customer of First Interstate Bank. Not once, in my experience, has a banking problem at my local branch been blamed on the Los Angeles fire. AFTER THE TOWERING INFERNO, FIRST INTERSTATE DOSEN'T MISS A BEAT Cole Emerson has known for two years that when the big earthquake hits California, it will be his job to get First Interstate Bank back into business. When the city's worst high-rise fire swept the bank's headquarters last month, Emerson saw his disaster plans put to the test, and by all accounts, they passed. [The May 4 fire gutted 4 1/2 floors of the 62-story building, killing a maintenance man and closing the building for an indefinite period of time.] But by the start of banking hours the next day, the vital business of First Interstate Bankcorp, the nation's 9th-largest bank holding company, was proceeding. And only one of the company's 320 California branches was closed. The one on the building's ground floor. Emerson, 42, is in charge of contingency planning and computer security. He is assigned to First Interstate Bank of California, although in the headquarters fire, his plan and staff also helped restart the parent company, which owns banks in 13 states and franchises in 10 others. He recalled that shortly after the fire broke out, his five-member "business resumption group" and a parallel group that deals with staff safety opened the bank's new emergency center in a computer operations building seven blocks from the downtown headquarters. As damage reports came in, Emerson's group orchestrated moves for the vital groups that work in the headquarters. They saw the securities trading department dispersed, with traders flying to company offices in Hong Kong and New York, as well as taking borrowed space in Los Angeles. They were prepared, since the disaster plan calls for traders and other key employees to carry home diskettes bearing vital records from their personal computers. The main computers handling the bank's daily rush of consumer and business transactions weren't in the headquarters, but if they had been knocked out, they would have been backed up in Northern California. The disaster plan was developed to deal with a great earthquake. The state Office of Emergency Services says odds are better than 50% that such a quake will hit the region in the next 25 years. "An earthquake is real, and it's catastrophic, and it's going to happen," Emerson said. "There's nobody in my position in any of the banks who's going to say 'if.' It's always 'when it's going to happen.' I feel even more confident right now that we're well on the way to being prepared for that." Jeff (Not employed by Sequent Computer Systems, Beaverton, OR., so don't blame them.)
Telecommunications redundancy
Joel Kirsh <KIRSH@NUACC.ACNS.NWU.Edu>
Wed, 1 Jun 88 10:34 CDT
The mention of government involvement in assuring robustness of
telecommunications jogged my memory. I recall reading of a particular
U.S. government agency, which is solely responsible for taking control
of telecomm services in the country in the event of a national emergency,
to insure that the government's communications abilities are maintained.
The article went on to describe that the agency's control center was
located within the blast radius of several primary nuclear targets, and
no plans had been made to build redundant control centers.
Look and Feel Copyright Issue
Karl A. Nyberg <karl@grebyn.com>
Tue, 7 Jun 88 14:11:57 edt
Text of an article in the Wall Street Journal this morning. (I claim USC 17
in reproduction of this article for fair use, or whatever the appropriate
legal term is...)
This could have a chilling effect on the future development of software if
the ruling is applied very broadly. I'm trying to get an actual copy of the
specific ruling.
-- Karl, Grebyn Corporation, 703-281-2194 --
U. S. Agency Rules Software Copyrights Protect Displays on Computer Screens
By Bob Davis, WSJ, Tuesday June 7, 1988, p. 4.
WASHINGTON - The Copyright Office, in a boost to software publishers, ruled
that software copyrights protect displays on computer screens from
infringement.
Protecting software, either by patents or by copyrights, has been a muddled
field of law in recent years. In a major case this year, Apple Computer,
Inc. sued Microsoft Corp. and Hewlett-Packard Co. in March for copying
certain graphical display features that Apple popularized in its Macintosh
personal computers. An Apple spokeswoman, however, said yesterday's ruling
doesn't directly affect that case.
Besides Apple, Lotus Development Corp. has tried to protect innovative
computer displays by bringing copyright-infringement cases against
competitors. But in cases of this type, it hasn't been clear whether
copyright protection extends to instances in which companies, using
different computer codes, generate displays that look like those of popular
programs.
The Copyright Office, a part of the Library of Congress, rules that when a
software company copyrights a program, it automatically copyrights the
graphic and textual displays produced by the program. At the same time, the
Copyright Office said publishers don't need to register any display or
textual screen separately.
"We think the screen will be protected, no matter what the code" used to
create it, said Richard Glasgow, the Copyright Office's assistant general
counsel.
As an example, Mr. Glasgow said that if Apple copyrights its Macintosh
software, the copyright "probably" protects the trash-basket symbol Apple
uses to tell users how to discard files. Apple would only need to prove it
has "an original drawing" of the trash basket to be covered by the
copyright, he said.
... stock information ...
Decisions of the Copyright Office, which sets rules governing copyrights,
are influential in federal courts that interpret those rules. Copyright
protection lasts for 50 years after the death of an author or for 75 years if
a company commissions the work and retains the copyright.
Jason Mirabito, a Boston copyright attorney, said the copyright decision
gives "greater protection and certainty" to software publishers. Had the
Copyright Office required publishers to register every computer screen, he
said, judges would likely have interpreted the protection narrowly to cover
only exact copies of the disputed display screens.
But Mr. Mirabito said the broader copyright protection would likely
encourage judges to rule that software publishers can protect their programs
from competitors that merely "look and feel" like popular programs, but
aren't exact copies.
However, computer veterans worry that if protection is extended too broadly,
it may harm consumers and retard innovation, because it will slow the
development of standardized displays. With such displays, computer users
wouldn't have to learn a new set of commands with every new software
program.
Moreover, "look and feel" cases are especially murky. If Shakespeare were
alive, Mr. Mirabito speculated, he could have a copyright infringement case
against "West Side Story" because it's very similar to "Romeo and Juliet."
The Apple spokeswoman said the ruling doesn't affect the suit against
Microsoft and Hewlett-Packard, filed in San Jose, Calif., because Apple had
filed separate copyright applications covering both the "literary and
audio-visual" aspects of the display features it wanted to protect.
In its suit, Apple also accused Microsoft of exceeding the limits of
licenses granted to it by Apple to use certain display features. At the
time, computer industry analysts and intellectual property experts
interpreted the suit as Apple's attempt to preserve a technological edge
just as rivals were starting to close the gap.
[This case never ceases to amaze me, particularly in that much of
the innovation came from Doug Engelbart's Augmentation Research Center
at SRI in the 60's and 70's, and thence from Xerox PARC. PGN]
Risks of root typos
Tim Pointing <tim%dretor@uunet.UU.NET>
Fri, 3 Jun 88 11:42:32 EDT
In Risks v6n92, Dave Sherman <dave@lsuc.uucp> writes... about accidental mis-use of dump wiping out a filesystem. The same sort of incident happened here earlier this year when somebody (who shall remain nameless to protect the horribly guilty [not me]) was running fsck on a PDP 11/70 running V7. This person's only mistake was leaving out a space. Instead of typing "fsck -t tempfile /dev/rroot" s/he typed "fsck -ttempfile /dev/rroot" (for those not familiar with the old fsck, the "-t" flag specified a temporary file for holding tables that grew too big for small address space machines). Unfortunately, this fsck came from well before the time that "getopt" existed and manually parsed the arguments. It expected the temp filename as the argument after the "-t", not glued to it. The result was that fsck used the root filesystem device for its temporary storage (to ensure that the damage was severe, fsck starts by zero'ing the temporary file :-) and started checking a default filesystem. In the blink of an eye, the first 400 blocks of the filesytem were gone. Combine this typo with a flakey emergency system which, for reasons we have yet to determine, restored files incorrectly, and you can see that we had some *real* fun getting the system back on-line. Tim Pointing, DCIEM
Access to DEC VMS 5.0 technical seminar
"Claude Barbe - SDR - (203) 431 5524" <BARBE%sdr.slb.com@RELAY.CS.NET>
Fri, 3 Jun 88 10:03 EDT
Working in the US under a 3 year L1 visa, I first could not enroll in the DEC VMS 5.0 technical seminar since I was not a US citizen nor holding a "green card". What surprised me is 1) the regulation that forces DEC to inquire about citizenship (the IRS is not that picky...) and 2) the menu system to accept my application could not handle L1 visa numbers... Claude Barbe - Schlumberger-Doll Research, Ridgefield, CT
Risks of bank ATM cards (more) (RISKS-6.94)
Karl Denninger <mordor!lll-crg!lll-winken!ddsw1!karl@rutgers.edu>
Thu Jun 2 16:08:19 1988
Here's another risk in the use of the ATM cards: At New Century Bank in Mundelein, IL there is an ATM terminal. About a month ago I used this terminal to make a sequence of transactions. The final transaction, a withdrawal of $20.00 was denied with a message "Cannot complete, try later". The card was ejected, with *no receipt* indicating failure. Thinking nothing of it, I went to another bank and obtained my cash. About three weeks later the *same* thing occurred. Suspecting something funny was going on, I reinserted the card, and discovered to my horror that the ATM had indeed debited my account, yet not dispensed any cash -- AND NO RECEIPT. This time I got a little peeved. The bank with the terminal (New Century) was unable to help at the time of the incident -- they claimed they had to wait for the "proof" from the machine the next day. My bank said the same thing. The next day, my bank said that yes, indeed, there was a transaction recorded, and to their knowledge *it was paid by the machine*. They put in a charge-back request to New Century. Upon more stringent questioning, they admitted that the charge-back might be refused by New Century Bank, and that since I had no receipt to prove that the transaction failed, I could be out the amount of the transaction in question! (the card agreement clearly states that receipts from the machines are considered "official" evidence of a transaction or failure thereof, and that they are the *only* evidence which the bank will accept!) I placed a call to "Cash Station, Inc" (the regional company handling the ATMs in this area) in an attempt to discover why the machines had been programmed to not issue receipts on failed transactions. Reaching someone with authority there took two days (!), and when I finally did get through the end result was that no change would be made. New Century did eventually own up to having a problem -- in fact, they said that after investigation I was not the only one who had been "hosed". My questions were (and still are): o Why was this not caught when the machine was balanced? It would seem as though if the machine recorded a debit of $20.00, and didn't issue the cash, that the machine would be out of balance by $20.00.... o After discovering that the machine was out of balance, why did New Century not attempt to rectify the problem themselves, or place the machine out of service until it was working properly? WHY DID THEY POCKET MY CASH? o Why was a decision made to not issue receipts on denied transactions, and why does Cash Station, Inc. refuse to *require* that institutions issue these receipts? o While I was on the phone with Cash Station, Inc. I inquired as to the display of balances (this was another "sticking" point with me; they were often off by hundreds of dollars). Their reply was that the network which interconnects the ATMs "cooks" your balance (!) depending on what you do at the terminal. In other words, the balance shown by the terminal MAY NOT BE YOUR TRUE BALANCE. When I asked as to why there was no indication anywhere that these numbers were "finagled" they indicated that the response time of the member bank's computers was insufficient to get a real balance.... sounded (and still sounds) fishy to me. Isn't this *literally* fraud, as they claim that number on the screen to be your BALANCE? (along this line, the machines do not dispense receipts on balance inquiries either -- perhaps to prevent you using these as "evidence".) It would appear that someone (or many someone's) have been making out like bandits on these "failures" -- I was hit twice within 30 days, at the same terminal. How many others (who don't balance their checkbooks and thus never catch this kind of error) have also been taken for a ride? What is most disturbing is that there was no indication that the problems would be resolved -- that is, no one was willing to state that they would begin (now or any time in the future) to provide receipts on all transactions in order to facilitate proof of what had occurred. I have decided to boycott all ATMs in the Chicago area until I receive some satisfactory answers to these questions. So far no one has been able to provide them. I suggest that others who are concerned for the safety of their funds also boycott the ATMs. Go to a Jewel (food store), where you can still use the card, yet you deal with a *human* who hands you your money. Karl Denninger, Macro Computer Solutions, Inc. ...ihnp4!ddsw1!karl
Re: Australia Card [RISKS DIGEST 6.94]
Greg Bond <munnari!vertical.oz.au!greg@uunet.UU.NET>
Thu, 2 Jun 88 12:32:50 EST
This card was intended as a plastic card. I never saw any intention of
a smart-card system. The initial idea came from the HEALTH department,
as all eligible residents carry a "Medicare" card for the national
health system. The Australia Card was to replace the Medicare card for
the health system, and was also to be used for taxation, social
security and other financial transactions. (For example, to open bank
accounts, or start jobs, or employ brokers/agents, so any taxable
transaction could be followed.) As the idea evolved, more and more
departments and uses were included. I think over a dozen departments
and 25+ "systems" were to have access to (part of) the database.
With 15M people, that is one ENORMOUS database.
The benefits the Govt. were flogging (and quite hard too) was savings
on social security and tax fraud. (Numbers like $1b/year - about 2-3%
of the Govt. budget).
There was to be a "Data Protection Agency" that was to monitor and
control access to the sections of the database. No-one really believed
it would work.
The idea was killed after the largest, loudest and longest public
campaign I have seen. Many groups joined in, from the looney left to
the radical right, including most professional Computing and
Engineering bodies, as well as the obvoius civil liberties groups.
The RISKs? This proposal took on an awesome momentum, and grew
frighteningly fast. I'm glad it was killed off before it started
as unwinding or even slowing the increase would be enormously
difficult. And governments aren't known for taking tough decisions.
One of the arguments in favour of the card was that with one centralised
database, and legislative controls over access, we as citizens would
actually be better off as far as protection and privacy were concerned.
Comments?
Gregory Bond, Vertical Software, Melbourne, Australia
Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net)
Bang: {uunet,mcvax,pyramid,mnetor,ukc,ucb-vision,...}!munnari!vertical.oz!greg
struct responsible for(these_opinions) { return me && !my_employer; }

Report problems with the web pages to the maintainer