|
RISKS Digest 16.22
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
RISKS-LIST: RISKS-FORUM Digest Saturday 9 July 1994 Volume 16 : Issue 22
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for information on RISKS (comp.risks) *****
Contents:
Roller coaster accident -- computer blamed (Jonathan Moffett, Marcus Marr)
Re: Tax Software to Avoid: CA Simply Tax (Rick Smith, Barry Margolin)
Re: Risks of vote fraud (Lawrence Kestenbaum)
Literary treatment of street-corner cameras (Mark Seecof)
Re: Just the Facts, Ma'am (Bob Frankston)
Re: Mosaic risks (John R Levine)
Any data of Bill Gates's Info-highway book? (Richard Botting)
Re: A330 crash (Curtis Jackson, Peter Ladkin)
Re: ACM Crypto Policy Statement (Nap & Erik van Zuuren)
Re: Fraud on the Internet (D. Owen Rowley)
EMI of 'VW? NOT! (Chris Norloff)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Fri, 08 Jul 1994 11:32:16 +0100
From: [email protected] (Jonathan Moffett)
Subject: Re: Roller coaster accident -- computer blamed
27 Hurt in Roller-Coaster Train Crash
By Victoria Combe, London Daily Telegraph, 8 July 1994
More than 20 people were hurt last night in an accident on the world's highest
and fastest roller-coaster at Blackpool's Pleasure Beach. Two trains on the
new 12 million pounds ride, The Big One, collided 30 feet above ground. Eight
passengers, trapped by jammed safety bars, had to be cut free. 27 people were
taken to hospital with minor injuries, while others were treated for shock.
The ride's computer-driven trains reach 85 mph but had slowed to 40 mph when
the crash happened.
The Pleasure Beach said "One train collided with the rear of another which had
stopped in the braking system. "At the moment we have no idea how this could
have happened. The fullest enquiries are being undertaken." Mr Geoffrey
Thompson, the Managing Director said: "I have asked the American designer to
return as quickly as possible. Until then the ride will be shut."
On the roller-coaster's first day, May 28, 30 people were trapped 235 feet
up after a fault in the computer system.
[Mr Thompson said on BBC Radio 4's Today programme this morning that the
collision had taken place at 5 or 6 mph, not 40 mph. (quote from memory)]
Jonathan Moffett Dept of Computer Science University of York, UK
[5 or 6, not 40? Big difference! But probably not 50 or 60...
American designer, eh? Perhaps the same one that did the Timber Wolf
at KC's Worlds of Fun (RISKS-9.96) and Hercules at Dorney Park
(RISKS-14.83), both of which had crashes? PGN]
------------------------------
Date: Fri, 8 Jul 94 15:39:31 BST
From: Marcus Marr <[email protected]>
Subject: Re: Roller coaster accident
[More on same from television news (ITN, 10pm, 7th July)...]
[...] Because the passengers needed to be cut out, I would assume that the
safety bars worked as designed (they failed locked rather than failed open,
especially important for the inverted loops), though an unlocking
mechanisms may have been a useful addition.
Marcus
------------------------------
Date: Thu, 7 Jul 94 18:16:42 CDT
From: [email protected] (Rick Smith)
Subject: Re: Tax Software to Avoid: CA Simply Tax (Craig, RISKS-16.21)
The essence of this 1040PC RISK is that a signature on the 1040PC does not
indicate that the filer understands and agrees with what it says. A readable
version is absolutely required to make an informed decision. I prepared my
1040 with personal tax software this year and submitted 1040PC. I keep printed
copies of the full return as well as the PC version for my records. They
matched up well enough to sign.
I find it incredible that a preparer only provided the PC version for review
and signature. At the very least the preparer should submit both versions for
review. In Craig Smith's case, this would have flagged the fact that buggy tax
prep software was being used. If the two didn't match, he shouldn't have
signed either, and perhaps should have looked for a different preparer.
Today, the IRS accepts their own printed forms, facsimiles produced by
particular software packages, 1040PC, and electronic filing. For years, the
IRS has accepted facsimile forms generated on "letter quality" dot matrix as
well as plain laser printers. They have _never_ required reproduction the
colors appearing on their original forms. While I believe the IRS will widen
their use of machine readable input, I don't believe the IRS could eliminate
readable forms even if they wanted to. There are too, too many people in this
country that just don't get it when it comes to encoded line numbers and other
such intangible stuff. They'd suffer a really sharp rise in compliance
problems if they eliminated "real" forms (a similar argument applies to the
likelihood of a completely cashless society).
I have been a consumer of tax software for several years and have some
perspective on the problem with "bugs." The bottom line is that the tax
software vendor had better not sell buggy software two years in a row, or
nobody will come back for Year 3. There is a competitive market for tax
software and unreliable products suffer a deserved disadvantage.
Regarding "endorsement" of tax programs, there does seem to be a process by
which the IRS will "approve" the appearance of signable forms generated by
various tax programs. There's no implication that they approve of the
programs' tax computations, just the appearance of critical forms like 1040.
Rick Smith [email protected] roseville, minnesota
------------------------------
Date: Fri, 8 Jul 94 16:25:45 EDT
From: Barry Margolin <[email protected]>
Subject: Re: Tax Software to Avoid: CA Simply Tax (Craig, RISKS-16.21)
>Apparently there is a preparer's code covering this. CA, on the other hand,
>is under no such obligation. In most industries, a defective product is
>exchanged, refunded or repaired by the seller.
While there's no legal obligation, and CA may not have such a policy, note
that some other tax software vendors do. I believe ChipSoft promises to pay
any penalties you incur due to a miscalculation by Macintax or Turbotax.
Barry Margolin System Manager, Thinking Machines Corp.
[email protected] {uunet,harvard}!think!barmar
------------------------------
Date: Thu, 07 Jul 94 20:10:02 EDT
From: Lawrence Kestenbaum <[email protected]>
Subject: Re: Risks of vote fraud (Rushton, RISKS-16.14)
It often seems to take people by surprise when they realize how lightly
secured voter authentication is in most elections. Thomas Rushton's note,
and some of the replies in 16.15, are typical examples. This concern,
coupled with deep cynicism about politics, leads people to generalize
this "lack" of security into a vision of a risky process open to easy
fraud and stolen elections. But this conclusion is wrong.
I'm not specifically familiar with voter authentication and balloting
practices in the UK, Canada or Massachusetts. What is described, though,
sounds substantially similar to practices here in Michigan, where I have
been a voter, an election worker, and a county commissioner.
Michigan voters receive a voter registration card, but it plays no role
in the actual voting process. Indeed, no identification card of any
kind is required; if presented, it is waved away.
The voter fills out a slip of paper with name, address and signature.
Supposedly, the signature on the slip is verified against the signature
in the voter files. In truth, almost any signature will do. The
training for election workers doesn't discusses this step; especially
in busy precincts, the signature may not even be glanced at. In any
case, the card with the voter's official signature is a public record,
which anyone could have inspected prior to election day.
Another way to "spoof" the process would be to register to vote multiple
times -- no proof of identity is required.
Thus, it would be easy for a miscreant to vote twice, three times, a
dozen times. So why aren't we worried about this?
The fact is that Michigan's election laws have evolved over a century
and a half of responding to different kinds of fraud and vote buying
schemes. (For example, if a voter reveals or displays his ballot in
the polling place, it is invalid.) Most other jurisdictions have had
similar experiences. Considering both the laws and the practicalities,
effective vote fraud is very difficult to do.
First, the law: vote fraud is a felony. The penalties are in the same
range with things like arson and armed robbery. Certainly there are
people who are willing to commit felonies, but most people are not.
The public thinks of vote fraud as being a crime of serious moral
turpitude, something more like stealing cars than exceeding the speed
limit. Moreover, a perpetrator of vote fraud is at serious risk of
being caught; and the more people who are involved, the greater the
risk. On the other hand, the fewer people who are in on it, the more
difficult it is to "spoof" a sizable number of false votes.
The nature of the political scene magnifies this problem. Practically
by definition, someone who wants to commit vote fraud has to be a person
with some investment in the political process. Scoffing about politicos
aside, practically all of them are strongly motivated to avoid any taint
of criminal activity. Though there have been cases where a sitting
officeholder has been re-elected despite indictment or conviction, on
the whole it usually spells the end to one's political career. Further,
a felony conviction in many states (though not Michigan) terminates
one's voting rights as well.
But there's still another problem: until the vote totals start to
appear, it is never clear how many stolen votes would be needed, and
for whom. Polling can't tell you this -- not with the requisite
degree of precision. The costs and risks of vote fraud are pointless
if your candidate is winning anyway, or losing by too wide a margin.
Effective election stealing (with a minimum of co-conspirators) requires
knowing exactly how many votes you need. Thus, it has to be an "inside
job" and happen AFTER the polls close.
The most famous American vote fraud of all time, Lyndon Johnson's
stolen victory in the 1948 Democratic primary runoff for U.S. Senator
from Texas, took place AFTER it was known that Johnson was 115 votes
behind his opponent, Coke Stevenson. Word was passed to George Parr,
the infamous "Duke of Duval," with a plea to come up with at least
that number of votes; and Ballot Box #13, Alice TX (with 202 votes
for Johnson and none for Stevenson) showed up THREE DAYS after the
election. LBJ was declared the winner by 87 votes.
I'd guess that Texas in 1948 was far more corrupt than any state is today. In
any case, the political process *does* sometimes learn from experience; the
most exacting safeguards in election law have been built around the
(vulnerable) tabulation and reporting phase.
Lawrence Kestenbaum, School of Criminal Justice, Michigan State University
[email protected]
------------------------------
Date: Thu, 7 Jul 1994 14:12:39 -0700
From: marks@bierce.latimes.com (Mark Seecof PSD x77605)
Subject: Literary treatment of street-corner cameras
The social implications of street-corner (etc.) cameras have been the subject
of literary exploration for much longer than 10 years. For a particularly
deep (though not exceptionally old) fiction treatment I refer you to David
Drake's stories about a character named Jed Lacey, last collected in full I
believe in a paperback titled "Lacey and his Friends." Drake explores the
implications of cameras everywhere. Just to name one, people might be forced
to share their living and work space with many others to minimize the number
of cameras required (separate offices would require many cameras, bullpens
could be covered by a few). Mark Seecof <[email protected]>
------------------------------
Date: Thu, 7 Jul 1994 17:32 -0400
From: [email protected]
Subject: Re: Just the Facts, Ma'am (was Re: AI to screen bad from good cops)
The issue of screening is an old one. I've already pointed, in RISKS, that
arrest records are probably a very good predictor of whether one is guilty.
But arrest records are not conviction records! Some of the problems arise
because such statistical analysis denies the individual's ability to depart
from the stereotypes. If I was once mistaken for someone who robbed a liquor
store because I happened to have a beard at some point in my life, am I now
less entitled to protect from unreasonable searches? Or does my profile mean
that I am now subject to extra scrutiny.
I might accept the idea of a profile in airport security fallible thought the
approach is). I'm much more reluctant to accept it if it denies an individual
opportunity.
Of course, this assumes that the statistics and analysis are meaningful -- a
very big assumptions.
------------------------------
Date: Thu, 7 Jul 94 12:17 EDT
From: [email protected] (John R Levine)
Subject: Re: Mosaic risks (Jawdat, RISKS-16.20)
[re the Spyglass version of Mosaic, and using it for credit card transactions]
There are several licensees of Mosaic who are building their own enhanced
versions of the program. As far as I can tell, the primary security feature
that is likely to be added is some sort of public key digital signature, so
a client can send a message to a server in a presumably unforgeable way.
> Also, sources to various NCSA projects are not particularly difficult to
>find (I found Telnet on wuarchive, and I've seen Mosaic at CMU) - with access
>to Mosaic sources people could build fakes of the commercialized Mosaic to
>trap credit card numbers.
This Trojan Horse threat is indeed a possible one, although it seems to me
that the same "safe software" techniques that one uses to avoid getting a
virus with one's PC software would be appropriate to avoid getting Trojan
Mosaics.
Regards,
John Levine, [email protected], [email protected], [email protected]
PS re Trojan Mosaics: Actually, most of the mosaics in that part of the world
are Byzantine, but from what I've heard about the internals of the Mosaic
source code, we have a Byzantine Mosaic now.
------------------------------
Date: Sat, 9 Jul 1994 11:07:40 -0700
From: [email protected] ("Dr. Richard Botting")
Subject: Any data of Bill Gates's Info-highway book?
In the July 6th 1994 issue of our local paper - The San Bernardino
Sun-Telegram there is an odd letter from one Daniel Jeffs of Apple Valley,
date June 29th.
I'm not sure if I'm seeing evidence of the RISK of luddite paranoia or a
useful early warning of a real risk to the public. It states that Bill Gates
"is authoring a book about the information highway" which "will provide you
with a left-handed warning about what's in the works for us" [...] "your PC
will be miraculously be replaced and transformed into your PE(Personal
enslaver) and PD (personal demon)"[...].
So far I'd suspect a clever publicity stunt... but the letter ends with an
appeal for "unselfish foresight and vision"[...]"traffic controls of
public policy in the hands of all people"[...]
So
(1) Does Bill Gates vision actually imply a RISK worse than any other
vision?
(2) Have similar letters been appearing in other local papers - a mail
merged version of internet spamming?
Dr. Richard J. Botting, California State University, San Bernardino, CA 92407
Copyright(1994)Copy and use as long as you include this copyright and signature.
------------------------------
Date: Fri, 8 Jul 1994 23:33:43 GMT
From: cjackson@adobe.com (Curtis Jackson)
Subject: A330 crash
The confirmation of the A330 crash stated that "the altitude of the aircraft
was too low to avoid impact with the ground."
Perhaps there is additional information that was withheld in the name of
brevity, but why would Airbus conduct such an amazingly dangerous test so
bloody close to the ground? If they were just after maximum aft centre of
gravity, high angle of attack, and maximum climb, why couldn't they do the
same at 2000 metres? At least until they got it right at altitude, and only
*then* bring it down to ground level and simulate it shortly after a real
takeoff.
Perhaps we in the software industry should take a cue from Airbus. For
instance, network software developers should start testing their pre-alpha
catastrophic failure recovery code on live heavily-trafficked networks...
Curtis Jackson [email protected].com (preferred) or [email protected]
------------------------------
Date: Sat, 9 Jul 1994 19:09:39 +0200
From: [email protected]
Subject: The Scoop on the A330 Accident [3rd Version - see 1st note]
Air et Cosmos, 11-24 Juillet 1994, p15, contains an extensive report on the
A330 accident of 30 June 1994 by Jean-Pierre Casamayou. The general story has
been reported by Peter Mellor (RISKS-16.19). The new info is highly relevant,
and implies that control of the aircraft was lost while the aircraft was under
automatic control. This is the first case, to my knowledge, in which this has
been proved to have happened to Airbus aircraft, without any concomitant pilot
error. Sadly, the test pilots allowed the departure from control to continue
for up to 12 seconds in order to analyse the incident. This delay was gallant
but fatal. That's the English for you (RIP Capt. Nick Warner).
The autopilot was using experimental software. This A330 was
undergoing a flight test required for certification of the autopilot
for Category III operations with Pratt and Whitney 4168 engines (the
other A330's already in operation use CF6-80E1's, and such equipment
has already been through this particular flight test sequence).
Category III operations mean use of the autopilot for landing, up to
and including main gear on the runway, and requires special
certification of both aircraft and crew. It follows that a Category
III operation can potentially be aborted, i.e. the pilots can select
go-around while under autopilot contol, with the main gear on the
runway, and in the worst case an engine can fail at this point. One
can see why it's required to conduct this test from an actual takeoff,
rather than at altitude.
The flight was supposed to test the mode SRS (speed reference system)
of the autopilot, which should control the speed and angle of attack
(AoA) of the aircraft in case of an engine-out. AoA is defined to be
the angle that the wing makes with the undisturbed airflow in front of
the wing. The test was performed at rearmost center-of-gravity.
Following is a translation of a continuous fragment of the article. I have
included the originals of phrases I am unsure of. My thanks to Pete Mellor for
confirmation of some of the meanings. I don't have a dictionary of French
aeronautical terms (although such exist, and they're quite large). It refers
to the following `V-speeds', defined in FAR Subchapter A Part 1 Para 1.2 for
those in the US. V_1 is takeoff decision speed (the speed at which the
decision is made to abort or to continue takeoff in the case of engine
failure); V_R is rotation speed (the speed at which the pilot commands
nose-up); V_2 is takeoff safety speed (the speed at which the airplane may
takeoff safely, even with one motor out); V_{mca} is the minimum single-engine
control speed (the speed at which control of the aircraft may be maintained
with one engine out).
[begin translation]
The takeoff (V_1 = V_R = 126kts and V_2 = 135kts) took place at 136kts, 25
seconds after full power was arrived at (`la mise en plein piussance des
moteurs'], then the aircraft took its speed of climb of 150 kts. After the
takeoff, an altitude of 600m QNH (roughly 460m QFE) was selected on the flight
director FCU [the Flight Director on the A330 is called the FCU. pbl] This
means that the aircraft should restore level flight [`retablir en palier'] at
450m from the ground.
Conforming to the test order, the pilot attained a speed of 150 kts, and 28
degrees AoA in order to maintain this speed. Six seconds after takeoff, the
autopilot was engaged, then the left engine retarded and the corresponding
hydraulic pump cut to simulate a complete failure of the left engine. As
predicted, the AoA began to diminish and passed from 29 degrees to 25 degrees,
the limit authorised by the FMGES (Flight Management Guidance and Envelope
System) which protects the flight envelope. But quickly, because of the low
altitude selected on the FCU, the autopilot departed from mode SRS and entered
mode ALT-STAR, the mode for acquisition and retention of altitude, in which
mode the autopilot tries to attain altitude as quickly as possible, without
taking into account the limiting conditions that the airplane was in: rearmost
CoG, one engine retarded and the other at full power, high `incidence'
[another word for AoA. pbl] [this is not a good explanation of ALT-STAR mode.
pbl]. Result: the AoA started to increase again, and the speed decreased
extremely quickly [`brutalement'].
The flight team noted immediately the anomaly, but purposely let the situation
degrade for about 12 seconds, in order to analyse it better, as is their role.
The AoA attained 33 degrees with speed decaying to 100kts, which is 18kts less
than V_{mca}, the minimum single engine control speed . At this moment, the
pilot disconnected the autopilot and took over control. But the speed
continued to decrease. At about 90 kts, 28kts less than V_{mca}, the aircraft
departed in a stall [`part en decrochage'] to the left with an angle of bank
[`angle de roulis'] which attained 110 degrees.
The pilot reacted quickly and well in retarding the right engine then bringing
the wings horizontal. Unfortunately, because of the low altitude and fast
rater of descent, he couldn't avoid impact with the ground, 35 seconds after
takeoff.
[end translation]
Peter Ladkin
------------------------------
Date: 07 Jul 94 11:18:15 EDT
From: Nap & Erik van Zuuren <100042.3164@compuserve.com>
Subject: Re: ACM Crypto Policy Statement (ACM, RISKS-16.20)
On the ACM Crypto Policy Statement -- to which I strongly agree - and all the
discussions on Clipper and associated phenomena, I would like to state my
opinion with my European mind and my European trust in some of our
authorities; in this case our Police authorities. All the meddling of the
National Security Agencies ( not only the U.S.A.'s NSA ) with reference to
Sealing, Signing -- and last but certainly not least -- Encryption is very
hard to understand, as for their own and MIL data/voice traffic these
authorities up to now use their own means. They want to go COTS ( Commercial
Of The Shelf ), but have a problem in stating the categories of "time of
protection" wanted for strategical, tactical and 'national interest'
information, thereby making it difficult for COTS-suppliers to help them out
the "COTS" way.
RE: The "listening in" part:
1) For some purposes, one could even make a statement through "clear"
telephone, which has a different meaning to the intended recipient; thus
"listening in" is of 'no' use, even for a "clear" communication
2) It is a "bloody shame", and the CEC-INFOSEC ( European Commission-
INFOSEC ) people know my opinion on that for a log time now, that not
all data-communications is enciphered in some "standardised" way, just to
have a 'general' barrier against 'criminal energy'.
The adversary then has to spend processing power = money to decipher
and will loose out by using money on -- for him -- unuseable information.
3) The only way, to solve the legal part, is NOT to forbid encryption, but
provide legislation on the obligation of 'handing' over the required info
on mechanism(s), algorithm(s), and key(s) used, if required -- case by
case -- in proven law cases [ to be edited by a lawyer, specialised on
the subject ]
4) Just as a reaction on what is going on, the use of PGP ( even 2.6 ) is
exploding over here; and a European EFF will be there within short.
5) Furthermore many European RSA-based, FEAL-based and "other"-based
products are on the market, and in use !
RE: Relation to "Police Forces", including e.g. Criminal Investigation Teams:
Apparently the some European Police Forces, and related Forces, are still
considered -- in general -- to be the "friends" of the population, by the
population. The requirements for reaching such a relation with the 'public'
are:
- to be "of assistance to the public"
- trustworthy staff
- to be a trustworthy organisation, accompanied by a free press and
political will
- to be supported by the judicial apparatus, for the Forces to stay motivated
- a "quality of life" worth defending it
We will need a lot of "trustworthy" energy to protect us -- and our children
-- against "criminal" energy.
Our Police organisations use several means to protect access to their various
Databases, and this protection has to be the strongest available, because of
the 'real risks' involved.
I fully agree with the following statements in the article by Ted Bunker in
LAN Magazine of August 94:
- "We must give our full support to the development of OPEN international
security standards, that protect the interests of all parties fairly
- There is a "constant" tension between the need for privacy and the need
for protection
- We do have serious privacy concerns
- NOTE: e.g. when a Police official is performing an SQL request on a
number plate, the official in the van should only get information on:
- whether the car is looked for
- whether the probable driver is looked for
- whether the probable driver might be armed
and nothing more, surely not the address of the pretty lady-driver !
Do NOT get me wrong:
- I also fell victim to injustice ( to my opinion ) in a case versus an
'official'.
- I even have been insulted in writing by a member of the Council of Ministers.
But, we have to trust ( and at the same time: control ) the forces which
should protect the "law-abiding" ( or = sullen ? ) citizen, and are paid by
that same citizen to do so ! Might be the price of "democracy".
Nap van Zuuren, CompuServe 100042,3164
------------------------------
Date: Thu, 7 Jul 1994 11:53:58 -0700
From: "D. Owen Rowley" <[email protected]>
Subject: Re: Fraud on the Internet (Barber, RISKS-16.21)
> ... Do we really need to require users to show their identification
>papers before they can participate on the Internet?
Your reaction is naive. The short answer is yes.
However, there is no *the internet*, what you refer to is an internetwork of
internetworks. The current popular conception is to have one huge internetwork
that serves all needs and desires of all participants all the time in all of
its parts. In short - I don't think so.
Just as we zone our physical space, we must zone our data-space. Our
internetworked services and data-spaces, must provide proper security in the
form of authentication and authorization for those transactions that
absolutely require such. Our internetworked services and data-spaces, need not
provide over-zealous security with absolute authentication and authorization
for those transactions that don't requier it. ( or where such is undesirable).
This whole ball of wax falls into what I call The Un-real estate business.
LUX ./. owen Inner Zone Unrealty Co.
------------------------------
Date: Fri Jul 8 07:59:16 1994
From: [email protected].jcs.mil
Subject: EMI of 'VW? NOT! (Elana, RISKS-16.17)
[No, I did NOT make this post up!!! Elana]
> ... I heard that if you had high enough RF power
>you could disturb the electric fuel pump, so I tried this one day using
>a 600 Watt PEP amp and keyed an AM carrier, and what did I see???
SOMEBODY is making this up! 1963 VW Bugs had a MECHANICAL fuel pump (a fact I
am totally certain of). I believe VW Bugs at least until the 1970's had a
mechanical fuel pump.
Good story, but only a story.
Chris Norloff [email protected].jcs.mil
------------------------------
Date: 31 May 1994 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<Lindsay.Marshall@newcastle.ac.uk>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<[email protected]> (which is not automated).
CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
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.
ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
Issue j of volume 16 is in that directory: "get risks-16.j<CR>". For issues
of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO
digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory
and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>"
logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may
differ; UNIX prompts for username, password; [email protected] and
WAIS are alternative repositories. See risks-15.75 for WAIS info.
To search back issues with WAIS, use risks-digest.src.
With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html.
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail [email protected] .
------------------------------
End of RISKS-FORUM Digest 16.22
************************
|
|
