The RISKS Digest
Volume 11 Issue 92

Monday, 17th June 1991

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

RISKS DISK'S WHISKS TSKS!
PGN
The Patriot system and the Dharan Scud: Time Warp
PGN
A two-cable telephone interruption: Washington D.C.
Steve Bellovin
PGN
Abusenet (a feeling of deja vu?...)
Pete Mellor
IRS Tax Systems Modernization
Dick Wexelblat
EC draft directive on telecomms privacy
Martyn Thomas
EC draft directive on data protection
Martyn Thomas
Re: Algol vs. Fortran
Steve Bellovin
Martin Minow
Caller ID and 800 numbers
Lauren Weinstein
Info on RISKS (comp.risks)

RISKS DISK'S WHISKS TSKS!

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 17 Jun 91 13:58:33 PDT
Speaking of things not working as expected (see the next three messages), the
active RISKS disk on CSL was down from late Thursday until mid-Monday.  [The
repairman said finally today rather calmly, "The disk motor fell out."]

The mail server (Hercules) remained up.  Nevertheless, all sorts of incoming
mail was rejected.  If you got BARFmail, please RETRY.  Thanks.  PGN


The Patriot system and the Dharan Scud: Time Warp

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 17 Jun 91 13:56:25 PDT
The 10 June 1991 issue of Aviation Week and Space Technology (p.25-26) has
another increment on the Dhahran Scud attack.  In the four-day siege ending on
25 Feb 91, one of the two batteries was down for radar repairs.  The other had
endured a clock drift of .36 seconds, which was enough to prevent the radar
from tracking the Scud.  It seems that the spec called for 22 hours of
continuous operation, with the tacit assumption that the system would be shut
down each day, maintained, and possibly moved to another location.  100 hours
was obviously well beyond spec...


A two-cable telephone interruption: Washington D.C.

<smb@ulysses.att.com>
Fri, 14 Jun 91 16:07:09 EDT
A fiber cable cut, in Annandale, Virginia, knocked out the Associated Press's
audio feed for their radio news service.  They do have a backup routing system,
which switches transmissions to a second cable if the first one fails.
However, according to a spokesperson for the AP, ``Somehow, they both ended up
being hit by this incident.''

        --Steve Bellovin


A two-cable telephone interruption: Washington D.C.

"Peter G. Neumann" <neumann@csl.sri.com>
Sun, 16 Jun 91 14:23:13 PDT
About 80,000 telephone circuits were accidentally knocked out when a contractor
severed two fiber-optic cables in a suburb of Washington, D.C.  UPI, AP, the
Pentagon, residential, and business phones were cut off for a few hours in the
morning of 14 June 91, along with some cellular phone relay stations.  [Source:
San Francisco Chronicle, 15 June 81, p.A5] The outage lasted from 9:30am until
3:30pm.

                      <<<<<<<<<<<<<<<><><><><><><><>

TWO cables in one swell foop!  So, as in the 1986 cutoff of New England from
the rest of the ARPAnet because one cable held all supposedly-independent 7
circuits, the primary and the backup were knocked out — this time despite the
precaution of running them through separate cables.  Murphy and his twin
brother were both at work.

This episode occurred just in time to add another datapoint for my talk at
COMPASS '91 on 26 June at NIST in Gaithersburg MD, presenting my annual `risk
award' paper, this year's title being

  "The Computer-Related Risk of the Year: Weak Links and Correlated Events",

considering a bunch of outages resulting from single-point failures and other
cases in which apparently independent events resulted in disasters.  The phone
cases discussed include the AT&T long-distance problem on Jan 15 1990, the
NY-area cable on 4 Jan 91, and the White Plains ARPAnet 7-link outage 12 Dec
86.  The multiple-event cases are also drawn from the RISKS archives.

If you are interested in COMPASS '91 (information, proceedings, etc.), please
contact Dolores Wallace at NIST.  Try wallace@swe.ncsl.nist.gov or mayhaps
DWallace@nist.gov if their "standardization" works...

Oh, by the way, RISKS will slow down for this week and next.  I'll put out an
issue only now and then.  PGN


Abusenet (a feeling of deja vu?...)

Pete Mellor <pm@cs.city.ac.uk>
Mon, 17 Jun 91 15:39:20 PDT
An item appeared in yesterday's Mail on Sunday which sent a shiver down my
spine. (I don't have the article to hand, so I am summarising from memory.)

Apparently, innocent British kids are being corrupted by a tidal wave of filth
from the other side of the Atlantic. This is being beamed right into their
homes via satellite, and all they have to do is flick a switch on their
computers to receive explicit hard-core porno pictures which they can display
on screen. The authorities are powerless, since the source is outside the UK,
and even the existing laws governing posting of indecent material do not apply.

This dire state of affairs has come to the attention of a certain
Emma Nicholson, MP (she of the proposed draconian laws against hackers: see
RISKS passim), who thinks that someone ought to do something about it.

Expect some half-baked attempt to introduce legislation to control UK access
to Internet! :-(

Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 p.mellor@uk.ac.city(JANET)


IRS Tax Systems Modernization

<rlw@ida.org>
Mon, 17 Jun 91 13:16:54 E+1
The IRS is heavily involved in a Tax Systems Modernization (TSM) program.  The
following (part of the public record) is from the IRS Commissioner's testimony
to congress about the program.

Chart 2  Projected Benefits From TSM

Eliminate 6-7 million unnecessary contacts with taxpayers each year that are
now required to correct name, address, social security number or account
information.

Eliminates 95 percent of the computer-generated enforcement notices
that our current systems mail out after a taxpayer has properly
responded to a prior notice.

Resolve during the first call 80 percent of all taxpayer questions that
are raised by telephone.

Assure that in 95 percent of all cases, a taxpayer can resolve an IRS-related
matter by dealing with a single IRS employee, and can do so within specified
time frames (ranging from minutes to months, depending upon the nature of that
matter).

Generate all account-related correspondence to a specific taxpayer, not
a generic "taxpayer".

In all cases, provide IRS front-line employees (and taxpayers) with
current, complete and accurate account information.

Provide copies of tax returns to IRS employees and taxpayers within one day
rather than the current 45-day target.  (A goal we presently are unable to meet
one-third of the time.)

Reduce case processing times by 20-15 percent.

Reduce taxpayer, practitioner and IRS caused processing errors by 70-90 percent
for electronically filed returns; increase number of taxpayers using electronic
filing from 4 milion (1990) to more than 25 million by the mid-1990s.

Maintain and enhance the privacy and confidentiality of tax returns and
taxpayer information.

Generate the information necessary to move from after-the-fact, case-by-case
enforcement activities activities to comprehensive strategies designed to
enhance voluntary compliance, while minimizing the burden on taxpayers and
reducing costs to the government.

Generate annual savings of $500-700 million (by reducing systems maintenance
costs, reducing staffing in paper intensive processing activities, and
eliminating the costs of storing and retrieving paper documents).


EC draft directive on telecomms privacy

Martyn Thomas <mct@praxis.co.uk>
Fri, 14 Jun 91 10:34:13 BST
The European Commission (CEC) has issued a draft directive on privacy of
telecommunications. The idea is to bring the EC natins' laws into harmony,
so that the service and privacy are the same throughout the EC. The draft
directive is COM(90) 314 final - SYN 288.

Some parts may be interesting for comparison with US practices:

Article 8: The telecommunications organisation [t.o.] must provide adequate,
state-of-the-art protection of personal data against unauthorised access and
use. In case of particular risk of a breach of the security of the network, for
example in the field mobile radio telephony [sic], the t.o. must inform the
subscribers concerning such risk and offer them an end-to-end encryption
service.

Article 12: [paraphrased]. callers must be able to disable CID per-call, and
per-line. Called subscribers must be able to disable incoming display of IDs
per call or per line, and must be able to restrict incoming calls to those
which transmit IDs. Overrides must be available for tracing nuisance calls and
for emergency services, and these must work community-wide.

Article 17: [paraphrased] Subscribers must be able to request that
unsolicited advertising calls are blocked, and the t.o. must take the
necessary steps to prevent such calls.

Article 19: "The provisions of this directive relating to the telephone
service shall be applied to other public digital telecommunications services
to the extent that these services present similar risks for the privacy of
the user".

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   mct@praxis.co.uk


EC draft directive on data protection

Martyn Thomas <mct@praxis.co.uk>
Fri, 14 Jun 91 11:15:37 BST
The Commission of the European Community (CEC) has issued a proposal for a
Directive on data protection [COM(90) 314 final - SYN 287.]

It is very detailed and prescriptive. The broad principles are similar to
the UK Data Protection Act (which I assume is well-enough known to save me
hours of typing!) with two notable extensions:

The "data-subject" has to have given informed consent to any processing
which goes beyond "correspondence purposes" (subject to exceptions for
public authorities and other processing specifically authorised by law).

The protection is NOT limited to computer files - it covers all manual files
as well.

Article 17 is interesting:

"The Member States shall prohibit the automatic processing of data revealing
ethnic or racial origin, political opinions, religious or philosophical beliefs
or trade union membership, and of data concerning health or sexual life,
without the express and written consent, freely given, of the data subject. [
... ... ] Data concerning criminal convictions may only be held in public
sector files."

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   mct@praxis.co.uk


Algol vs. Fortran (Nilges, RISKS-11.90)

<smb@ulysses.att.com>
Thu, 13 Jun 91 20:33:31 EDT
     Algol lost out to Fortran in part because of imperialism:
     Algol was superior to Fortran but the United States could not
     concede that the Europeans had the lead in programming languages.

This claim, though (mercifully) tangential from the main thread, is actually
quite relevant if viewed differently.  Is Algol really superior?  By what
metric?

Fortran was carefully crafted to be as efficient as assembler language.
Witness, for example, the restrictions on subscript form — they were imposed
so that a comparatively-simple compiler — and today's optimizers didn't exist
-- could generate excellent code.  Algol, on the other hand, had constructs
like call by name, and required a stack for efficient implementation.

Today, with the hindsight of 30-odd years, it's easy to see that Algol is
better.  But the criteria by which we make that judgement didn't even exist
then — all there was was the clash of efficiency versus an (obvious) elegance.
And even if those making the choice had known of our concerns, it's far from
obvious what they would have decided — machine cycles were not seen as a
luxury.

Sure, cultural NIH played a part.  But don't discount the effect of people
aiming for different — and equally valid — targets.  (I leave the connection
as an exercise for the reader.)
                                           --Steve Bellovin


The best is not good enough — why Algol lost out to Fortran

Martin Minow 14-Jun-1991 0949 <minow@ranger.enet.dec.com>
Fri, 14 Jun 91 06:57:36 PDT
I must respectfully disagree with the claim in Risks 11.90 that Algol lost out
to Fortran because of an American rejection of a superio — but non-American --
language.  There are several other reasons, some of them actually Risks
related:

-- Algol-60 lacked a usable input-output method, especially one appropriate
   for the offline tab-equipment (punch cards and line printers) in common
   use in America in the '50's and early '60's. This was an intentional
   omission in Algol-60, as many of the computers it was first (in Europe)
   were one-of-a-kind research computers that used 5-channel paper tape and
   teletype printers.  Magtape was generally unavailable.
-- No Algol-60 compiler was available on an IBM-709 series machine until,
   roughly, 1966.  (Well, there was the Algol-58 MAD, but it was a university
   development that ran on a non-standard executive.)  By 1965, however,
   Fortran was being taught to engineers as an engineering tool (one of my
   programming courses was in the agriculture department), the IBM 360 was
   about to replace the 709-series. and PL/I was not yet available.
-- IBM *marketed* Fortran to engineers: I learned it from a tiny manual
   called, as I recall, "An Introduction to Engineering Analysis by Computer"
   that taught Fortran by example, and used "real" engineering problems
   for its examples (structural engineers did not see the relevance of
   the eight queens problem).

The above claims are from my own experience: I learned Algol (from Dijkstra's
book) before Fortran, gave some minor assistance to the Alcor-Illinois
Algol-60 compiler team, and programmed for several years exclusively in
Algol-60 on an European 1st-generation computer using a compiler that I
believe was written by Dijkstra — and a very good compiler it was, too.

Martin Minow            minow@ranger.enet.dec.com


Caller ID and 800 numbers (Mainwaring, RISKS-11.91)

Lauren Weinstein <lauren@vortex.com>
Mon, 17 Jun 91 12:01:41 PDT
John (J.G.) Mainwaring, in response to my recent statements on caller ID (CID),
suggests that since 800 calls are essentially a "collect call", that caller
number information is appropriate to provide to the callee.

He states:

"A call to an 800 number is in fact a collect call.  A person (or
company) has at least a plausible argument that they should know who
is calling, and have the right to refuse calls from whomever they
please."

He also suggests that callers could avoid perceived problems by finding the
number of the company via directory assistance and not using the 800 number.
Outside of the fact that this would require the caller to pay for the call, it
can be difficult, and often impossible, to gather enough information from a
quick commercial or even a print ad to dig out the actual name of the parent
firm who would be listed and to know where they are listed.  Then you end up
paying for the directory assistance call, and, assuming you get a number, find
yourself talking to a receptionist at corporate headquarters, rather than the
sales or info people who answer the 800 number and might be located somewhere
else entirely!

I would agree that 800 calls, being of a "callee pays" nature, are deserving of
special consideration (however, this does not apply to non-800 calls, which are
the primary focus of the now appearing general purpose CID systems).  One of
the problems, however, as has been mentioned here before, is that CID does not
tell who is calling, it tells the number of phone from whom the caller is
calling!

When someone calls you collect, are you told the number they are calling from?
No, you are told *who* is calling.  As I mentioned in my original article,
people make calls from different numbers at different times!  Nor should one be
required to provide their number in order to "identify" themselves.  Telling
someone who you are (if they have a "need to know") is one matter--giving them
your (possibly unlisted) phone number is something entirely different.

While at least one telco is experimenting with a name delivery service in
conjunction with CID, this as far as I know is providing the name associated
with the phone number account, not a name as provided by the person who is
actually making the call (who may have nothing to do with the name on the
account).  This forum has previously seen discussion of proposals that would
allow the caller to individually specify what name would be sent to the callee
as an identification on a call from any phone.  There is no evidence that the
telcos are interested in such systems or that they are moving in that
direction.  Such systems would of course have various RISKs associated with
them as well, and I would consider it important that callers still be able to
choose not sending any identification at all if they so desire.

Decisions made on the basis of caller telephone numbers will often be
incorrect.  Even worse, callers may not even realize why they were treated the
way they were, since they won't usually know how much (possibly erroneous and
often invasive) information was gathered based on their phone number before
their call was answered.  The ANI magazine I mentioned previously suggested
using calling number as a means to determine what language operator to use when
answering incoming calls, since, it states, "people who speak different
languages tend to live in geographic clumps".  While this is one of the less
onerous applications of this technology, it gives some insight into the rather
bizarre thinking going on among some of the proponents of these systems.

Regarding the specific issues of 800 numbers, the legitimate concerns
of the firms paying for these numbers can be preserved in other ways.
Presumably it could be made possible for them to block calls from
particular numbers, without knowing what those numbers are, just as
in standard CID systems.  There are of course RISKs associated with
this, given that you are dealing with a phone number, not the person
who might be, for example, making harrassing calls to your firm.  You
could end up blocking a number that happened to be used for some
troublesome calls at one time but that later might represent a
potential customer.  And people do change their phone numbers!

An even better technique would be for the telcos and long distance (LD)
carriers to be required to respond to an 800 subscriber's request for
dealing with harrassing or troublesome calls.  This could be done by
the telco or carrier looking at the call pattern information for the
subscriber (at their request) to determine the caller numbers, or
through the use of a Call Trace system like that which exists as an
alternative to CID for conventional calls.  In either case, the
subscriber themselves would not need to know the caller's phone
number.

To make it easier for the 800 subscriber to detect abusive calling patterns but
avoid the problems associated with full number delivery, it might be reasonable
to provide the 800 subscriber with the caller's area code and prefix only, when
the caller has specified CID blocking. This would only apply for 800 calls--for
all other calls a CID block would result in no number information being
provided.

Area code and prefix would provide enough data to pick out harrassing or other
troublesome 800 call patterns.  In conjunction with rules that required the
telco or LD carrier to cooperate in such cases to use their full number
information that they have for the callers to deal with taking action against
such callers, this could solve the problems without revealing the full caller
number to the 800 service subscriber.  The lack of full number would make most
of the more obnoxious applications of CID/ANI delivery on 800 numbers
impossible.

Of course, the telcos and LD carriers would prefer not to be involved in this
process.  They'd prefer that the caller and callee just slug it out completely
amongst themselves.  Their main concern is that if full calling number
information is not available to the entity being called, a massive potential
revenue stream from business applications that would make (mostly realtime) use
of these numbers would be rendered impractical.
                                                        --Lauren--

Please report problems with the web pages to the maintainer

x
Top