risks@CSL.SRI.COM (RISKS Forum) (04/09/91)
RISKS-LIST: RISKS-FORUM Digest Monday 8 April 1991 Volume 11 : Issue 42
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Now the police can find you anywhere in town! (S. Spenser Aden)
Re: Automatic Vehicle Identification (was driving and privacy) (Brinton Cooper)
UPS to collect electronic signatures? (Dwight D. McKay)
Software fault in aircraft navigation systems (Steve Bellovin)
Smiths Industries 737-400 LCD display (Robert Dorsett)
UPC Hiccup and human error (Wayne Gibson)
A `security device' that isn't (Andrew Koenig)
Re: E-mail role in LA cop probe (Henry Spencer)
Re: Computer Ballot Tally (B.J. Herbison, Erik Nilsson)
Re: Tricky application of Caller ID (Randall Davis)
The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive
"Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For
vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
----------------------------------------------------------------------
Date: Sun, 7 Apr 1991 21:41:40 CDT
Subject: Now the police can find you anywhere in town!
From: ADEN@vf.jsc.nasa.gov
On David Horowitz' consumer advocate show _FIGHT_BACK_ this Saturday, they
"previewed" a product that's in the prototype stage called (something to the
effect of) TELETRACE. This product is an antitheft device for your car. You
will pay something on the order of $600 initially, then a modest monthly fee,
and your car, with the TELETRACE device, can be traced anywhere in the zone of
control of your police department. Polling sites are set up around the
perimeter of your city police's area of control, and these sites will receive
transmissions from your car. By monitoring strength and angle of the signal
(their claim, not mine), they can "pinpoint" your car.
The idea, of course, is that if your car in stolen, the police can find it.
But there's an added "feature" ... you don't have to call the police to
tell them it's stolen ... the car can be armed so that as soon as it's
broken into, the police start to monitor it. Nifty, huh.
I suppose the readers of RISKS can spot the problems here ... from Big Brother
complexes to inadvertant arrest when you steal your own car :-). Personally,
I found it all terribly amusing, but I wouldn't buy it.
S. Spenser Aden -- Lockheed Engineering and Sciences Co. -- (713) 483-2028
NASA -- Johnson Space Center, Houston -- Flight Data and Evaluation Office
------------------------------
Date: Sun, 7 Apr 91 20:54:00 EDT
From: Brinton Cooper <abc@BRL.MIL>
Subject: Re: Automatic Vehicle Identification (Ravin, driving and privacy)
Risky computer practices seem to be accelerating faster than sane people can
react to them. However, this one seems to be on the wrong track. Cars don't
get speeding tickets; people get speeding tickets. In Maryland, a speeding
ticket is actually a summons to District Court sitting as Traffic Court. Such
a citation would most likely be issued, if at all, to the owner of the vehicle.
This being a non-civil case, however, the State bears the burden of proving
that the owner was actually driving the vehicle. The owner need not testify in
her/his own behalf! While this is likely to be a nuisance for the first few
victims, no sane court is likely to uphold the charge.
It seems that our Risks discussions speak to two communities: we speak to one
another as computer professionals and we speak to the public at large. In the
former case, we ponder the correct and proper use of computers. In the latter,
we'll increasingly have to invoke the tools of jurisprudence to overcome
improper use.
_Brint
------------------------------
Date: Fri, 5 Apr 1991 14:32:35 -0500 (EST)
From: "Dwight D. McKay" <mckay@ecn.purdue.edu>
Subject: UPS to collect electronic signatures?
Having just received a delivery, I am reminded of a small article in last
week's Wall Street Journal. It described a new computer system United Parcel
Service will be introducing which has some serious risks associated with it.
UPS plans to field a large number of the new pen-based computers as
replacements for the ubiquitous UPS clipboard. When you receive a package
you'll sign for it on the pen-based computer. Each evening the delivery person
will drop off his "pad" which will upload the days signatures to UPS's computer
network. With in a matter of a few weeks they could have a sizable percentage
of population's signatures in digital form.
Does anyone know more about this system? What sort of controls will
they have in place for securing the collected signatures?
--Dwight D. McKay, Purdue University, Engineering Computer Network
(317) 494-3561 ...rutgers!pur-ee!mckay
------------------------------
Date: Mon, 08 Apr 91 20:14:43 EDT
From: smb@ulysses.att.com
Subject: Software fault in aircraft navigation systems
The FAA has informed airlines that aircraft equipped with certain models of the
``Honeywell Flight Management System 1 million word database'' may fall prey to
software problems. Apparently, one of the navigation systems -- the
non-directional beacon landing approach system -- is buggy and can display the
wrong course. Planes affected include the 747-400, the 757, the 767, and the
MD-11.
Navigation system software is updated monthly; future release will omit that
code until the FAA approves a bug fix.
--Steve Bellovin
------------------------------
Date: Sun, 7 Apr 91 17:29:59 CDT
From: rdd@cactus.org (Robert Dorsett)
Subject: Smiths Industries 737-400 LCD display
RISKS readers may recall some concerns over the Smiths Industries LCD-based
engine instrumentation, which was introduced on the Boeing 737-400 in 1988
(advertisements appeared in Aviation Week through 1989). This is essentially a
very low-resolution engine instrumentation scheme, utilizing a series of LCD's,
in a circular layout, as trend indicators, with a digital readout. It is now
offered as a retrofit package for the 737-300, and is available as an option on
the 737-300, -400, and -500. It replaces the electromechanical "clock"
displays, which have been in use since 1969. The Smiths Industries display
interface is fundamentally different from those used on the 747-200 and -300
(electromechanical dials or tapes), the 757/767 (CRT-based "moon" displays),
and the 747-400 (CRT "tapes").
Following the crash of a 737-400 at Kegworth, two years ago, the British Air
Accidents Investigation Branch initiated a fairly exhaustive survey of the
human factors of the cockpit (which seemed warranted, since the pilots had
apparently shut down the wrong engine, following an engine emergency).
Here's an interesting (i.e., supports my position :-)) article from a
recent FLIGHT INTERNATIONAL, March 6, 1991. Note that many of the issues
raised have been discussed on the net, and have appeared in numerous reports
in real life, yet no action ever seems to be taken...
UK AAIB SLAMS 737-400 DISPLAYS, by David Learmount.
"Tests have revealed that the layout and type of engine instruments on board
the British Midland Boeing 737-400 which crashed at Kegworth in 1989 were the
worst possible combination by a considerable margin, says Ken Smart, chief
investigator of the UK Department of Transport's Air Accidents Investigation
Branch (AAIB).
"The liquid-crystal displays and their layout were cited as factors in the
737 crew shutting down teh wrong engine. The findings follow UK laboratory
tests, Smart otld a UK Parliamentary Advisory Council for Transport Safety
meeting in London on 26 February.
"AAIB accident investigator Ed Trimble, concerned that there are no national or
international standards for testing instrument effectiveness before operation,
saked why tests had not been carried out before--his questions prompted Boeing
to admit that it has still not modified either the layout or display type in
its 737-400's. Some airlines have reverted to electromechanical instruments in
new 737's.
"Smart points out that the British and US armies have a program called
'Manprint' to test the user-friendliness and operational efficiency of
equipment design choices. He says: 'It is long overdue that the position of
the crew in the system should be considered. It is inevitable that its role,
if things keep going the way they are, will be reduced purely to that of
monitor, a role in which man is not effective.'
"International speakers at the conference claimed that 'glass cockpit' design
induces errors as a result of being insufficiently tested before going into
service--eventually resulting in a serious accident.
"Airlinr manufacturers, accident investigators, human-factors specialists and
airline pilots believe unanimously that today's automated cockpits, which
present the pilot with huge quantities of information on 'untested' displays,
are not designed to keep the pilot 'in the control loop.' Future avionics and
cockpit designs must bring the pilot back into the loop, says Boeing's chief
flightdeck engineer, Del Fadden, making clear that [text omitted in
original--another RISK of electronic publishing systems :-)] intends to do
this.
"The US National Transportation Safety Board's (NTSB) chief accident
investigator Robert MacIntosh told the 'Pilot error in perspective' conference
that although '...glass cockpit aircraft have been remarkably accident-free ...
the NTSB is trying to anticipate what kind of accidents there might be [in
them].'
"Smart revealed that the results of a major line-pilot opinion survey 'Human
factors on the advanced flightdeck'--to be presented by the Confidential Human
Factors Incident Report Programme, showed that pilots are seriously concerned
at the degradation of flying skills automation causes." (sic)
Robert Dorsett UUCP: ...cs.utexas.edu!peyote.cactus.org!rdd
------------------------------
Date: Sat, 6 Apr 91 12:44:26 -0600
From: wgibson@capstan.convex.com (Wayne Gibson)
Subject: UPC Hiccup and human error
I was at the grocery store and spotted 12-pack coke in cans for $2.50. Being a
programmer I could not pass this up and got 4 12-packs. At the checkout
counter (UPC scanner) the girl took the first 12-pack and ran it over the
scanner 4 times. With everything else included the total was $75.68. Since I
had a couple of prescription medicines I thought this was high but not
rediculus. So after paying she hands me the receipt and the first four lines
look like this:
BBS DIET COKE 12 25.00
BBS DIET COKE 12 2.50
BBS DIET COKE 12 2.50
BBS DIET COKE 12 2.50
Now remember she used the exact same carton all four times!! I point out that
this doesn't look right. She agrees but since I've already paid she's
powerless to do anything about it; I need to go to the service desk. OK, fine.
It's right there ten steps away. I have this awful headache and just want to
get home and take my prescriptions, so I'm not paying close attention. Well,
the "assistant manager" working at the service desk goes, "Oh, that's terrible.
Here let me get you a refund. Let's see... 25.00 minus 2.50. I owe you $23.50
plus tax." With my headache I didn't even notice until I got home.
She can't add and subtract. But she also showed no concern that the UPC system
might do this again. When I brought this up she just said that she hadn't seen
it before a was sure it was just a "glitch".
-- Wayne
[I have been generally not too enthusiastic about including the scads of
incremental-experiential sagas that are currently pending consideration
in the RISKS queueueueueueue, but this one slips through... PGN]
------------------------------
Date: Sat, 6 Apr 91 22:02:21 EST
From: henry@zoo.toronto.edu
Subject: Re: E-mail role in LA cop probe (PGN, RISKS-11.37)
> ... essentially any message can be spoofed, tampered with, or destroyed
> altogether, given suitable system access...
The same is true, of course, of recorded voice. Again, the analogy seems good,
and the decision to accord the same status a sensible one.
Henry Spencer at U of Toronto Zoology utzoo!henry
------------------------------
Date: Mon, 8 Apr 91 14:28:08 PDT
From: "B.J. 08-Apr-1991 1625" <herbison@ultra.enet.dec.com>
Subject: Re: Computer Ballot Tally (Richard Wexelblat, RISKS-11.38)
> Question: is this felt to be a reasonable method?
I don't feel the method is reasonable. It *might* have been
reasonable before you published it, but now that you have
provided the information needed to cook the vote and avoid
detection--just modify the electronic vote counter so it is
accurate until the ballot count is larger than 2% of the
expected returns and does anything it wants after that point.
B.J.
------------------------------
Date: Mon, 8 Apr 91 20:20:38 EDT
From: ark@research.att.com
Subject: A `security device' that isn't.
I received a catalog in the mail recently that among other things advertised a
device to `stop people from making expensive 900 calls from your phone.' It
consisted of a little box with a lock that clamps onto the back of the phone.
As far as I can tell from the picture in the catalog, it has a modular jack in
it, into which you plug the cord coming from the wall. It also has about a
2-inch cable coming out of it with a modular plug at the end, which you plug
into the telepone.
I wonder how many people will order these things, not realizing that they can
be defeated in about two seconds? For that matter, I wonder how hard it is to
pick the lock?
--Andrew Koenig ark@europa.att.com
------------------------------
Date: 08 Apr 91 17:12:04 PDT (Mon)
From: erikn@tekcae.cax.tek.com
Subject: Re: Computer Ballot Tally (Richard Wexelblat, RISKS-11.38)
> is this felt to be a reasonable method?
Controls on a vote counting system, like controls on any system, can be
reasonable only in relation to the types of threats that are bring controlled
against.
Broadly, for vote counting, there are two threats:
- someone fixes the election (fraud)
- something goes inadvertently wrong (error)
In each case, the reported results won't match the true results.
Terminology:
results: the number of votes each candidate and measure received
outcome: who won, which measures passed and which failed.
reported: what the counting system claims happened
true: what each voter intended to do
The probability that the reported results will perfectly match the true results
will never be 100%. The probability that the reported outcome will match the
true outcome must be very high, even if the race is arbitrarily close.
Back to the question. If the ballots have already been mailed, it's too late
to do much about fraud. For next time, a few issues you might want to think
about for both fraud and error are:
- how is ballot stock controlled? Are ballots numbered? Are secrecy
envelopes numbered? How are both secrecy and security maintained?
- how is the mailing list maintained? Are you sure that everyone one the
mailing list had a ballot mailed to their address of record? Who has access
to the official mailing list? How many days before the election must a
member join to be eligible to vote? Is this the day you take your pull from
the mailing list?
- is the ballot designed in such a way that all voters will be reasonably able
to follow the instructions and vote their choice, with equipment they will
have at the address the ballot is mailed to? Don't laugh, I'm not sure that
this is true for all U.S. elections. It sounds like you're using some sort
of markable form. If it's a form where you have to punch little squares
out, I'm not sure the manufacturer recommends those for mail voting. If
it's a form where you mark a square, what kind of pencil or pen are you
assuming your voter has?
It's best to think out the whole process IN DETAIL before you even send out the
ballots. Perhaps you have, but I can't tell from your posting. I have a few
questions:
> Before the Validators get there, the company has opened any ballots with
How are the validators chosen and trained? Who is "the company"? What are
they doing with your ballots? Why are they doing anything with them while you
aren't there? Remember, security is trust with a paper trail.
> Any that fail are put aside.
For what reasons would a ballot be failed? Someone intended to vote with that
ballot, it is your responsibility to count it, if it can be done so
unambiguously, even if a particular piece of hardware can't deal with it.
BTW, you need to count the ballots that failed, too. In a mail election, it is
difficult to account for every ballot, but you need to get reasonably close.
Call a random sample of the people you sent ballots to, but didn't get one
from, to see if they actually got their ballot. Just an idea.
A few more comments:
> We then select at random about 1% of the "passed" group and tally them
This is too low, and shouldn't be a constant. There are formulas for
calculating how many ballots you need to recount, to reach a certain confidence
that no undetected fraud or error of certain types has been reached. I can dig
some of them out, if you're interested, but all of them share the property
that, as a race approaches a dead heat, the percentage of ballots you need to
recount approaches 100%.
> (No machine discrepancy has yet been discovered; don't know what to do if one
> occurs)
Either you haven't counted many ballots, the errors aren't being caught, or you
aren't hearing about the errors that are caught. The ballot counting systems
I've seen out there just aren't that reliable. A big number of "failed"
ballots is a good sign that your system is flakey.
For machine count systems, a failed ballot usually means that the ballot is
marginal in some way. Maybe it's dirty, or a mark is outside a line, or the
ballot was cut slightly narrow. Maybe there was a power glitch while the
ballot was read. In this last case, the failure has nothing to do with the
ballot, so I'm sure this is what you'd call a "machine discrepancy." For
failures that do have something to do with the ballot, they all exhibit a
transition zone, so that a ballot that is a little dirty will read OK 40% of
the time, and fail 60% of the time. A little dirtier, and it reads bad 80% of
the time. So machine discrepancies are inevitable, and fairly common.
However, machine discrepancies aren't the voter's problem, your duty is to
determine voter intent if it is possible to do so.
I can see problems with your recount method, because it doesn't verify anything
except that the reader is working OK while you happen to be doing the recount.
You might argue that you are validating the software that does the counting,
but only for the volume of cards in the recount, only if you are sure the
program hasn't changed since the count, and only if you aren't worried about
fraud. You don't know if the counters were zero when the count started. You
don't know whether ballots were intentionally or inadvertently counted twice,
or not at all,
The preferred method is to subdivide the ballots into groups, called precincts,
then count each precinct separately, and sum the subtotals. Each group needs
an anonymous, yet deterministic method of group assignment, such as a number on
the ballot. You might want to think about zipcodes. As I recall, your recount
work is minimized if all groups are approximately the same size, and the number
of groups is about the square root of the number of ballots. It depends on how
expensive each operation is, some people believe that there is never a reason
to have more than about 1000 precincts.
If an election is worth something, someone may try to steal it. It it isn't
worth anything, someone may not take it seriously enough to count it correctly.
> We then open all unsigned ballots. If a signature inside, manually add
Why can the voter sign one of two places? Why wasn't this designed out?
We could get into vote counting software issues, but that's another huge area.
Your responsibility is to not only correctly count the election, but to be able
to demonstrate that you counted the election correctly. This requires careful
documentation at each step of the process, and opens up another huge area that
I won't get into.
Conducting a trustably accurate election is difficult. Ask yourself how much
accuracy you need, then design a system to give you that accuracy for a
reasonable amount of money. For elections that matter at all, the accuracy
needs to be pretty high. For small elections, say only a few thousand ballots,
it is often cheaper to get an accurate count by hand.
Erik Nilsson, CPSR Vote-Counting Project Leader
erikn@tekcae.cax.tek.com (503)690-8350 690-9292[fax]
------------------------------
Date: Fri, 5 Apr 91 14:50:40 est
From: davis@ai.mit.edu (Randall Davis)
Subject: Re: Tricky application of Caller ID (Johnson, RISKS-11.38)
> Does anyone have any documentation on this supposedly-true story?
Consider the scenario for a moment and imagine, say, 10,000 kids in the
audience actually do what they're told. You've got 10,000 phones dialing the
same number simultaneously. How many of those calls do you think will
actually get through?
Sounds like a typical urban legend and a very ineffective way to get a sizable
mailing list. They'd be much better off with the coupon in the paper trick.
I strongly suspect that what Gary said was of the form ``What if...,'' and it's
now being repeated as ``He said that...'' I tried calling him here at MIT to
find out more, but his answering machine says he's in Belgium for the year.
[Lots of other folks commented on this one also, including Jerry Hollombe.
PGN]
------------------------------
End of RISKS-FORUM Digest 11.42
************************