Subject: RISKS DIGEST 13.82

Subject: RISKS DIGEST 13.82
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Friday 25 September 1992 Volume 13 : Issue 82

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: [CLEAN-UP OF SOME BACKLOG, A FEW MARGINAL. SLOWDOWN AHEAD.]
Police files conference (Nigel Allen)
Electronic mail confusion (Stewart T. Fleming)
Duplicate Account Names (Martin Smith)
Digitizing art (John Sullivan)
Re: Airliners playing chicken (Rogier Wolff, Leslie J. Somos, Larry Seiler,
Marc Horowitz)
Re: Airplane chicken, scanning addresses, Sneakers (John Sullivan)
Re: Postal service privacy RISK (Kraig R. Meyer, Gene LeDuc)
Re: Bounced cheque libel (Peter J. Scott)
Re: Computerized warrant systems & mobile data terminals (Michael G Kielsky)
Re: Arrest warrants / Datamation (Lars Henrik Mathiesen, Bob Frankston,
Cristobal Pedregal Martin, Geoff Kuenning)

The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with relevant, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. REQUESTS please to [email protected].

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 13, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

For information regarding delivery of RISKS by FAX, phone 310-455-9300
(or send FAX to RISKS at 310-455-2364, or EMail to [email protected]).

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: Tue, 22 Sep 1992 20:00:00 -0400
From: Nigel Allen <[email protected]>
Subject: Police files conference

Here is a press release from the U.S. Department of Justice.
National Criminal Justice Information Conference in New Orleans
To: City and Assignment desks
Contact: Stu Smith of the Office of Justice Programs,
U.S. Department of Justice, 202-307-0784 or
301-983-9354 (after hours)

WASHINGTON, Sept. 23 -- A national conference on federal-state criminal
justice information sharing will be held from Wednesday, Sept. 23, through
Saturday, Sept. 26, in New Orleans, the Department of Justice announced today.
Jointly sponsored by the Bureau of Justice Statistics (BJS) and the Justice
Research and Statistics Association (JRSA), the conference participants will
discuss "Federal and State Information Sharing to Effectively Combat Crime and
Ensure Justice."
Specific topics that will be aired include "New Measures in the Criminal
Justice System," "'Weed and Seed' and New Drug and Crime Prevention
Initiatives," "Challenges and Reforms to the Justice System in the 90s," "Uses
of Incident-based Reporting Systems," "Recent Developments in Criminal History
Improvements" and various research issues in corrections, prosecution and law
enforcement. Among the approximately 250 people expected to attend will be
officials from state and local government and various federal agencies as well
as leading criminal justice researchers and scholars. Other participants will
be the directors of State Statistical Analysis Centers (SACs) and other
members, associate members and guests of JRSA.
BJS has provided funding to state justice statistics and information systems
through a network of SACs since 1972. There are currently SACs in 48 states,
the District of Columbia, Puerto Rico, the Virgin Islands, and the Northern
Mariana Islands. The SACs provide a wealth of data about crime and the
operation of the criminal justice system to state and local governments,
legislatures, and Attorneys General for policy analysis and planning purposes.
This year is the 20th anniversary of the SAC program. It also marks the
beginning of a new initiative to establish a truly national system of federal,
state and local government information-sharing and readily accessible data
bases.
Additional information about BJS programs and publications may be obtained
from the Bureau of Justice Statistics Clearinghouse, Box 6000, Rockville, Md.
20850. The telephone number is 800-732-3277.

Canada Remote Systems - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044

------------------------------

Date: Thu, 24 Sep 92 16:27:17 +0100
From: "Stewart T. Fleming" <[email protected]>
Subject: Electronic mail confusion

I wasn't going to contribute this until I read David Paschich's contribution
(Wed, 16 Sep 1992) concerning potential confusion of users on electronic
networks.

Working within a computer-oriented university department, a lot of internal
work (memos, reminders etc) gets distributed by e-mail. Such distribution
lists exist for staff, postgraduate students and so on. This afternoon, a
postgrad. student was surprised to receive complaints from postgraduates at a
neighbouring institution about an e-mail message he had sent for internal
distribution.

What had happened was that an electronic mail address had become truncated and
passed through the smart address matching path. None of the machines on that
path flagged the address as invalid and the mail was sent on up the chain.
When it reached the other institution, it was distributed to their
postgraduates.

This incident illustrates the potential for embarrassing disclosures,
particularly in view of two results from a recent e-mail survey we carried out:

Q: Have you sent or received confidential/sensitive information by
electronic mail ?
Yes: 75%

Q: Was the material encrypted or protected in any way ?
No: 91%

Do you know where your e-mail messages are ?
STF

[email protected] or [email protected] or ...uknet!cs.hw.ac.uk!sfleming

------------------------------

Date: Thu, 24 Sep 1992 08:49:21 +0100
From: msmith <[email protected]>
Subject: Duplicate Account Names (was Phone Numbers In Popular Entertainment)

David Paschich writes in Risks 13.81 about one of the risks of getting account
names mixed up, the fact that you could inherit someone's reputation (good or
bad).

While at University I came across another aspect of this problem. When people
left their accounts were put on tape and deleted. I have a fairly common name
(ask Douglas Adams) and there was someone in the year above me also called
Martin Smith. Account names were normally first name and initial of surname but
their account wasn't called MartinS, presumably because there'd been a name
clash in the past. Thus I was known as MartinS.

I came back from the summer holiday and guess which account had been deleted?

Things then became even more confusing when I went to get my files back. There
was *another* Martin S* (the surname escapes me) just arrived in the new intake
who had already been given my old account name. My account had to be renamed to
MartinSm.

I can't help wondering who got deleted when I left.

(not necessarily THE) Martin Smith

------------------------------

Date: Tue, 22 Sep 92 12:39:37 CDT
From: [email protected]
Subject: Digitizing art

The Economist (Aug 15) reports that the National Galleries in both Washington
and London have plans to digitally record images of all their paintings,
because digital images "last for ever". London hopes to scan their pictures
"repeatedly over time ... to track how their colours change": "Since human
colour memory is poor, and photographs change colour themselves, the only way
to do this is by using a computer."

I have trouble here dealing with image files I created a couple of years ago:
we have new hardware, software, and file formats. I have all but given up hope
that colors will look similar on the screen, when printed, and when scanned in.
I hope the museums will give careful thought to such problems.

-John Sullivan, The Geometry Center, University of Minnesota

------------------------------

Date: Thu, 24 Sep 1992 12:19:50 GMT
From: [email protected] (Rogier Wolff)
Subject: Re: Airliners playing chicken

Last time I heard about this incident (Here on comp.risks I believe) it was
told that _both_ "squats" had failed. I.e. there where considerations towards
reliability and safety of the devices.

An interesting question pops up now. Should these devices be wired in an "and"
or in an "or" fashion? I guess that it would be safest to wire them in such a
way that when they agree, they can override the pilot, but if they disagree,
the pilot should be able to take responsibility.
Roger

EMail: [email protected] ** Tel +31-15-783644 or +31-15-142371

------------------------------

Date: Thu, 24 Sep 92 10:27:48 -0400
From: [email protected] (Leslie J. Somos)
Subject: Re: Airliners playing chicken (RISKS-13.81)

I know nothing about planes.

I can understand preventing deployment of spoilers or thrust reversers while in
the air, but I don't understand preventing brake application.

Leslie J. Somos [email protected]

------------------------------

Date: Fri, 25 Sep 92 09:09:53 -0700
From: [email protected] (LARRY SEILER, DTN225-4077, HL2-1/J12)
Subject: Safety interlocks that fail

re "Airliners playing chicken" from RISKS digest 13.81:

I agree that it is better to have an occasional accident due to a safety
interlock system that fails than to have more accidents due to people
accidentally doing fatal things like engaging the thrust reversers or deploying
the spoilers while the plane is in the air.

However, the better solution is to have an emergency override system that is
simple enough to engage quickly, that cannot easily be engaged by accident and
that warns that it is engaged. And, of course, there must be severe penalties
for anyone who uses it except under emergency conditions.

To use a computer analogy, there can be serious accidents if everyone has
superuser privileges enabled all the time. But there are also problems if you
cannot get privileges when you really need them -- like at 9pm when no one is
around and you just have to read that protected file!
Larry

------------------------------

Date: Wed, 23 Sep 92 22:54:47 EDT
From: Marc Horowitz <[email protected]>
Subject: Re: Airliners playing chicken

Or, we can realize that failures and "impossible" circumstances do occur, and
install overrides so the pilot can tell the system it's wrong. People deal
with unforeseen circumstances better than computers.
Marc
------------------------------

Date: Thu, 24 Sep 92 16:04:47 CDT
From: [email protected]
Subject: Airplane chicken, scanning addresses, Sneakers

A few quick comments on items in RISKS-13.81:

David Wittenberg reports on airliners playing chicken, and suggests that
we "not panic when a safety device does cause damage" even though
switches "used in all sorts of safety devices ... will eventually fail".
I'd like to see an overridable switch: if the pilot engages the brakes
or thrust reversers, and the computer thinks the plane is in the air, it
shouldn't just quietly fail to engage them, but should tell the pilot what
is going on, and leave some way to override the ground/flight switch.

Daniel Burstein is concerned about the post office's plans to send images of
hand-written envelopes via computer to remote sorting sites, and the
possibility that addresses could be stored in a database. Of course
letters with typed addresses are already sorted by machines with OCR
software, so these addresses are even easier to store. Overnight delivery
services must enter each item sent into some kind of computerized tracking
and billing system: who knows if any of them have thought to keep a
database indexed by sender/recipient pairs?

There has been much discussion of the real phone number used in 'Sneakers'
for the NSA agent. The movie also shows phone numbers being typed in on a
numeric keypad (when they first test the decoder), and at least one
instance where touchtones are audible. I didn't try to identify any of
these, but I'm sure someone will.

-John Sullivan, The Geometry Center, Univ. of Minn. [email protected]

------------------------------

Date: Thu, 24 Sep 92 14:28:07 PDT
From: [email protected]
Subject: Re: postal service privacy RISK (RISKS-13.81)

In RISKS-13.81, Daniel Burstein relays US Postal Service plans to use remote
video technology to allow remote sorting of mail, and notes: "given OCR
technology, it would be quite trivial to have EVERY piece of correspondence
going through the USPS scanned, and a data list of who sent what to whom could
be generated."

I want to point out several issues related to this article:

1. The RISK of stored communication matrices--having a record of who
communicates with whom--is perhaps simplified, but certainly not
created by the use of computer sorting technologies. In small town
days, the local postman and telephone operator knew exactly who
communicated with whom.

2. OCR Technology is already very widely used by the USPS. If you
place a letter in a mailbox that is designated "for envelopes with
typed and printed addresses only," that envelope is read by an OCR and
a bar code is put on to the envelope corresponding to the zip code.
(Try sending yourself a letter in this manner!)

3. There was a front-page article in the LA Times (Sunday, 20 Sept?) that
describes how firms in general are using remote technologies to move jobs to
remote locations. It's generally a benefit to both the company and the
workers. The company gets better workers and lower costs. The workers are
happier because their wages go a lot further in the remote geographic location,
allowing a better standard of living. Why not let workers in Vermont sort mail
that is going through a plant in New York City?

------------------------------

Date: Fri, 25 Sep 92 07:33:53 PDT
From: [email protected] (LCDR Gene LeDuc)
Subject: Re: postal service privacy RISK (RISKS-13.81)

In RISKS-13.81 Daniel Burstein wrote about Remote Video Encoding in use by the
USPS, a procedure involving scanning a letter and sending the envelope's image
to a remote site to be ZIP and barcode processed. [...]

Those who fear this type of data collection are certainly under no obligation
to include a return address on any envelope. In this case (for once!), the
default in mailing a letter is "no return address" and one must override this
default by putting one on the envelope.
-gene-

Gene LeDuc ([email protected]), Navy Personnel R & D Center,
San Diego, CA 92152-6800

------------------------------

Date: Wed, 23 Sep 92 16:53:44 -0700
From: Peter J. Scott <[email protected]>
Subject: Re: Bounced cheque libel

Terry Gerritsen quotes The Lawyers Weekly as saying that the 9-year libel
action, ultimately successful, of a company against Lloyd's bank for
erroneously returning cheques marked "Refer to drawer", is believed to be the
first of its kind to reach British courts this century. Actually I am aware of
a case identical in all pertinent respects, and while I do not remember the
date I am reasonably certain it was within this century. I remember finding it
in a search of important libel decisions when I was in the UK and it stuck in
my mind. Given such a clear precedent, it's appalling that it took nine years
to come to a decision.

Peter J. Scott, Member of Technical Staff | [email protected]
Jet Propulsion Laboratory, NASA/Caltech | SPAN: GROUCH::PJS

------------------------------

Date: Thu, 24 Sep 92 10:47:38 MST
From: [email protected] (MICHAEL G KIELSKY)
Subject: Re: Computerized warrant systems & mobile data terminals

Mobile data terminals (MDT's) in police cars are nothing new around here
(Phoenix, AZ area), and have been in use for years. My experience has ranged
from working for an organization which serviced these devices (and thus using
them in testing), thoroughly studying the computer system that works in the
background, to accompanying on-duty police officers from various departments on
many ride-alongs, and viewing the system in action. These systems are in use
with virtually every police agency in the Phoenix area, as well as the
Department of Public Safety (Highway Patrol), but not with the sheriff's
office.

The systems are nothing more than data terminals on a radio network. Data
traffic is NOT encrypted (risks obvious), and converting an installed base to
handle encryption is not feasible for most departments. Log on practices vary,
with identification information ranging from officer ID, to shift/beat code,
with usually short (and few different) passwords. The "base computer" is
connected to several databases, including the National Crime Information
Computer (NCIC), the Arizona Crime Information Computer (ACIC), and motor
vehicle records. Information retrievable includes driving license records
(including traffic violation history), vehicle registration records (including
vehicle description), arrest warrant information, stolen motor vehicle records,
stolen firearm records, etc. Data retrieval is notoriously slow during busy
times (Friday & Saturday night), sometimes taking as long as 30 minutes for a
license plate check. Terminal to terminal messaging is possible.
Communication with dispatchers is also possible. All transactions are
recorded/printed.

Accident Risks: A few years ago, the Phoenix Police Department, after
experiencing numerous problems with officer's driving and operating the
terminals at the same time, improved the ergonomics by mounting the terminal
higher and closer to the driver. This way, the drivers eyes are not completely
averted from the road while using the terminal.

Privacy Risks: It is common practice for officers to "run" license plates on
vehicles which they observe, for no reason whatsoever, or for any trivial
reason. Information retrieved via the computer includes name, address, SSN,
and driving license number of the current registered owner, vehicle
identification number, lien holder (usually bank/loan institution), original
lien amount, date vehicle first registered, date registration expires, vehicle
description, and whether the vehicle is stolen. Registration violations are
most commonly found this way. As newer officers (who often are less
techno-phobe) take to the streets, use of the system is increasing.

False Arrest Risks: Arrest warrant information obtained through the computer
(term is "CAPRI Hit") will find the listed individual in handcuffs (i.e.
existence of a computer arrest warrant record is sufficient probable cause for
arrest). Again, we know how infallible information entered into computers is.
These computer warrant records must then be verified against the actual warrant
(on paper), before the arrestee can be arraigned (brought before a judge).
These warrants are stored in filing cabinets at the sheriff's office of the
warrant issuing jurisdiction (here it is the Maricopa County Sheriff's Office,
and I have seen the actual filing cabinets stuffed with warrants). This
process can be slow, since there are hundreds of thousands of outstanding
warrants in these filing cabinets, some going back over half a century.

Michael Kielsky, Arizona Public Service Company, P.O. Box 53999, Phoenix, AZ
85072-3999 602-250-2897 (W) 602-919-0182 (M) ...sunburn!overlord!mkielsky

------------------------------

Date: Fri, 25 Sep 1992 12:37:16 GMT
From: [email protected] (Lars Henrik Mathiesen)
Subject: Re: Arrest Warrants (Weinstein, RISKS-13.81)

Lauren Weinstein writes about the classic treatment of the "computer-
induced" nightmare through "minor" errors:

> (A clue: at the end of the piece, the governor's order to stop the
> execution is accidentally misrouted...)

Actually, the order was to be sent by a special urgent-mail system --- but it
was held back because the Governor didn't get it authorized by his supervisor
.. (I think I read this short story in a science-fiction collection named _The
Astounding-Analog Reader_.)

Lars Mathiesen (U of Copenhagen CS Dep) <[email protected]> (Humour NOT marked)

------------------------------

Date: Thu 24 Sep 1992 11:39 -0400
From: [email protected]
Subject: Re: A simpler risk of computerized warrant systems (Karn, RISKS-13.80)

Consumer car phones are already shipping with voice dialing. Extending that
to replacing the keyboard by speaking letters as opposed to something as
fancy as full word recognition would be straightforward. Given not only the
safety risk but the awkwardness of using a keyboard in a car along with the
compelling value of using the device while driving, I'd be surprised if voice
is not added very soon.

Let's start the timer going and see how long it takes to get the technology
deployed.

------------------------------

Date: Thu, 24 Sep 92 20:34 CDT
From: [email protected] (Steve Nuchia)
Subject: Re: Arrest Warrants (Davis, RISKS-13.81)

>Given the alleged facts here the amount in question must have been
>on the order of $3;

An incident with similar background but (so far) less outrageous conclusion
happened to me. Early in my consultancy I had my business checking account at
a small bank. Through a bookkeeping error on my part I bounced a check. The
check was small, the account was small, the error was small and the overdraft
was small.

In what I hope and believe was a complete coincidence, the bank was closed by
federal regulators between the time the check was bounced and the time I
received notice of it. The check was not honored but the overdraft charge ate
up the balance in the account plus a few dollars. Since I couldn't find
anybody who had a clue what was going on I just abandoned the account.

The bank was purchased by Texas Commerce Bank, one of the largest in the area.
For several months they accrued overdraft charges to my old account because it
now had a negative balance. The end result was that they wrote off the account
with about $75 owing and sent me a nice registered letter to the effect that I
had "caused a loss" of $whatever to the bank. The way I see it they made off
with the $12 I had in there when they bought the old bank, but I suspect they
could have one of those stealth arrest warrants issued for me by including my
case on a list of other "losses" and mailing it to the district attorney.

I also managed to spend a couple of hours in jail once due to a parking ticket
that was over five years old. It was legitimate and once I was told about it I
vaguely remembered having gotten it, but I had completely forgotten it. The
arresting officer could not tell me what I was being charged with at the time
of the arrest, which I found pretty offensive. All he knew was that a warrant
existed.

What I don't understand is why they can't send out letters to people instead of
lying in wait for them and wasting everybody's time. It wasn't like I was
going to flee the country over a parking ticket.

Steve Nuchia South Coast Computing Services, Inc. (713) 661-3301

------------------------------

Date: Thu, 24 Sep 92 9:43:17 EDT
From: pedregal%[email protected]
Subject: Re: A simpler risk of computerized warrant systems (Karn, 13.81)

Phil Karn comments about a computer terminal mounted on San Diego police cars;
these devices can be (and are) used by the driver while in motion. He points
out the safety risks associated with that (typing/reading while driving).

Karn also mentions that "[the police] like to drive around semi-continuously
punching in license plate numbers", i.e., that they check plates in many
situations that are not "only when they really suspect somebody (e.g., during a
stop)".

So there's a change with respect to the previous situation: now the checks on
plates can be (they probably are) stored and can be manipulated much more
easily; more such data is gathered; and, more relevant to RISKS, it can be
easily matched with location, as police cars (will) have devices that
continuously report their location. Of course, if the records exist, they will
eventually be used against someone.

This is yet another instance of a common risk: having more and
richer data changes the possible uses of such data.

Cristobal Pedregal Martin [email protected] (internet)
Computer Science Department UMass / Amherst, MA 01003

------------------------------

Date: Wed, 23 Sep 92 18:11:30 PDT
From: [email protected] (Geoff Kuenning)
Subject: Re: Datamation fiction (Weinstein, RISKS-13.81)

Lauren Weinstein writes:

> The classic treatment of the "computer-induced" nightmare through
> "minor" errors must be the humorous (fictional) piece done by
> "Datamation" in the early 70's.

As I recall, the title of the story was "Computers Don't Argue," and
it was not original with Datamation. I think it appeared first as a
science-fiction short story in the late 60's.

Geoff Kuenning [email protected] uunet!desint!geoff

------------------------------

End of RISKS-FORUM Digest 13.82
************************