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…
This may or may not involve a computer, but I think it did. Those of you travelling in the Southeast yesterday were made well aware that the Atlanta airport was thrown into a complete chaos by the thunderstorms in the area, and this rippled throughout the air transport system. To make a long story short, I managed to get out of Augusta on a plane that was five hours late, which was okay since that had me leaving Augusta only two hours after I was supposed two, and my connecting flight was also two hours late. The computer part is this. After we boarded in Atlanta the pilot announced he had called for his air traffic control clearance and was told that flow control into Minneapolis was in effect and there would be an indefinite delay. Those of you who have had nothing to do with air traffic control may not realize that in the late 60's or early 70's a change was made in the way the over-all air traffic was controlled: instead of stacking planes up over destinations when traffic got crowded, a national system was instituted to monitor and control the general flow, not allowing a plane to depart until there was a clear slot for it to land in. This is all coordinated between the terminal air traffic control computers and a central computer in Washington. Anyway, we sat for about another half hour and the pilot called again. Same answer. He and/or the Delta operations people used a little common sense: the weather in Minneapolis was just fine and they could understand no reason why the airport should be congested -- they called Washington and after someone checked around received the answer "there shouldn't be any flow control into Minnapolis; someone got their wires crossed." We left in five minutes, having been on the ground for nearly an hour by either a computer error or human error only possible because the computers were installed to manage a humanly unmanageable task — almost certainly the error was caused by the overload generated to handle the disrupted schedules throughout the system. Ted
The SF Chronicle 15 March 1986 has a news story about cordless phones making ``ghost'' phone calls to the emergency number 911 (and presumably to other numbers as well). The cordless phones, which send out and respond to radio frequencies, behave strangely when their batteries start to run down. In addition, other household appliances can spur cordless phones to start diaing spontaneously. Michael Moos (president of the National Emergency Number Association) was quoted: ``Frequencies given off by other appliances -- micorwave ovens, blenders and even fluorescent lights — interfere with the cordless phones and make them start dialing.'' On an average day, at least 12 of the 2000 calls received by Santa Clara County's 911 system are such ghost calls. [Cf. heart pacemaker interference, Sputnik triggering garage door openers, automotive CB interference, etc., in past RISKS.] PGN
INFOSYSTEMS, Vol 33, No. 3, March 86 carries subject article, beginning on page 40. Also several other computer security items. Ought to help sell a few password systems, at least. - Mike McLaughlin
The wreck of a VIA Rail Canada train and Canadian National freight
train on February 8 was mentioned in this forum.
[See Martin Minow, RISKS-2.9; Chuck Weinstock, RISKS-2.12]
I think it's worth pointing out that the accident has been attributed
to human error, specifically by the CN engine crew, both of whom were
among the 23 killed. (Not 30+ as feared originally.) They drove past
a stop signal which both men should have seen.
Not only was this NOT a case of computer malfunction, but indeed, a more
fully computerized system (with cab signalling and automatic train stopping)
would probably have prevented the accident.
Mark Brader
[A fine example of the risks having to include people, not just
computers, and of a more pervasive role of the computer than meets
the eye — indeed a more human-oriented computer system might have
helped! Thus, even though it appears NOT to be a computer problem,
we discover that the computer could have done better! But, of course,
don't blame the computer system. Blame the people who specified,
designed, and implemented it — not JUST the train operator(s). PGN]
I don't want to extend this discussion of ballot integrity, but my
understanding is that in Pennsylvania there is a registration number
on the ballot when it is given to the voter, but the voter tears it
off and retains it, so the ballot when in the ballot box is not
traceable to the voter.
I'm curious about the tone of some of the discussion on this issue.
Granted we shouldn't assume the absolute integrity of non-computerized
voting without careful scrutiny. But some of the contributions seem, if
I am not mistaken, to justify computerized balloting on the grounds of
a broad (and unarguable) assumption that "any balloting process can be
subverted." Sure. But the object is to insure insofar as possible that
it won't be, and that means, primarily, protecting (1) secrecy, and
(2) accuracy.
Does anyone have an opinion on the question of how the local situation,
in this case RISKS, may influence the general consideration of the issue?
That is, RISKS is devoted to an interest in computers, not voting. Does
that, explicitly or implicitly, influence the question of what ought to
be relevant to the decision process? I'm not complaining, nor am I
criticizing previous comments by correspondents or the editor. What I am
trying to do is draw attention, as a communication scholar, to another
potential RISK: the use of electronic mail and digests with clear agendas
may inhibit the generalism needed to address substantive problems. Does
anyone have instances of this in their experience? (Note: I understand that
the problem is not limited to computers; committee work in general suffers
from this problem).
Tom Benson T3B AT PSUVM (BITNET)
[Hmm. For some reason I am rarely accused of undergeneralizing.
I keep mumbling that to deal with RISKS, we must do so holistically,
and that the computer is only a small part of what must concern us --
even though it is the primary justification for the existence of this
forum. Any weak link can be devastating. RISKS indeed tends more
toward breadth than depth, toward ALL RISKS than just computer risks.
Indeed a few other people have commented that we have strayed off into
the subjects of THEIR on-line forums! I don't really think there is
too much danger that we are too narrow. But discussion is welcome if
relevant to RISKS. PGN]
Tom's Perrine's question about the Interface Message Processors' (IMP)
security [RISKS-2.23] is a really well-founded one. As I see it (and I
haven't spent much time thinking about it, really), we can design a
network's security procedures based on some information and management
judgements.
Try answering some of these questions about the network you manage or
administer:
o How critical is the general network operation?
This can be based on many things, not the least of which include the value
of the tokens passed on the network and the desirability or necessity of
proper message reception.
o How confidential are the messages? Are patterns,
themselves, classified?
Traditional cryptology can be applied to "entire messages" (or whatever the
DIRNSA will let you get away with), but would releasable routings disclose
critical paths? Would they "give away" operational information which should
be protected?
o Can message speed be increased for vital information
whose delivery is paramount? I'm not sure that this is as
much a security problem as it is a basic applied-computer-
science question. Some feel that packet precedence systems
are unnecessary; some feel otherwise.
The Defense Data Network (DDN), which is comprised of the ARPAnet and the
MILNET, serves a mighty diverse consumer market. Universities, research
facilities, commercial institutions, and government operations all share the
facilities of the network.
Currently, some classified (i.e. sensitive) operations make use of the DDN.
Systems like the COINS-CINCPAC project now use the DDN as a transport
medium; loss of the medium would have at least some impact on CINCPAC's
intelligence operations. For such setups, the basic network security is
ensured through fail-secure cryptographic setups which are only able to
prepend one specific message header to an already encrypted packet. (One
thus gets around the red-black interface problem with packet addressing.)
And physical security is ensured by using guards, locked doors, and the like
at the point of security interface, and at all secured locations.
But this doesn't address the Internet physical or electronic security in
general. I believe that the Defense Data Network Program Plan has a
scheduled dis-integration of the DDN parts very soon. Obviously we have
already traversed the ARPA/MIL separation, but more is soon to come. With
the introduction of Internet Private Line Interfaces (IPLIs) (and, based on
various community needs, estimates for numbers of IPLIs are nearly 1000--and
probably higher), the network can divide itself such that hosts will not
talk to non-community-of-interest hosts. The "big plan" includes folding
MINET, MILNET, SACDIN (!), and IDHS (!!) into one network: the DDN. The
current ARPAnet will remain an R&D network, essentially isolated completely
from the DDN.
I haven't been watching the network events (due to my absence) for about a
year now, so I don't know how far along we are in this plan. But if it's
implemented (we're all waiting for BLACKER, so budgetary holdbacks may well
intervene), then "vital network nodes" would be physically secured, with the
ability to fold ARPAnet into DDN in the event of a crisis where additional
redundancy is required to limit network failures due to attacks on the
system.
Perhaps someone who really knows a lot about these things could comment on
the physical security side of the DDN house. For those of you who are
interested, I have some citations to references which I would be happy to
share with persons on the ARPANET or MILNET; I will respond only to e-mail
requests.
Kurt F. Sauer
Tulsa, Oklahoma
Internet: ks@a.cs.okstate.EDU UUCP: ks@svo.UUCP
In re the modem controversy: the originating modem contains circuitry
to detect answering tones (in the range of 2000-2400 Hz.) It should
remain silent until it does detect the answering carrier (at least
if the modem claims to be Hayes standard.) However, other sounds on the
telephone line (noise, human voice, even just picking up the phone)
can sometimes excite th detection circuitry and software, resulting
in the originating modem turning on its tone generator. Sorry, but
Phil does know what he's talking about.
Jim McGowan
(jrm@ford-wdl1)
[Let's BLOW the WHISTLE on this one. There's no modem operandi. PGN]
Please report problems with the web pages to the maintainer