Subject: RISKS DIGEST 13.09
REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest  Saturday 1 February 1992  Volume 13 : Issue 09

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

  Contents:
Confusing Telephone System Overload Message (Bruce McCulley)
Re: Airbus A-320 (Helen Trillian Rose, anonymous, Harry Erwin, Joe Morris,
    Dave L. B., James B. Shearer)
Communication between ATC and pilot (Ian Moor)
Another hacking myth (Robert Jenkins)
World Bank Virus [anonymous]
Australian Tax File Numbers (Barry Johnson)
Error in 1099-G Tax Form (William Mihalo)
Computer evidence is Hearsay (Kevin Stock)
The absence of a warranty (Fred Gilham)
Re: A Tale of Risk Avoidance [so far ...] (Rick Smith)
Serious dangers in the Caltrans AVI spec [URGENT for Californians] (Phil Agre)

 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 may be ignored!  Contributions will not be ACKed.  
 The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
 especially .UUCP domain folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.     
 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.
 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: Thu, 30 Jan 92 11:51:03 -0500
From: mcculley@racy.zko.dec.com
Subject: Confusing Telephone System Overload Message

On Tuesday night (1/29/92), after President Bush's State of the Union address I
happened to tune into the CBS television network as they were announcing a
novel poll.  They claimed nothing like it had ever been attempted before, and
it sounded interesting so we stayed with them for awhile, and even tried to
participate.

The basis for the poll was an interactive telephone system set up at a site in
Omaha, Nebraska, with an (800) WATS line to allow toll-free access from
anywhere in the US.  Early in the show CBS announcer Charles Kuralt reported
that the telecommunications center was capable of handling thousands of calls
per minute, "so there should be no problem".  HA!

Participation required a touch-tone phone, so that callers could respond via
keypad entry to the canned questions posed by the automated response system.
Although we live in a rural area with old mechanical switch gear, my phones
all can switch between rotary and touchtone mode, so I could dial up using
pulse mode and then switch to tone for the response.

After watching a few minutes to see what additional explanations were given, I
decided to try accessing the poll.  At the time they seemed to be running at a
couple of thousand calls per minute.  My initial attempt to call them resulted
in a very long dead interval, followed by a message saying "Your call cannot be
completed as dialed, you must supply more digits in the number dialed."

That seemed strange, so I tried redialing several times, more carefully, with
similar results.  Since the map showing calls received was showing nothing from
our area of New England (New Hampshire and Maine were both showing null), I
wondered if there was a problem with the WATS routing or something, that might
have caused the strange error message.  So I called the operator, and when I
started to say I was having trouble dialing an (800) number she immediately
asked if it was the one that had been given on TV.  When I said it was, I was
told that the lines were flooded.

Apparently the volume of calls was either forcing the long-distance system into
some strange failure mode in which it thought more digits were required in the
number being called, or there was a mismatch between the particular error
condition and the error message being used.  I suspect, based on my limited
knowledge of the telephone network, that there may have been some timeout or
connection loss or contention or something that inadvertently truncated the
routing information string, due to the huge volume of calls.

Shortly afterward, with the display showing about 125,000 calls processed, Dan
Rather reported on the air that AT&T was estimating there had been about
7,000,000 call attempts!  Obviously their throughput was a little below the
capacity requirements...

BTW, using redial, I was able to access the number on a subsequent attempt, and
did get my response included in the poll.  At that time they were reporting
about a hundred thousand calls processed.  From the ratio of call attempts
reported by AT&T to calls processed it looked to me like the ratio was upwards
of 70 to 1.  It took me only about ten tries or so, so I guess I was lucky.

The risk seems obvious, experimenting with a novel application in a live
production environment requires some careful system analysis and planning to
avoid unexpected errors.

One thing I'm curious about, wonder what their phone bill was?
                                                               --bruce mcculley

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

Date: Tue, 28 Jan 1992 23:31:25 -0500
From: Helen Trillian Rose <hrose@eff.org>
Subject: Speculation on latest A-320 crash: why? (Joel Upchurch, RISKS-13.08)

 Joel> It might be informative to compare the A-320 accident rates to
 Joel> other planes that have a two man crew, rather than comparing it
 Joel> to planes of similar size that use a three man crew.

OK. We'll do this. 

The Boeing 757. No total hull losses. No incidents *at all*, that I can recall.

The Boeing 767. One total hull loss, due to a problem with the engines (and on
the engines that were least used. The ones in question were the Pratt &
Whitney, while most customers had the GE/SNECMA).

The Boeing 747-400 (though not a 2-engine plane, is the most "technologically
advanced", aside of the A320, with an almost total glass-cockpit) some
incidents, but no hull losses. The 747-400 is particularly interesting because
earlier models had three flight crew members.

The A-320 is about the same vintage as the 747-400, and is newer than the 757
and 767 by a good five plus years.

Helen Trillian Rose <hrose@eff.org> EFF Systems and Networks Admin

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

Date: Tue, 28 Jan 92 12:33:32 XXT
From: [anonymous]
Subject: A320 crash may have been caused by ATC/Pilot miscommunication

... The AT320's fly-by-wire system or glass cockpit ... may not have been
directly involved in the lastest A320 crash.

A U.S. air safety source informs me that initial information suggests that a
miscommunication between Air Traffic Control and the A320's pilot may have been
the primary cause of the accident.  Apparently the A320 was originally on a
landing path to a runway with a fairly rapid descent slope.  Sometime fairly
late in the landing sequence, the pilot was ordered to a different runway by
ATC, but may not have been warned that the new runway would require a different
descent to avoid slamming into a mountain.  The pilot descended at the original
rate and the crash resulted.

Before someone argues that the automated information transmission systems being
planned would have solved this problem, it's worth noting that many are very
concerned that such information systems would deprive pilots of information
being sent to other planes, which they might need to know to avoid collisions
or other problems.  Many accidents have been avoided by pilots who heard ATC
directions being given to *other* pilots (over conventional radios, of course)
and realized that they themselves needed to take evasive action!

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

Date: 29 Jan 92 13:25:27 GMT
From: trwacs!erwin@uunet.uu.net (Harry Erwin)
Subject: Re: Speculation on latest A-320 crash: why?

There is an old story about WWII in the Pacific, where an operations research
team was sent to the combat zone to determine where armor should be added to
the fighters in use. Originally they were going to survey aircraft returning
with battle damage to see where the battle damage was concentrated--the armor
was to be added to those areas. However, an older analyst pointed out that the
armor should be added where there was no battle damage--planes receiving damage
in those areas were not returning.
                                      Harry Erwin  erwin@trwacs.fp.trw.com

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

Date: Thu, 30 Jan 92 11:09:24 -0500
From: Joe Morris <jcmorris@mwunix.mitre.org>
Subject: Re: Another A-320 crash in France (Bennett, RISKS-13.06)

>In RISKS 13.05 Romain Kroes, Secretary General of SPAC is quoted as saying
>"...it has been clear to us that the crews were caught out by cockpit layout"
>
>     Surely this statement implies that there is a problem with training
>rather than the software or the crew

Not necessarily.  Especially in stressful environments, a poorly-designed
cockpit layout can be a disaster waiting to happen.

An aviation example on a smaller scale is the control panel layout of the
flight instruments.  For years there was no standardization of what 
instrument went where, neither between manufacturers or even between 
models.  Only after studies showed that there was a quite significant
safety advantage did the designers agree to the "basic" formation:

    airspeed           artificial        altimeter 
    indicator           horizon

    turn-and-             gyro         vertical speed
  bank indicator         compass         indicator

Prior to the standardization these instruments could be almost anywhere in
the cockpit.  (Of course, we now have the interesting problem of trying to
figure out how to best present the information on integrated displays in
an EFIS (Electronic Flight Information System) environment.)

Another example of poor cockpit design was the way that Beech Aircraft
moved cockpit controls around in different years in some of its airplanes.
In some years the Beech Bonanza airplane put the control for the wing
flaps (which are to be retracted after landing) on the left side of the
cockpit and the gear retraction switch on the right; in other years the
positions were reversed...with the obvious problem of pilots retracting
the landing gear while on the ground.  Beech also had a disconcerting 
habit of not following common industry practice in the order of the
engine controls: where most designers put the controls on the panel
in left-to-right sequence of throttle/prop/mixture, some Beech products
used throttle/mixture/prop.

My point is that while training can teach a pilot about the particular
idiosyncrasies (or idiotsyncrasies) of a particular airplane, a design which is
nonstandard and/or unintuitive and/or misleading can be the trigger for
failures which are eventually blamed on "pilot error".

This does have a direct significance to the normal subject matter of the
RISKS-FORUM: the design of user interfaces in software systems.  In fact, it's
almost exactly the same issue: poorly-designed, or nonstandard, or "slightly"
different interfaces between programs which perform similar functions are one
of the reasons for many of the problems we have in this industry.
                                                                   Joe Morris

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

Date: Sat, 1 Feb 92 15:53:12 GMT-0400
From: dlb@osf.org
Subject: A320 Crash

A couple of comments about topics related to the A320 crash:

Potential of the FAA banning or restricting the A320 for nontechnical reasons
(i.e. politics or advantage to US aircraft manufacturers): I think this is
unlikely for at least two reasons.  First, at least one major US airline
(Northwest) has a significant A320 fleet.  There may be others.  If anything,
the FAA is more beholden to US airlines than it is to US aircraft
manufacturers.  Second, the FAA is has an excellent reputation in safety
matters to consider/defend.  Aviation authorities in many other countries look
to the FAA on aircraft safety matters, and routinely implement FAA safety
directives.  Issuing an unjustified safety directive with significant impact
would do major damage to the FAA's status, influence, reputation, etc.

2-man crew (vs. 3-man) as a major factor.  Highly unlikely.  Virtually all
recently manufactured aircraft (newer 737's, 757's, 767's, 747-400's, MD-80,
MD-11, ... [hope this list is correct]) have two man crews.  None of them have
the crash record of the A320.

On the other hand, I wonder if we're looking at the wrong statistics.  Fatal
aircraft crashes are so few and far between that it's hard (statistically) to
draw reliable inferences from such spotty data.  I'd be much more comfortable
looking at data that included significant failures that could have caused the
aircraft to crash (but the plane didn't due to skill of the crew, luck, etc.).
I'm sure the FAA keeps such numbers, but of course they're not newsworthy
because nobody died, and there aren't any good pictures ...
                                                                 --Dave

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

Date: Thu, 30 Jan 92 18:33:31 EST
From: jbs@watson.ibm.com
Subject: 3 man aircrews

         Joel Upchurch suggests 3 man aircrews will be safer than 2 man crews.
         Studies have shown 1 man police squad cars are safer than 2 man squad
cars.  Nevertheless police feel safer in 2 man cars (which may be part of the
problem).  I suspect something similar may be true of aircrews.
                                                               James B. Shearer

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

Date: Wed, 29 Jan 92 19:35:55 +0000
From: iwm@doc.imperial.ac.uk
Subject: Communication between ATC and pilot

Communication between Air Traffic Control and Pilots is currently verbal and in
English (as a `Universal' language).

An item in a recent BBC radio program mentioned work on a possible replacement.
They played back a recording of a dialogue where neither participant had
English as a first language as a demonstration of misunderstandings that
happen.  The cure was to be a means of transmitting coded messages, presumably
displayed in the pilot's native language, and presumably vice-versa.  The
interviewer asked `why not have the commands transmitted directly to the
plane?', and was reassured that the pilot would have ultimate control.

However  nothing was said  about:

  Error checking, natural language is redundant, but coded messages may not be.

  What happens if the message to be sent was not anticipated by the system
  designer (Elephant on runway ?).

  How the message was displayed: Headup display, voice, or another console
  display
                                       Ian Moor

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

Date: Fri, 31 Jan 92 20:35 GMT
From: Robert Jenkins <rjenkins@cix.compulink.co.uk>
Subject: Another hacking myth

There has been an instructive little flurry about hacking in the British press.
 
It starts with Police Review, 17 January 1992: A columnist, C H Rolph, writes:
"Did you know that there are hackers (i.e., people who make a hobby out of
studying and programming other people's computers, or who get unauthorised
access to computer systems by telephone) making a good living out of `cleaning
up' people's driving licences. A wealthy man with an endorsed licence will pay
a lot to have his file beautified at the Driver and Vehicle Licensing Centre at
Swansea. I'm told that for 100 pounds a point, it is possible to get an
endorsement completely erased, and then apply for and get an unblemished
licence. Or was, until fairly recently."
 
The Times took up this "revelation" and, on 20 January, reported that "an
investigation is under way after claims that computer hackers are wiping
motorists' penalty points from the DVLC computer in Swansea. The hackers are
charging 100 pounds for each penalty point, according to the Police Review".
 
On 31 January, C H Rolph returned to the affair. He referred to the Times story
and said "I didn't quite say that. I said there were allegations that this *had
been* going on. And it turns about that there had certainly been attempts. The
Driver and Vehicle Licencing Centre at Swansea tells me that the story first
appeared in the *Sun* in 1986, and that it was at once jointly investigated and
refuted by the DVLA and Scotland Yard ... "
 
Looks like pretty bad behaviour by C H Rolph (a former senior police officer,
by the way). His original story seems to have had no foundation whatsoever (the
*Sun* is not a serious newspaper), but he is trying to wriggle out of accepting
fault. And the Times doesn't come out of it well, either. Doesn't *anyone*
check out hacking stories, or do journalists prefer urban myth. (I write as a
journ.)
         [This sounds as if an old tale had been warmed over.  See RISKS-2.38,
         8 April 1986, for Brian Randell's contributed item on the alleged DVLC
         hacking activities.  (See also Software Engineering Notes, vol 11, no
         2, April 1986, page 4.  [The reference is WRONG in the RISKS INDEX,
         which appears once again in the January 1992 issue of SEN, pp. 23-32.
         I just noticed that in digging for the original.)  PGN]

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

Date: Recently
From: [anonymous]
Subject: World Bank Virus

The bit about the World Bank virus [Ted Lee, RISKS-12.36, and Software
Engineering Notes, Vol. 16 No. 4 (Oct. 1991) p.17] was actually a bit
overblown.  A few dozen networked PCs did get hit, but it was just one of those
things that came off a diskette of questionable origin.  There was no
`international army of nerds and police experts' required to track it down,
although it did occupy internal staff for several days to clean it out.
Apparently the Bank's efforts to have Time print a correction came to naught.

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

Date:        Wed, 29 Jan 92 10:12:00 EST
From: BARRY JOHNSON <WB15471@ibrdvax1.bitnet>
Subject: Australian Tax File Numbers

Reading the January 1992 `Inside Risks' column in the CACM reminded me of what
seems a very relevant article in "The Australian Computer Journal", Vol. 22 No.
1 (February, 1990) pp. 11-20 [published by the Australian Computer Society
(ACS)]: 'Implications of the tax file number legislation for computer
professionals'.  After years of public resistance against anything like a
Social Security Number, the Australian Government finally opted for a 'tax file
number.'  Although organisations such as employers and banks are expected to
collect this number so that it can be included when submitting information to
the federal tax authorities, there are also VERY strong legislative safeguards:

-   It can ONLY be used for tax-related functions.
-   It must NOT be disclosed to anyone who does not need, nor revealed if
    not immediately relevant.
-   It may NOT be used as a national identification scheme nor for building
    up a database on individuals nor for matching personal information.

After discussing the meaning and implications of the legislation, the article
touches on implementation issues (access control, personnel screening,
communications and operating system security, and professional responsibility)
that relate to the securing of the number.  It discusses in some detail the
choices of including the tax file number in a file/table with other personal
information versus isolating it in a separate file/table.  Interestingly, the
article opens by noting that the legislation is based on privacy principals
espoused by the Organization for Economic Cooperation and Development (OECD).
It might be interesting to know what they are exactly ...  If you would like a
copy of the article and are unable to get it from anywhere else, I would be
glad to send a copy if you can provide an address.  Regards ... BJ 

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

Date: Wed, 29 Jan 92 12:12:53 -0600
From: wmihalo@lucpul.it.luc.edu (William Mihalo)
Subject: Error in 1099-G Tax Form

Last week I received an erroneous form 1099-G from the state of Indiana.  The
form erroneously claimed that I had received a large tax refund from the state.
A call to the local state revenue office revealed that a faulty computer
algorithm had created the problem. Apparently, if you claimed a tax refund or
received a tax deduction, and also filed an estimated tax payment for the first
quarter in 1991, the algorithm >added< the two numbers together rather than
subtracting one from the other.

In my case, the error was compounded by a combination of a misplaced decimal
point and adding the numbers together. The tax rate for Indiana is 0.034. Thus
if you have a $1,000 tax deduction, it reduces your tax liability by $34. The
statement that I received had apparently used 0.34 as the tax rate and added
this to the amount owed and estimated taxes.

The person at the state revenue office said one million people were affected by
the error. But I'm not certain if it's that large. At any rate, don't people
bother to check their software for mistakes before doing a mass mailing? The
last time I received an erroneous 1099 form, I underwent three audits for three
years in a row before the IRS finally recognized the error.
                                                            William E. Mihalo

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

Date: Wed, 29 Jan 92 09:44:38 GMT
From: kstock@gouldfr.encore.fr (Kevin STOCK - MIS (Compta))
Subject: Computer evidence is Hearsay

[ Unfortunately I don't have a citable source for this as I no longer live
  in the UK and so I rely on BBC Radio for this news. ]

Local taxes in the UK were changed a couple of years ago from a system known as
the "Rates", which was based on property values, to a system called the
"Community Charge" (by the Government; most people call it the "Poll Tax")
which is based on the number of adults living at an address. Many people
consider the new system unfair, and a campaigning movement has been set up to
fight against it.

One of the principal attacks has been simply refusing to pay the demands.
Local councils have therefore taken defaulters to court to request orders for
payment. However, the magistrates' courts which should deal with such cases are
refusing to hear them, on the grounds that computer output is hearsay and
therefore not acceptable as evidence.

[ Curiously, in the main criminal courts, computer evidence is acceptable as a
result of specific legislation, but this legislation does not apply to the
lower courts. The government has promised to end this anomaly. ]
                                                                 Kevin Stock

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

Date: Tue, 28 Jan 92 18:57:32 PST
From: quail@csl.sri.com (Fred Gilham)
Subject: The absence of a warranty

My understanding is that if a warranty is not provided, the implied warranty
gives the buyer quite a bit of protection.  Manufacturers supply `limited'
warranties for the very reason of saying how far they are willing to go, and
for how long, to remedy a problem with their product.

An implied warranty, as I understand it, usually says something to the effect
that the thing is supposed to perform as advertised or specified in
instructions that come with it, basically forever.

So, if the manufacturer doesn't supply a warranty, the product had better be
good.
                             -Fred Gilham      

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

Date: Wed, 29 Jan 92 13:18:21 CST
From: smith@SCTC.COM (Rick Smith)
Subject: Re: A Tale of Risk Avoidance [so far ...] (Thorson, RISKS-13.08)

Mark Thorson (mmm@cup.portal.com) responded to a posting by
"Kai-Mikael J\d\d-Aro" <kai@nada.kth.se> in RISKS DIGEST 13.05:

>Tools will always be pushed to their limit, because the limit is actually in
>the programmer and it is the fundamental nature of programmers ...

>Will Kai-Mikael J\d\d-Aro find himself next year creating state diagrams
>with the complexity of a street map of Stockholm ... ?
>This might open a whole new range of computer applications ... but there
>is no reason to believe these systems will be more reliable than the
>smaller systems built before the tool was developed.

We have 2 different classes of tools here, very different. As Mark said,
the shift to (more) automatic programming simply abstracts away certain
technical details in software development. This makes bigger problems 
easier to tackle, but that's not the essential value of formal methods.

I remember Kai-Mikael saying that his workbench provided tests of various state
machine properties; this goes far beyond the rudimentary correctness tests a
compiler might apply (eg type consistency). Thus, the formal methods _do_ give
us more reason to believe in the system's correctness.

If the tool in question simply provides a graphic representation for some
network (streets, whatever) then it isn't contributing much to increased
software reliability. After all, the network's correctness would still depend
on whether the coder sees any errors in it when it is created and manually
reviewed.
                   Rick Smith.      smith@sctc.com     Arden Hills, Minnesota

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

Date: Thu, 30 Jan 92 14:06:58 pst
From: pagre@weber.ucsd.edu (Phil Agre)
Subject: Serious dangers in the Caltrans AVI spec [URGENT for Californians]

I just received the latest revisions to the State of California's proposed spec
for automatic vehicle identification (AVI) equipment.  This is the box that the
state envisages attaching to your car that broadcasts your car's vehicle
identification number (VIN) when pinged by a roadsite transmitter.  The spec is
being developed on the instructions of the state legislature, which is
considering automated systems for collecting tolls.  The spec has been through
a number of revisions.  The latest, dated 17 January 1992, is considerably
different from the others.  It is an irritating document because so little is
explained about how toll collection would actually work, and in particular
whether it would be necessary for every car on the road to have one of these
transmitters.  Many of the new revisions are highly technical in nature, but
some RISKS-relevant trends are clear.

First and most obviously, the proposal no longer contains any language at 
all about privacy or about encryption.  Previous drafts had specified the use
of DES, but this is gone.  In the former sentence "The initial data records
are designed for voluntary implementations of automatic toll collection, 
where security and anonymity are not overriding concerns.", the phrase "where 
... concerns." has now been struck (section 1702.1).  Whereas the former 
document had provided both encrypted and unencrypted versions of the "reader
communications protocol" (section 1704.5), the encrypted version is now gone.

But this seems to be a symptom of a much deeper change in the purpose of 
this whole spec.  Caltrans (the state Dept of Transportation) has generalized
the proposal; the "AVI" equipment is no longer specifically aimed at toll
collection but is now intended to support a much wider range of applications.
For example, in section 1701 "Definition[s]", the term "Transponders" has been
changed from "Electronic devices attached to a vehicle and contain information
which can be communicated to the reader."  to "Electronic devices that contain
information which can be communicated to the reader."  New text in section
1702.1, "Objectives", reads "It is further envisioned that more complex data
records will be developed to handle anonymous transactions, secure funds
transfers, information transfers, and other transactions between the Reader
and the Transponder that will be defined as needed."  Caltrans will authorize
new record types, but "shall pass this responsibility to an appropriate
standards setting organization when one is established and recognized."

It seems to me that this is a serious situation, for two reasons.  The first
reason is narrow and clear: the state is about to receive an AVI spec that
calls for an unencrypted protocol for toll-collection purposes.  This is a
serious matter in any case, but just how serious depends on whether it will 
be compulsory to attach one of these boxes to your car.  I cannot understand
how automatic toll collection could work unless every car has a transponder.
(Maybe there's a box that can "see" a car going by, like the European boxes
that issue speeding tickets automatically, and then determine whether any 
of those cars failed to transmit their VIN's?  Even this is a scary enough
thought.)  The spec certainly reflects no effort to develop a proposal
that would not require cars to transmit their VIN's, say through public-key
encryption or the anonymous purchase of a transponder that gets decremented
like a phone-card.

The broader and murkier reason for worry is that the state is envisioning a
bureaucratic mechanism for the multiplying applications of automatic tracking
mechanisms.  The spec is actually broad enough, in principle anyway, to
encompass certain kinds of anonymous schemes (as section 1702.1, quoted above,
mentions), but the proposal reflects no analysis of the specific technical
requirements of anonymous schemes.  In effect, all of the hard social issues
have been pushed down the line, to the committee that will authorize new uses
of these boxes.  Once the boxes exist and are in wide use, though, that will
be a whole new ball game.  We ought to stop now and think.  Do we want to set
up a bureaucratic mechanism that can turn out automatic tracking schemes on 
an assembly-line basis, hoping that we can hold the line on privacy and other
civil liberties by keeping careful enough track of this process?

Or should we take some action -- for example, writing letters to the Pete
Wilson, the state legislature, and Caltrans -- to get this entire process to
be suspended long enough for a proper public debate?  I vote for the latter.
The official address for public commentary is as follows ("All written
comments received by February 6, 1992, which pertain to the indicated changes
will be reviewed and responded to by the Department as part of the compilation
of the rule-making file."):

   Les Kubel, Chief
   Office of Electrical and Electronics Engineering
   Department of New Technology, Materials and Research
   PO Box 19128
   Sacramento, California  95819-0128

More importantly, we need to publicize the issue, so that Californians -- and
others who live in jurisdictions that might adopt the California proposal as a
model -- can make an informed choice.
                                                  Phil Agre, UCSD

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

End of RISKS-FORUM Digest 13.09
************************