The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 6 Issue 38

Monday 7 March 1988

Contents

o EPROM Risk
Brian Randell
o Bigoted expert systems
Jack Campin
o PC-LOCK -- BEWARE
J Greely
o Yet another antiviral program -- BEWARE
Ted M.P. Lee
o mac II virus
Robert Ward
o Database Design and Misuse
James H. Coombs
o Correlating databases; Disappearing skills; Copious warnings
Paul Smee
o Re: Disappearing Skills
Henry Spencer
Jonathan I. Kamens
David Wittenberg
Mark Vonder Haar
o Re: Police computer problem -- license-plate matches
Brint Cooper
o Leap year madness
Alan J Rosenthal
o More on Bank ATMs and checking your statements
Eric Herrmann
o Info on RISKS (comp.risks)

EPROM Risk

Brian Randell <Brian_Randell%newcastle.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 7 Mar 88 9:48:47 WET DST

The amusing, but rather vague, article which is excerpted below, was in The
Guardian of 7 March 1988. From further (non-excerpted details) I surmise
that it comes from a press release from the makers of the Psion Organiser. 

PSION'S MEMORY IS MADE OF THIS, by Tony May

  As a drug smuggler, Paul Dye knew that a filofax was of no use to him, but
since his highly entrepreneurial business demanded a portable diary, contact
list, memory prompter, calculator and note-taking device, he opted instead for
a Psion Organiser.
  At around (pounds)100 for the basic machine, he got a hand-held computer
whose memory could hold details of his (pounds)200 million drug smuggling ring,
and could be wiped clean if the law caught up with him.
  But since he has been fined (pounds)202,000 and is now doing 28 years in gaol
partly on the strength of evidence obtained from the machine's "erased" memory
we may conclude that he potentially has a case under the Trades Description
Act.
  Our computer staff tell us that when he came to erase his file the details
were no longer available to him but were retained in the EPROM chip-based
storage system which does not actually erase.
  They also tell me that Psion may have had another walk-on part in the case as
members of the ring used corsets bought from Marks & Spencers to carry heroin,
and the stores use Organisers for till price checking and chargecard
validation.
  Mr Dye may not have been entirely happy with his purchase, but Psion believes
that 300,000 of them will have been sold by the end of year ......

Brian Randell, Computing Laboratory, University of Newcastle upon Tyne
PHONE = +44 91 232 9233         JANET = Brian_Randell@uk.ac.newcastle
                                UUCP  = ...!ukc!newcastle.ac.uk!Brian_Randell

                            [Ah, the old residue problem strikes again.  
                            The eraser's edge.  Psion-ARA!  PGN]


Bigoted expert systems

Mr Jack Campin <jack%cs.glasgow.ac.uk@NSS.Cs.Ucl.AC.UK>
Mon, 7 Mar 88 18:48:47 GMT
Further to Brian Randall's posting about the St George's Hospital case:

According to the Times Higher Education Supplement (26.2.88) St George's is
actually one of the LEAST discriminatory teaching hospitals in London, with
12% nonwhite students; others, using human assessors whose procedures cannot
be reviewed, get as low as 5%. In a warped way this is almost a success story.

What other examples do readers have where "knowledge" elicited from "experts"
has codified prejudice? There are proposals afoot to give expert systems total
control of British social security benefits; the record suggests that any
bigotry that can be built in, will be (refusals of benefit have been made in
the past on racial grounds by clerks belonging to neo-Nazi organizations).

Does any state anywhere have legislation requiring public access to source
code of software performing tasks like that? (not that that would be a lot
of help with a neural network that didn't like black faces).
ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk       USENET: jack@cs.glasgow.uucp
JANET:jack@uk.ac.glasgow.cs      useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens,
      Glasgow G12 8QQ, SCOTLAND     work 041 339 8855 x 6045; home 041 556 1878


PC-LOCK (Re: James Ford, RISKS-6.34) -- BEWARE

J Greely <jgreely@tut.cis.ohio-state.edu>
Mon, 7 Mar 88 03:21:13 EST
>There is a program called PC-LOCK (*NOT* the PD version) which is made by
>Johnson Computer Systems.  We have installed it on some hard disks here and
>have had no problems at all.

A quick warning about PC-LOCK (shareware).  If you are currently using
version 1.0, REMOVE IT IMMEDIATELY.  It will not hurt you if it already
works, but you might be tempted to give a copy to someone else, and this
could be fatal.

  Version 1.0 stores your password in an "unused" section of the partition
table, and does not document this.  Approximately 10% of all Western Digital
hard disk controllers (PC/XT version) *also* use this section, for an
advanced partition management feature (that never worked).  If you have one
of these controllers, installing PC-LOCK version 1.0 will lock your system,
and make your hard disk completely inaccesible.  The good news is that
Western Digital will send you a replacement BIOS chip upon request (mine
arrived within 3 days).  PC-LOCK version 1.1 does not have this problem, and
performs perfectly on every system I've seen it on.

>     You have to boot with drive "C" and enter the proper password to gain
>access.  There are 5 possible passwords you can set/use....1 administrator
>password and 4 user passwords.

Sounds like a newer version.

>PC-LOCK, Johnson Computer Systems, 20 Dinwiddie Place, Newport News VA 23602

If you'd like to contact the author by phone (I had to, about the version 1.0
problem), there is no listing for JCS, just ask for a Johnson on Dinwiddie.
He was very helpful, and has further information about who to contact at
Western Digital.


Yet another "antiviral" program -- BEWARE

<TMPLee@DOCKMASTER.ARPA>
Thu, 3 Mar 88 11:54 EST
The following is abridged from the March 3 Minneapolis Star & Tribune.  Anyone
willing to guess how many people are being suckered into buying this (or other
similar products) and how long it will be before they discover that the
protection being advertized is illusory and can't be anything but?  Now if the
vendor (Lasertrieve) in question also sold insurance and was willing to
significantly lower the premium for insuring against loss of data if you used
his program, then I'd listen.

N.J. FIRM SAYS IT CAN 'INOCULATE' COMPUTERS AGAINST 'VIRUSES'

Associated Press
Seattle, Wash.

A New Jersey company is offering to "inoculate" computers against "viruses,"
or rogue programs that are designed to spread from computer to computer and
damage data the computers store.

The Viralarm system was announced Tuesday by officials of Lasertrieve Inc., of
Metuchen, N.J., during a Microsoft Corp.  conference on [CD-ROMS].

A statement issued by Lasertrieve said that although the newer CD-ROM disks are
impervious to corruption because information on them cannot be altered, many
computer users are concerned about protecting programs on hard disks or on
conventional floppy diskettes.

Viruses are creating a growing fear among computer owners and users.  Officials
in Israel recently announced the detection of a virus that, if left to spread
unchecked, could have wiped out memory banks and disabled computers throughout
the country.

Previous antiviral programs only drew attention to changes, noted the size of a
program or monitored the dates of program changes, and all were "easily fooled
by sophisticated viruses," the statement said.

Viralarm consists of a special program to protect another program, creating a
software barrier.  The protection is available for individual personal
computers and works for most of the operating systems now available, the
Lasertrieve statement said.


mac II virus

Robert Ward <rw23+@andrew.cmu.edu>
Mon, 7 Mar 88 12:56:21 -0500 (EST)
It was recently reported in this newsgroup that the editor of "MacMag," a 
Canadian monthly magazine, hired a programmer to create a Mac II virus which 
served more or less as an advertisement (or at least an attention-getting 
device). The virus was supposedly set to go off on March 2, the birthday of 
the Mac II. It was reported that the virus had been spotted on Compuserve and 
other commercial databases.

Well, it's now well past March 2...any actual sightings of contamination?


Database Design and Misuse [RISKS-6.32 and -6.36]

"James H. Coombs" <JAZBO%BROWNVM.BITNET@MITVMA.MIT.EDU>
Sat, 5 Mar 1988 22:15:30 EST
I have been thinking about design requirements.  First, a database
designer needs to understand thoroughly both the data that will be
stored in the database and the ways that it will be used.  Clearly, the
designer must be a pessimist.

One way to reduce problems caused by partial data would be to specify NULLS NOT
ALLOWED for critical fields.  This would prevent the entry, for example, of a
record specifying a license number but not a make and model.  Unfortunately,
energetic organizations can easily subvert such integrity constraints by
directing their operators to enter some value that will be treated as a NULL
(e.g., "N/A" for make and model).  Nonetheless, designers must make themselves
aware of the consequences of NULL values in particular databases.  Even though
their efforts can be subverted, they can make such subversion relatively easy
to spot; they can supplement their design efforts by specifying clearly in the
documentation that pseudo-NULL values should not be entered.  Should a database
fall into misuse on entry, an ethical supervisor might still appear someday and
correct the situation.

If it is preferable to allow entry of partial records, one can still define
views that allow only certain people to see those records.  Once the record is
filled out, it becomes available to others.  Again, this sort of constraint can
be subverted easily (e.g., assign the appropriate privileges to everyone).

Alternatively, as PGN suggests, the front end can issue warnings when the
results are likely to be misinterpreted.

In all of these situations, however, we rely on the organization 1) to want to
use the database properly and 2) to enforce the appropriate constraints.  I do
not believe that designers can prevent this sort of misuse.  (In an extreme
case, a pseudo-NULL could be chosen from the values of a closed set, e.g., all
cars of color RED are understood to have an unknown color.)

I hope that I'm missing something here.
                                                  --Jim

Dr. James H. Coombs, Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS), Brown University

    [Interesting choice of example, in that red cars are 
    involved in accidents disproportionately many accidents!  PGN


Correlating databases; Disappearing skills; Copious warnings

Paul Smee <Smee@AUCC.AC.UK>
Fri, 4 Mar 88 10:45 GMT
Several short comments on miscellaneous recent discussion.

'On the topic of correlating databases':  Matt Fichtenbaum mentions a NY
match of the driving licenses DB with the aid to the blind DB.  Never
lived in NY, but in many states, eligibility for aid to the blind is
determined by the state of your *uncorrected* vision; while eligibility
for a license is determined by the state of your *corrected* vision.
The general principle involved is that while cross-correlation may,
prima facie, seem reasonable, it might not really be meaningful.

'Disappearing skills':  The biggest danger posed by people who can't do
simple math 'the hard way' is that they tend to trust whatever their
computer or calculator says.  Knowing how to do it by hand, and well,
increases a person's 'feel' for the right answer.  For example, I
recently objected to a sales assistant trying to charge me an amount I
knew was wrong.  'The till [US cash register] says it's 12 pounds', she
insisted.  'Why don't you believe it?' Well, I said, I've got 5 items,
each under a pound, so can't be over a fiver.  Indeed, she'd mis-keyed
one of the prices.  More frighteningly, I occasionally see the same sort
of obviously wrong (but 'the computer said so, it MUST be right') answer
being accepted by an engineering student.  I would be much more
comfortable if I felt that the bridge I'm driving over (or the airplane
I'm on) had been designed by someone who had a 'feel' for the maths, so
that he or she would be able to recognize if the 'computed solution' was
actually believably near to the reasonably expected one -- or if not,
why not.  I think knowing the basics helps give this sort of feel.

'Copious warnings':  (I've lost the original title of this chain).  The
principle of the 'boy who cried wolf' is often neglected -- dangerously,
I think.  For example, the micro I use at work always says, when you ask
it to format a disk, 'Warning:  formatting disk B will cause all data on
the disk to be lost.  Do you really want to do this?' Well, I know it's
going to ask that, and I know I've just put a virgin disk in the drive,
so I always anticipate it with a 'yes'.  Some day I'm going to forget to
set drive B (so it will go for A, or worse, C); or I'm going to mix up
my disks in the shuffle, and regret it.  It would be safer (in my
environment at least) if it would first LOOK at the disk, and reserve
the warning for those cases where the disk actually already has been
formatted.  (My controller can tell the difference, at least for it's
own format disks.  There would be the risk, of course, of accidentally
formatting a disk which has already been done in some other machine's
non-standard format, but for me that's not an issue.)  There are a lot
of examples of this in computing -- for example the system which
*always* asks you to confirm deletions.  Of course I want the thing
deleted, I wouldn't have asked you to otherwise.  For my own (mainframe)
delete I've managed to wrap in a personal heuristic, so it asks only if
(a) the file(s) are 'protected'; or (b) the file string contains a
'dangerous' wildcard spec -- like '**' (everything); or (c) I've
requested multiple single files (because, the way I work, that usually
means I've mistyped some filename like '*.fred' as '* fred' instead.
Nevermind bugs, faults, and breakdowns in 'emergency warning' systems --
there's a lot of just plain poorly thought out design.


Re: Disappearing Skills [RISKS 6.35]

<mnetor!utzoo!henry@uunet.UU.NET>
Sun, 6 Mar 88 00:10:59 EST
> I never learned how to multiply by using a slide rule ...

Ah, but what happens if it becomes necessary to find a logarithm or a
square root and your calculator's battery is dead?  If it were me, I'd
either dust off my slide rule or dig out a book of tables -- I have, and
can use, both -- but those options increasingly are not available.  (The
standard references like the Handbook of Chemistry and Physics are dropping
things like log tables on the grounds that they are superfluous nowadays
and the pages are better used for other material.)  One can argue that
logarithms and square roots are in some sense less fundamental than
multiplication, but to what extent is this a lingering side effect of days
when multiplication was easier?  Certainly I use the square-root key on
my calculator quite a lot.

> ... The need for multiplication will probably exist as long as mankind ...

The same can be said of the need for logarithms, square roots, trig functions,
etc... and artificial aids have been the normal approach to them all along.
Engineers have been completely dependent on artificial aids for doing
multiplication -- in the sense that the slowness of doing it by hand would
be considered utterly intolerable for practical purposes -- for many decades.
(Here I am not talking about computers, but about mechanical calculators,
slide rules, and log tables.  Not to mention assistants!  Grace Murray Hopper
once commented that she could remember when "computer" was a job title, not
a piece of machinery.)

> Technological advances should save us time; they should not "save" us the
> "bother" of being able to think.

To what extent does a purely mechanical skill like multiplication constitute
"thinking"?

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry


Re: Disappearing Skills [RISKS 6.36]

<jik@ATHENA.MIT.EDU>
Sat, 5 Mar 88 22:30:47 EST
In RISKS 6.35, Ronald J. Bottomly says,

  I am not condoning technological stagnation, but I am condemning
  absolute technological reliance.  The need for multiplication will
  probably exist as long as mankind exists; but it seems dangerous
  (RISKy?) to come to rely upon calculators (or whatever will succeed
  them) to perform this multiplication.

A story by Isaac Asimov called "A Feeling of Power" illustrates this
point beautifully, using the same example (dependence on calculators)
that Mr. Bottomly uses.  The story takes place at a time so far into
the future that man has become completely dependent on calculators and
has forgotten how to do calculations by hand.  One man rediscovers
hand calculation, and the results are quite surprising.  I won't spoil
the plot, but I definitely think it is worth reading.

  Jonathan I. Kamens


RE: Disappearing skills

David 'Witt' Wittenberg <wittenberg%ultra.DEC@src.dec.com>
Fri, 4 Mar 88 06:29:23 PST
[Also noted Issac Asimov ...]

The thing that scares me more than people being unable to do arithmetic is 
the inability to recognize wildly erroneous calculations.  A friend of mine
(who works as a software engineer) quoted a value for the ability of a ski
resort to move people up the mountain. It was off by 4 orders of magnitude.
Even if we lose the ability to add accurately, we must retain the ability
to recognize major errors.
                                        --David Wittenberg


Disappearing Skills (Re: RISKS-6.33)

<allegra!cbcsta!mvh@EDDIE.MIT.EDU>
Mon, 7 Mar 88 18:09:53 est
We have long ago lost *THE* most fundamental basic skill for 95% of the people
in western civiliation: farming.  Unless you can feed yourself, please don't
lament the loss of multiplication skills.  By the way, technology is probably
the primary cause of lost farming skills.
                                                  Mark Vonder Haar


Re: Police computer problem -- license-plate matches

Brint Cooper <abc@BRL.ARPA>
Fri, 4 Mar 88 0:24:17 EST
I'm all in favor of improving the matching algorithms used by the police, to
avoid using defective database systems and cause serious problems for
innocent people.

But here's the other side of the story:  Look how the police can use
database systems to be more efficient in catching up with people running
loose with outstanding arrest warrants.

About 4 years ago, a young man whom I know neglected to pay a $25 Public
Defender's fee for services in District (Traffic) Court.  Subsequently,
a bench warrant was issued for his arrest for violation of probation.
Meanwhile, he had left this state and was working elsewhere.

Six months ago, the man was vacationing within the state and locked his keys
in his car.  At 3:00 a.m. police found him trying to open his own car with a
coat hanger.  Being forthright, he showed his license and said, "This is my
car.  I've locked myself out."  Here there are two databases:  one for
outstanding traffic violations and one for outstanding criminal warrants.
Since this fellow was doing something possibly "criminal," the cops checked
the latter database and got a hit.  They detained him and the rest is sadder
history than it need have been.

Once in a while, we who worry about risks should review the countless
routine uses of computers and databases without which ours might be a less
desirable society in which to live.  We're a large country, and this brings
special problems that seem made to order for computers.
                                                              _Brint


Leap years

Alan J Rosenthal <flaps%dgp.toronto.edu@RELAY.CS.NET>
Mon, 7 Mar 88 10:45:07 EST
A program was discussed recently that caused accounts created on 29 feb
this year to be listed as expiring on 29 feb next year, and access then
to be denied due to the invalid expiry date.

In risks 6-34 Michael Wagner identifies three design errors:
>  1. Two different representations/algorithms for dates ...
>  2. At least one representation allows illegal dates to be expressed ...
>  3. The treatment of an illegal date *in the future* as an expired date...

I think concluding #1 and #3 is not justified.  Probably dates were simply
represented as records containing entries for day, month, and year (like on
many IBM computers).  Since 29 was in the valid range for a day, it was
representable.  Then the simple approach of adding 1 to the year would
produce an invalid date.  I don't think that the original article said that
the illegal date was treated as being in the past; it's probably just that
as a security feature access is denied to accounts with invalid expiry dates.

#2 is certainly correct.  If the representation was the simpler "number of
days since time x", then the calculation would have been simply to add 365,
and in a leap year the user would be cheated out of one day, rather than an
illegal date created.

In the same issue, Mark Brader writes:

>All right now -- how many people reading this *haven't yet realized* that
>their watches have to be set back 1 day, ...

This brings up another interesting issue.  Many programs assume that time
goes forward.  For example, documentation for the Amiga says that this is
guaranteed and that programs should not move the time backwards.  At a place
I work for we have networked microcomputers running a database program in
which the central database is updated nightly, and the update program
assumes it is run every day and that all un-updated entries were created
today.  Setting the date backwards between updates would have caused
problems.  Fortunately we realized that the problem existed.

ajr <flaps@dgp.toronto.edu>


More on Bank ATMs and checking your statements

Eric Herrmann <pixar!banzai@ucbvax.Berkeley.EDU>
Mon, 7 Mar 88 13:53:49 PST
I would like to contribute yet another anecdote about the sometimes bizarre
and arbitrary world of electronic banking, which happened maybe 3 months ago.

After receiving my bank statement for the month, I took all the ATM receipts I
had accumulated and proceeded to balance my checkbook.  All was well except I
saw a $60 withdrawal from a Gibraltar Savings branch (linked by the Star
system to my bank) on the same day that I withdrew $40 from my Great Western
machine (about two blocks distant).  I had no receipt for this, and I couldn't
remember withdrawing the money, nor could I conceive why I would withdraw $40
and then withdraw $60 the same day two blocks away, but it occurred to me that
I couldn't prove anything, so I decided to eat the $60 loss.

About a month later, I received a form from my branch bank explaining that a
$60 withdrawal had been mistakenly posted to my account, and that the amount
had been restored.  The explanation was hand-written, but did not explain who
posted the transaction, why it was posted, or how the mistake was discovered.

I would agree with David Segal that good record-keeping is necessary as a
check on technology.  In this case, had the bank not confirmed and reversed
the error, I would have had no recourse to recover the money.  Thankfully, all
I lost was a month's worth of interest.  The problem was not compounded, I
suppose.

Please report problems with the web pages to the maintainer

Top