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…
Welcome to VOLUME 10. RISKS will be beginning its SIXTH year on 1 August 90, although it will soon go into a first-month-of-the-summer sporadic mode until then. For FTPers who previously complained about the unfriendly sort order produced by the directory commands, you probably noticed that we recently switched the archive issue-number file name extensions to double digits (e.g., RISKS-9.01, 02, 03, etc.) and the volume summaries to RISKS-i.00, for i=1 to 9. Beginning with this issue we now have double-digit volume numbers for volume 10 and beyond, but the original single-digit volume numbers remain for the first 9 volumes. Beginning with this issue, ALL issue numbers will appear as two-digit numbers, even in the headers. (No volume has exceeded or will exceed 99 issues, a decision that ensures that the volume summary issues will be not much larger than RISKS-9.98 = RISKS-9.00, which was the largest yet.) Astoundingly, there is always someone going back to get the early issues, which affords an interesting chronological perspective of where we've been and how we got to where we are now. The historical archive also gives lots of clues as to what we need to do better in the future... Thanks for your patience through the multiple-copy ordeal. The various manifestations of it all seem to have been rectified on my end, although I still hear reports of problems elsewhere. PGN
>From an Infoworld article on Word Perfect ("Leader of the Pack,"
pp. 45-6, May 23, 1990):
"When [Word Perfect] 5.0 shipped in May 1988, the company underestimated
the demand for telephone support. Although it bought additional phone
lines, traffic was so heavy that calls to the support department brought
down the toll-free systems for the state of Utah, including phone systems
for American Express, Delta Airlines, and the Latter Day Saints Church."
Bill Kules, Automation and Research Computing, Federal Reserve Board,
Washington, DC wmk@fed.FRB.GOV Phone: (202) 452-3933
[More details on this item, first noted in RISKS-9.90.]
Here are excerpts from a page 1 story in MILITARY AND AEROSPACE ELECTRONICS,
vol 1 no 5, May 1990:
VIRUSES COULD CRASH U.S. BATTLE SYSTEM by Lisa Burgess and Tobias Naegele
WASHINGTON - Computer viruses could crash critical battlefield command and
control computers, according to a draft version of the Army's new Command
and Control Master Plan. The report says the Army's Maneuver Control
System, touted by developer TRW Inc. as the "integrating node" of the Army's
command and control battle plan, is vulnerable to sabotaged software
designed to undermine and disrupt operations.
... The four-page subsection, titled "Subversive Software" and buried 10
items deep in a section on camouflage, warns that "contractor-developed
non-developmental item (NDI) and `homegrown' software each present unique
[software surity] problems that must be addressed."
Generated by the Army's Combined Arms Combat Developments Activity at Fort
Leavenworth, Kan., the report raises three questions about the potential for
software sabotage to damage the $1.3 billion MCS battle management network:
- Could virus software implanted in the system during the design phase attack
MCS at a later date?
- Could an agent introduce a virus during combat by surreptitious access to a
workstation?
- Could an enemy use a captured workstation to introduce a virus over the radio
network?
"Under its present configuration," the report states, "the answer is yes with
regards to MCS."
... Defense contractors say any system using the sort of off-the-shelf hardware
and software utilized in MCS and ATCCS --- the Army Tactical Command and
Control System --- is potentially vulnerable to virus attacks. ...
- Jon Jacky, University of Washington, jon@gaffer.rad.washington.edu
>From the Los Angeles Times, May 31, 1990, p. D2: Court Rules Against Caller I.D.: Bell of Pennsylvania's caller-identification service is an invasion of privacy and violates the state's wiretap law, a state court ruled. The decision reverses an order by the state Public Utility Commission allowing Bell to offer the service. The service would let people know who is calling before they pick up the phone, even if the caller's number is unlisted. Several other regional phone companies already offer the service. [Also noted by schwartz@groucho.cs.psu.edu (Scott E. Schwartz).]
[From the New York Times, Thursday 31-May-90, Page D1]
Services Identifying Caller Held Illegal In Pennsylvania, By Keith Bradsher
A Pennsylvania court ruled yesterday that services that identify the telephone
numbers of callers represent an illegal invasion of privacy.
The verdict was the first in the nation on the legality of such services. The
five judges of the Commonwealth Court, a mid-level state appellate court, ruled
unanimously that caller identification services ... violate Pennsylvania's
wiretap law.
All five judges found that the services violate the law even when telephone
companies allow some customers to block the release of their telephone numbers.
And the court ruled by a 3-2 vote that the services violate privacy protections
offered by the Pennsylvania Constitution.
"In the framework of a democratic society, the privacy rights concept is much
too fundamental to be compromised or abridged by permitting Caller*ID," Judge
Doris A. Smith wrote in the majority opinion....
But Bell of Pennsylvania criticized the ruling. "Because of this decision,
Pennsylvanians are being deined a service they eagerly want and badly need -
a weapon against harassing, threatening or obscene calls," [a spokesman said].
Three Options for Panel
The Commonwealth Court hears appeals of decisions by state and local
administrative bodies in Pennsylvania, and its decisions may be appealed to the
Pennsylvania Supreme Court. John F. Povilaitis, the chief counsel of the
Pennsylvania Public Utility Commission, said his office would review
yesterday's decision and make a recommendation to the commissioners within a
few days.
[He] said the commission had three options: to ask [for a rehearing], to file
an appeal before the Pennsylvania Supreme Court, or to allow the decision to
stand.
Bell of Pennsylvania was not named as a defendent in the case. But [it] said
it qualified as a party [and could appeal if the PUC chose not to].
Bell ... filed with the commission on June 18, 1989 for permission to offer
caller identification. The commission approved the filing on Nov. 9 and the
company scheduled service to begin Jan. 9. But a Commonwealth Court judge
blocked the service pending judicial review.
The suit was filed against the P.U.C. by the state's Office of the Consumer
Advocate, the [ACLU], the Pennsylvania Coalition Against Domestic Violence
and the Consumer Education and Protective Association.
[Caller id is now] widely available in [five states] and on a limited basis in
[three others] ... according to ... a spokesman for Bell Atlantic Corporation,
the parent of Bell of Pennsylvania. Phone companies in nine other states and
Washington are seeking to introduce caller identification.
Long-distance companies, including [AT&T], also offer caller identification to
some businesses with 800 and 900 numbers. Yesterday's decision ... did not
address whether long-distance companies should stop providing information for
Pennsylvania callers.
"We have to see how, if at all, this ruling affects AT&T," said ... a spokesman
for the company.
Privacy Issue Cited
Bell Atlantic and other defenders of caller identification have argued that
the services discourage obscene callers and protect the privacy of people
receiving calls by allowing them the choice of not answering. But the court
ruled explicitly that the privacy of people making calls is more important.
The court found that caller identification services function as call-tracing
devices, which under the Pennsylvania wiretap statute may be used only under
certain circumstances. The court noted that Pennsylvania requires the consent
of all parties before a telephone conversation may be recorded.
As of December, there were 15 other states with similar requirements. The
remaining states and Federal law allow taping with the consent of one party.
But [FCC] rules require that all parties to an interstate or international call
be aware they are being taped.
The Pennsylvania wiretap statute contains wording similar to the Federal
wiretap statute. Bills are pending in the House and Senate that would amend
the Electronic Communications Privacy Act of 1986 to make caller identification
explicitly legal while requiring that telephone companies give customers the
option of blocking release of their telephone numbers. A subcommittee of the
Senate Judiciary Committee has scheduled a hearing for June 7 on caller
identification.
[Because of the remarkably complex tradeoffs between
defensive functionality and offensive violations of rights,
this item seems worth including in its entirety for its
intense educational value. PGN]
The Massachusetts Institute of Technology runs its own 5ESS switch to provide
telephone service on campus. This has significant benefits, including many
different telephone classifications (office, dormitory, etc), a modem pool, and
ISDN phones in the offices which pay for them (most do).
This week, I discovered what I consider a serious problem, however. A friend
was at the Massachusetts General Hospital (MGH) for surgery. (I'll save you
the suspense: the surgery went well.) I wanted to call and check on him to see
how the surgery went. I called the hospital's main number, and was transferred
to his room, except the phone was busy, so the operator gave me his phone
number.
The next day, I attempted to call his room, only to be greeted with "I'm sorry,
but your call cannot be completed as dialed...." I thought about the
situation, and after placing a call to the MGH operator, discovered that my
friend was in a brand new building with a brand new exchange all its own. I
called the MIT operator, who told me that the number I was trying to reach was
in Petersburg, over a half hour away (I can see MGH from my room). I finally
convinced her that this was a number at MGH, but she told me that she couldn't
connect me. My phone is only able to make local calls, so I called a friend
who works in the same office as the people who run the switch. They couldn't
make the call. In other words, neither the operator nor the top class of phone
could make the call.
Today, I called MIT's help line, and described my problem. Within several
hours, my theory was confirmed. The switch simply didn't know the new exchange
existed. It turns out, that as a "client," MIT doesn't get automatic updates
when new exchanges are created. Without this information, the switch has no
clue how to bill the caller, or even if it should let the caller make the call.
So it assumes the worst case, and disallows anyone from making the call. The
switch had to be manually programmed with the necessary information about the
new exchange.
This worries me, as someone who isn't as familiar with telephone switching
equipment might not have known what caused it, assumed it was his/her fault,
and been denied service because of it. It is surprising, to me that our switch
is not configured to take updates of this kind of information automatically
from the New England Telephone switches it talks to. I was trying to call a
hospital; fortunately it was not an emergency. My workstation has dynamic
nameservice; my doesn't my telephone switch?
Marc Horowitz
Some little while ago, Risks published the report of a flight crew landing an
airliner in Britain after a very difficult time with wind readings of 100+
knots and repeated equipment failures (in a "glass" [computerized] cockpit).
There is an interesting sidelight on this in the May 2 issue of Flight
International:
CAA appeals for CHIRP pilot to step forward
The UK Civil Aviation Authority is publicly appealing to
an unknown pilot to file a Mandatory Occurrence Report
about a serious digital cockpit systems failure which it
is unable to investigate, because the airline pilot
involved reported it through a confidential reporting system.
Investigators and airline maintenance staff have no access
to details of the apparently first-time incident. The MOR
would allow the aircraft to be identified and its cockpit
systems failures identified...
[Recap of incident, as reported by pilot.]
The confidential human factors incident reporting program
(CHIRP) was designed to encourage pilots who have experienced
a potentially dangerous incident because of human error to
report it without fear of any disciplinary repercussions.
It is unclear why this pilot used CHIRP, because there is no
indication of human error — only bad weather and systems failure...
[More recap.]
One really has to wonder just what really went on on that flight. Use of CHIRP
might seem appropriate to a pilot fearful of management reaction to criticism
of electronic aircraft, but as a result the people who want to investigate the
problem are hamstrung, doubts are cast on the accuracy of the report, and if it
*is* factual, that aircraft is still in service and potentially a lethal hazard
to crews and passengers.
Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry
I have a friend who's involved with Steve Jackson games and here is his
response to the articles that have appeared recently in RISKS. -Mark
[I had to edit a bit to make it self contained,
rather than including all of the previous items. PGN]
Date: Thu, 31 May 90 14:03 EDT
From milliken@BBN.COM Thu May 31 14:04:19 1990
Subject: Re: Debate on SJG raid in comp.risks
Re: Sherwood, RISKS-9.96:
To the best of my understanding, this account is correct except for trivial
details (not a footlocker, but some filing cabinets were broken open in the
account SJ himself wrote).
Re: Von Rospach, RISKS-9.97
> the person working on for Jackson Games was a former Legion of Doom member...
This first part of this also appears to be true — Loyd was apparently
associated with some bunch of crackers sometime in the past, and apparently
discussed some of the stuff he was doing with Cyberpunk with them, in the way
of reality-checking. However, Cyberpunk was certainly *not* a "manual on
hacking" — I haven't read my copy yet, but I'm quite certain the game rules
don't go into details of breaking computer security — it just has abstract
security programs and "cracking" programs as things that exist in the game
world. These things also exist in cyberpunk novels, which is why they're in
the book.
>If you're running a BBS that's supporting a group of system crackers, you are,
>at least, contributory to felony crimes...
The problem was that SJG *was* clean, as far as I know — the Secret
Service just went overboard in their search for "contamination". I
believe guilt-by-association is not a tenable legal theory in the US.
Grounds for some amount of suspicion, yes. But search and seizure?
<>Or does it indicate that games which involve "hacking" are subject to ...
>Not if the Legion of Doom angle is true....
The Legion of Doom connection appears to have been there, but very tenuous.
The Feds seem to have been unable to draw the line between fantasy and reality,
and appear to have been operating under a "guilty until proven innocent"
premise as far as the seizure of equipment went. As far as I know, the Secret
Service had no direct evidence that SJG or the BBS had *anything* to do with
their case — mere proximity to the principals seems to have triggered the
raid. I would expect that they would have done more research before swooping
down and carting off someone's business equipment.
I can understand how the raid happened, and even sympathize somewhat with the
motivations of the Secret Service, but I think that they definitely stepped
over the line here. One of the principles of the law in this country is that
the innocent shouldn't be harmed in the pursuit of the guilty.
---Walter
The chance of GURPS Cyperpunk being used as a manual for computer crime is very
slight indeed. In Cyperpunk fiction, a hacker's interface with the computer
network he or she is trying to operate in is an actual physical connection with
the computer. This connection is usually in the form of a direct link to a
person's brain through jacks surgically implanted in their skull. It is my
understanding that Steve Jackson Games used the same method of interfacing with
computers in GURPS Cyperpunk. This would make it a little difficult for a
person to use the game rules a handbook for crime. Unless they had a friend
real handy with tools...:-).
Stephen J. Webb
I received two copies of a well-known Macintosh software company's "Technical
Solutions" newsletter today, identically addressed. It happens fairly often
and I wouldn't have given it a second thought, except for the lead article:
"Eliminate Duplicate Records: Omitting and Deleting Duplicate Records in
<database program>". It starts off "Eliminating duplicate records is part of
the ongoing maintenance of any mailing list...."
John Chew
In RISKS 9.96, Richard Muirden writes of his experience with $89m showing up in his bank account; his bank blamed him for keying in the amount at the ATM. He went on to wonder about the range checking that might or might not be employed at the ATM to catch "such obvious erroneous data". It is my experience that there is, indeed, NO such checking performed--at least at one institution, at one time. A few years back, my credit union installed an ATM machine; as part of the hoopla surrounding the event, they had a demonstration where members could "practice" on the machine, using a card provided by the demonstator. I, being the obnoxious sort, made use of the opportunity to determine an empirical answer to the question of range checks. I cheerfully deposited the amount of $99,999,999 in the account. The demonstrator was rather worried when I showed him the receipt (oops--I meant "transaction record"); it seems that they were using a live account for the demo, which meant that all these phoney transactions would show up on the balance sheets at the end of the day! I did hear later that the trouble caused was minimal, but they did have to jump through some hoops to make sure there were no ripple effects caused by that $99m. P.S.--My personal feeling is that any non-zero deposit is an "obviously erroneous value"; I don't like giving my money to a machine in exchange for a worthless transaction record. Andy
Please report problems with the web pages to the maintainer