precedence: bulk
Subject: RISKS DIGEST 19.68

RISKS-LIST: Risks-Forum Digest  Thursday 16 April 1998  Volume 19 : Issue 68

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

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents:
Commerce Secretary calls U.S. encryption policy a failure (Edupage)
IRS to spend $1 billion to fix Y2K problems (Declan McCullagh)
Only 1/3 of popular Microsoft apps are Y2K compliant (Chris Stamper
 via Declan McCullagh)
Y2K and the eagle talon (Josh Rivel via Dug Song)
Gas station owners forbid use of mobile phones ... (Steven Slatem)
Tacoma, WA 911 computer problems (Jonathan Clemens)
Comvor: Hamburg police computer system (Martin Virtel)
Risks of being a pioneer: KL International Airport (John Lim)
AT&T network failure takes a toll on commerce (Edupage)
AT&T frame relay network effects (Brian McMahon)
HP200 data integrity woes (Fred Cohen)
Webmaster's copyright risks (Mario Profaca)
Re: Cypherpunks break GSM digital cell phone encryption (Stewart Fist)
CFP: Dependable Computing for Critical Applications 7 (Chuck Weinstock)
Abridged info on RISKS (comp.risks)

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

Date:   Thu, 16 Apr 1998 19:57:16 -0400
From: Edupage Editors <[email protected]>
Subject: Commerce Secretary calls U.S. encryption policy a failure

Distancing the Commerce Department from the position held by the Federal
Bureau of Investigation, Commerce Secretary William M. Daley says that the
Clinton Administration's controls on encryption technology are hurting
America's ability to compete with other countries.  "There are solutions out
there.  Solutions that would meet some of law enforcement's needs without
compromising the concerns of the privacy and business communities.  But I
fear our search has thus far been more symbolic than sincere... The cost of
our failure will be high.  The ultimate result will be foreign dominance of
the market.  This means a loss of jobs here, and products that do not meet
either our law enforcement or national security needs."  (*The New York
Times*, 16 Apr 1998; Edupage, 16 April 1998)

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

Date: Thu, 16 Apr 1998 10:56:16 -0700 (PDT)
From: Declan McCullagh <[email protected]>
Subject: IRS to spend $1 billion to fix Y2K problems

[If, as is widely predicted in Y2K circles, the IRS's computers go south,
maybe we'll have that national sales tax after all. --Declan]

http://cgi.pathfinder.com/netly/opinion/0,1042,1909,00.html

The Netly News, April 16, 1998

How is it that millennial fever is focused so far on 30-year-old lines of
COBOL code, as opposed to, say, the second coming of a messiah? Yesterday
the head of the IRS used his agency's biggest day of the year to proclaim
Year 2000 the "most unfortunate but most essential problem" -- and one that
will cost $1 billion to fix. This is up from $850 million two weeks ago, and
$250 million six months ago. "We simply, absolutely must devote all of our
resources to fixing the year 2000 problem," Charles Rossotti said at a
National Press Club luncheon. If the problem is not solved, he said, the
result will be "very dire indeed." Only 625 days to go.

 [To subscribe: send a message to [email protected] with this text:
subscribe politech
 More information is at http://www.well.com/~declan/politech/ ]

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

Date: Wed, 15 Apr 1998 17:35:32 -0700 (PDT)
From: Declan McCullagh <[email protected]>
Subject: FC: Only 1/3 of popular Microsoft apps are Y2K compliant

[Time for the government to step in and start licensing programmers! Just
kidding, folks -- but I know industry lobbyists here who are getting
worried.  --Declan]

>Date: Wed, 15 Apr 1998 15:40:30 -0700 (PDT)
>From: Chris Stamper <[email protected]>
>To: [email protected]

 By Chris Stamper
 ABCNEWS.com
 April 15 - Some Microsoft products used on thousands of computers will
 have problems after Dec. 31, 1999, and Bill Gates turned the light on
 the Year 2000 bugs in his software today.  Microsoft's new Year 2000
 Resource Center is now alive on the Web. There's a picture of Gates on the
 home page, reassuring millions of customers that "we are committed to
 providing the information you need."

Microsoft Reveals Y2K Problems On New Web Site:
http://www.abcnews.com/sections/tech/DailyNews/y2k980415.html

 [Declan's POLITECH mailing also included an article by Mary Jo Foley
 <http://www.zdnet.com/sr/breaking/980413/980415a.html> pointing out that
 MS reports that only 21 of MS's top 60 software products are Y2K
 compliant, primarily because of MS Internet Explorer 3.X and 4.X.
 Windows 95, Windows for Workgroups 3.11, NT Server 4.0, NT Workstation
 4.0, various versions of Office 95, Visual Basic 5.0 and Visual Studio
 Enterprise 5.0 and also reported as noncompliant.  PGN]

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

Date: Wed, 15 Apr 1998 20:46:03 -0500 (EST)
From: Dug Song <[email protected]>
Subject: Y2K and the eagle talon

>Date: Wed, 15 Apr 1998 20:18:52 -0400
>From: Josh Rivel <[email protected]>
>To: [email protected]
>Subject: GeeK: interesting implications of Y2K non-compliance

I'm on a mailing list related to Eagle Talons/Mitsubishi Eclipses/Galant VR4's
anyway, it seems the code in the ECU's for the 1st generation of those cars
(1990-1994) has an interesting problem with Y2K compliance.

The following excerpt was written by Todd Day <[email protected]> who is the
list moderator, and ECU (Engine Control Unit, aka car computer) wizard.

[All you guys with 1989-1994 DSMs might want to take another car to the
parties on Y2K eve...  or arrange for a tow truck.  1995-98 ECUs seem
to be Y2K compliant, as far as I can tell (an OBDII requirement).  If
you don't want to be seen at the party without your DSM, for $100, I
can fix your ECU so the overflow problem won't happen until 2089.

I've set my ECU to the bewitching hour, and the results aren't
pretty.  The overflow causes a mask bit to be set which prevents the
spark plug in cylinder 3 from firing, but doesn't stop the fuel flow.
The fuel flow in that cylinder actually doubles due to a side-effect
of the spark bug.  This creates some pretty spectacular backfires, I
must say...  One hell of a way to welcome in the new century.

Oh yeah - this bug happens at December 31st, 1999 at midnight (or
January 1st, 2000, depending on how you look at it) in the CENTRAL
time zone.  That's because the cars were all built in Illinois.  So
for you East Coasters, it will occur at 1am, and West Coasters will
experience it at 10pm.

-talon mgr]

Josh Rivel  Senior Network Engineer  Digital Telemedia, Inc.
http://home.dti.net/jrivel

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

Date: Thu, 16 Apr 1998 21:02:29 +0200
From: IntelliTech Media <[email protected]>
Subject: Gas station owners forbid use of mobile phones ...

Gas station owners forbid use of mobile phones, claiming EM waves are
disrupting their data networks

PRAGUE, CZECH REPUBLIC (NBISN, 04Apr1998) -- Mobile phones, which used to be
an extravagance for the elite, are now cursed by many of the thousands that
have adopted them since networks and phones based on the digital mobile
standard GSM became available over one year ago. Users have been warned that
use of the phones while driving can be dangerous, use in banks is forbidden
due to use by robbers to target cash-heavy bank clients, use in hospitals is
forbidden because of interference with equipment, use on airplanes is
forbidden (and usually useless even if it wasn't), they just plain don't
work in the underground, use on ground-bound public transportation is
frowned upon by other passengers (or grinned upon by snoops) and now use at
many gas stations is forbidden. Gas station chain owners, such as Benzina,
are posting signs with a big X over the picture of a mobile phone and
claiming that they have a legal right to forbid the use of these devices as
the rascals interfere with data transfer over payment card networks such as
CCS, Mlada Fronta DNES, a leading Czech newspaper, reported on 04Mar1998.

But CCS claims that mobile telephones can in no way affect the operation of
the CCS system and that not a single case as such has been reported, MF
DNES quoted Hana Sevcikova, business manager at CCS, as saying.

A Benzina spokesman, Pavel Schinkmann, however, says that the cases are
fresh and thus maybe not everyone has heard about them yet... and that the
phones are indeed forbidden at all of its over 400 stations throughout the
Czech Republic. Benzina, who holds an ISO certificate, links all its
stations via a network, apparently with some wireless connections.

MF DNES quoted one Benzina spokesman as saying that "electromagnetic waves
can disrupt computers and sometimes can cause an explosion."

But MF DNES did cite at least one concrete case: A spokeswoman for the
Benzina station in Prostejov, Bozena Hochwaldova, said the mobile
telephoning brought down the whole CCS system not long ago.

Some Shell stations have also forbidden the use of mobile phones for the
first time just days ago but some operators such as OMV say they will
tolerate their usage.

Tamoil, recently exposed as having Libyan capital behind it by the English
language Prague Business Journal, http://www.ceebiz.com, will probably not
be one of those to forbid mobile phone usage since they are already
starting to lose enough business as is.

Maybe the list of where you can actually use mobile telephones should be
published -- it will soon certainly be much shorter than the list of places
where you can't.

- Steven Slatem, IntelliTech Media, Inc., http://www.intellitech-media.cz,
[email protected]

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

Date: Thu, 16 Apr 1998 08:40:13 -0700 (PDT)
From: Jonathan Clemens <[email protected]>
Subject: Tacoma, WA 911 computer problems

>From <http://www.tribnet.com/news/top/a1/0416a15.htm>

"Glitches in a new 911 computer system are slowing critical communications
between local emergency dispatchers and officers.

"The sporadic problems have become severe enough to jeopardize officer
safety and must be fixed immediately, police say." [...]

The article goes on to describe how the "windows based" solution by
Unisys was one full year behind schedule, was pulled out of service for 18
months of software repair, and is still unusable under heavy load.

The contract (US$ 1.4M) seems relatively small to be plagued by such
problems. Yet, it is another reminder that poor project execution, no
matter with whom the blame lies, can be hazardous to life and safety.

Jonathan Clemens, CCP  Intel Corp.

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

Date: Thu, 16 Apr 1998 20:30:15 +0200 (MEST)
From: Martin Virtel <[email protected]>
Subject: Comvor: Hamburg police computer system

Since 1989, some 120 Million (estimated) Deutschmarks (US$ 70 million) have
been wasted trying to design and install a new computer system ("Comvor")
for the police in Hamburg, Germany. The system, designed to ease the load of
paperwork on the police, never worked.

So far nothing new, the reports have going on for month, if not years. Red
tape wasting our money, one thinks. What strikes me are three conclusions of
the whole affair that appeared in Hamburger Abendblatt (April 16th, p. 13)
today:

- 356 jobs have been cut (some of them because they "won't be necessary
after the system starts working", some of them to save money for buying the
computers in the first place), and there are no plans re-employ
people. Instead, police officers do the paperwork that the computer system
was supposed to do, and money has to be found to buy new computers.  The old
system (the one "Comvor" was built to replace) sucks in 340.000 Deutschmarks
a month for maintenance.  (Lean government is more expensive, in some ways.)

- The consultant firm contracted for designing a new computer system blames
part of the mis (or non-)achievements of Comvor on the fact that police
people were in charge of the development team.  "Software design was not one
of their core competences", reads the quote from Uwe Kirchhoff, the boss of
the consultant firm. (And I thought it were the software people who make
computer systems that don't work in the real world.)

- Interior minister Hartmuth Wrocklage blames the misachievements on the
fact that "the complexities (of the whole venture) had been underestimated".
(This one ranks first in the top-ten of "Why our software doesn't work", I
guess).

To me, it looks a bit like a case of "Hey, how can we save money and at the
same time stick to the weird and inefficient way we do our job? By putting
the whole thing into a computer?" Contracting a software firm in a situation
where you should buy advice from a management consultant.

Big risk: "The Computer will solve our problems".

Martin Virtel, DIE ZEIT im Internet (http://www.zeit.de)  +49 (0)40-3280-562

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

Date: Thu, 16 Apr 1998 10:38:42 +0800
From: [email protected]
Subject: Risks of being a pioneer: KL International Airport

Malaysia is getting a state- of-the-art airport for its capital (Kuala
Lumpur), but it has been plagued with delays. Portions of an article is from
the Far East Economic Review.  ---
http://www.feer.com/Restricted/98apr_16/projects.html

"With the (Malaysian economic) slowdown, demand will come down and we'll
have some excess capacity on opening day," admits Clifford Herbert, who
heads Kuala Lumpur International Airport, the government-owned company
responsible for the 9-billion-ringgit ($2.4 billion) project. But he rejects
notions that the airport is too extravagant. "In terms of cost, we have
something very functional," Herbert says, pointing out tha the airport was
almost completed before the currency crisis struck. "I don't think we wasted
anything."

Whether airlines and passengers agree will depend on the airport's teething
problems in the months ahead. The opening has already been postponed twice:
most recently from April to late June. Some of the biggest anxieties centre
on the 700-million-ringgit (US $200 million) Total Airport Management
System, a computer network that links 16 sub-systems ranging from flight
information to baggage handling.

The airport will be the first in the world to link all these functions into
one set-up. But pioneers often pay a price. Reports say that when the
baggage-handling system was tested for the first time, with 200 bags, not
one ended up where it should have. "In theory it sounds great, but there are
a lot of intricacies in linking so many computers," says a second foreign
airline manager in Kuala Lumpur.  ( Shades of Denver airport ! - john)

Some airline operators fear Malaysia is stressing pizzazz over efficiency.
"Kuala Lumpur strikes me as state-of-the-art. They've tried to put all the
best things into the airport," says the first foreign airline executive,
whose airline lands in both Kuala Lumpur and Hong Kong. "Hong Kong is trying
to make an efficient airport," he says. (Hong Kong's new airport is slated
to open in early July.) "What we've heard so far about Kuala Lumpur is that
it's more grand than functional."

-- My comments - John Lim: I was formerly employed by a company heavily
involved in bidding for IT systems for the KL International Airport and I
can attest to the dream of the politicians approving the project were more
grand than functional.  In fact when my former company were bidding for the
project, most of the big IT companies in Malaysia felt that the ambitions
were too great given the tight schedule. But most of these companies,
including my former company still went in to bid anyway. PS: we knew about
Denver airport back then in 1994/5.

The Risks:
For companies: Some projects are felt to be too big and prestigious to walk
away from; particularly in a small country like Malaysia.  For governments:
Be very sure you have the resources to implement your ambitious plans;
particularly in a small country like Malaysia.

John Lim         Natsoft Malaysia
http://www.natsoft.com.my/natsoft  Tel:(60)3 7061216 Fax:(60)3 7061210

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

Date:   Thu, 16 Apr 1998 19:57:16 -0400
From: Edupage Editors <[email protected]>
Subject: AT&T network failure takes a toll on commerce

The failure earlier this week of AT&T's national high-speed network didn't
affect conventional or cellular telephone service, but did manage to disrupt
the portion of the network that carries data for transactions involving
credit cards, bank accounts, travel reservations and the like.  "This sort
of thing is going to happen infrequently, but more and more in the future,"
says the managing director of the Yankee Group.  "And it makes you realize
how vital to the lifeblood of the economy these complex computer networks
have become."  There is no way to gauge how many transactions were forfeited
as a result of the blackout, but analysts are saying the losses are likely
huge, with thousands of businesses affected.  (*The New York Times*, 15 Apr
1998; Edupage, 16 April 1998)

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

Date: Wed, 15 Apr 1998 11:32:46 -0700 (PDT)
From: Brian McMahon <[email protected]>
Subject: AT&T frame relay network effects

Among the many places that felt an immediate and severe impact from the
outage was our Access support group, which handles ISDN and modem dialup
issues.  ISDN and async are both popular backup solutions for FR links, and
lots of people found out in a hurry just how good their backup configs were.
It hailed high-priority "network down" calls all afternoon here, both from
customers who didn't have backup links in place and were scrambling to set
them up, and from customers who had something that they thought would work,
but didn't.

This illustrates an often-overlooked risk.  Backup strategies are no good
unless they actually work when needed.  To be reasonably assured that they
will work when needed, you have to test them.  And (here's the kicker) your
test has to cover the WHOLE THING.  But a *complete* test is (almost
inevitably) disruptive, and risky in itself.  Therefore, the more important
the thing being backed up, the less likely it is to be properly tested.

For instance, the only REAL test of a backup circuit for frame relay
involves shutting down the production FR circuit and seeing if your backup
does the right thing.  Less drastic tests (e.g., can we dial the backup
number) won't tell you if the whole thing will do what you need -- which is
not just to get two routers talking, but to get packets to the appropriate
destinations.  That takes more than just a connection between the two
routers, though.  (You need to make sure that routing updates happen
correctly on both sides, to name just one popular failure point.)

Management is often reluctant to allow full-scale backup tests of critical
links, but those are the ones you want to be especially sure of.  Catch-22.
An incompletely tested backup may even be worse than no backup at all,
because it encourages unwarranted complacency.

Similar problems apply for tape backups, by the way.  The best test of your
backup is a restore, which usually means system downtime.  And if your
restore fails, then what?  You have a scrozzled system, that's what.
Ideally, you'd run your test on a spare system, but not everyone has that
luxury.

(Then there was the customer whose telco turned off their backup ISDN line
"because it wasn't being used...."  Sigh.)

Brian McMahon <[email protected]>, Customer Support Engineer, Cisco Systems

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

Date: Thu, 16 Apr 1998 10:14:17 -0700 (PDT)
From: Fred Cohen <[email protected]>
Subject: HP200 data integrity woes

I just had an amazing conversation with Hewlett Packard's support services.

My HP200 lost it's mind this morning and corrupted the content of it's RAM
disk. I was able to reboot the computer and get a copy of the data onto a
PCMCIA memory card and put it onto other computers at my site. The next step
was to try to recover the content, so naturally, I called HP's support line.

They told me that the palmtop computers they were selling only a few months
ago used formats for their calendar and quicken databases that they did not
know how to read. They claimed that they went directly to their own
engineers who had designed the products and that these folks did not know
what the data formats were - even for their own proprietary file formats!

I guess it's the end of an era when a company with a long reputation for
high quality and reliability doesn't even know how their own products work.

I guess I'll just have to hack their software to get my data back.

 [Added later:]

So I tried to call Intuit to get technical support for data recovery from
corrupt pocket quicken data files, and wouldn't you know...

The Intuit Web page refers you to HP for support of the HP-based quicken
products, but as we already know, HP doesn't know the format information
required for file recovery. So next I tried the number for Intuit's corporate
headquarters as posted on their Web page - 1-800-446-8848

But lo and behold, the area code for the area I live in recently changed
from 510 to 925, so apparently the phone switch at quicken decided I was
calling from Canada. Instead of technical support, I got a new telephone
number to call that was toll-free from Canada - but of course it doesn't
work from the United States.

Next I tried the operator (not the quicken operator - no such option on
their answering machine and buttins like 0 don't work) and got a number in
Mountain View for the real Quicken headquarters - which I called. Naturally,
I finally did get an operator - and I found out that there is a number for
quicken technical people - it's 520-618-7292 - but the operator told me that
it wouldn't help to have the number today (Thursday) since all the employees
were having a party today to celebrate that 15th anniversary of the founding
of the company. I tried anyway and got a fast busy signal.

So my denial of service was caused by:

 A human design failure in my willingness to trust a computer with my
 upcoming appointments.

 A hardware failure in a palmtop computer.

 A software failure in the inability to read the hardware-corrupted files.

 A business failure by HP not having the necessary information on
 their own products.

 An information failure in the Intuit Web page not leading you to
 technical support that knows the answer to your questions.

 An infrastructure failure in the telephone system deciding I am from
 Canada.

 A business model failure in my expectation that during normal
 business hours a company that is supposed to be a major player in a
 financial industry would be available to support their products.
AND
 A support failure in that they were not available to support their product.

The probability of all of this set of events must be astronomically small by
the calculations of any competent risk analysis system, but that just goes
to show you - tightly coupled systems with interdependencies... yada yada
yada

As a postscript, by now I have recovered most of my data -- using an old
fashioned text editor and the normal tools available from Unix. Under DOS
or Windows there was no hope.

Fred Cohen & Associates: http://all.net - [email protected] - tel/fax:510-454-0171

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

Date: Wed, 15 Apr 1998 03:36:33 +0200
From: "Mario Profaca" <[email protected]>
Subject: Webmaster's copyright risks

I do not know if it happens to other www owners, designers and webmasters,
but from time to time some smart fellows, kleptomaniacs, used to come to my
web site to "collect" my animated gifs, although there is a precise and
clear copyright notice at all of my 300+ web pages. The
catch_as_catch_can_minded "webmasters" simply download it and put it on
their web pages. And, of course, they are also claiming copyright for the
entire contents of their web pages...

From time to time I go to a research expedition throughout the Cyberspace
looking for animated gifs stolen from my web site (Mario's Cyberspace
Station <http://mprofaca.cro.net/mainmenu.html>)

In past few years so I found my little animated red devils at others
web pages in Croatia, Slovenia, U.S.A., Japan, Spain, Australia, and Taiwan.

When discovered, I used to send a kind message to the webmaster asking them
to remove my images (animated gifs) from their web site for it is my
copyright. And they always did. Some of them sent to me a sort of apology,
somebody did not answer to my message but simply remove it.

But this last case is the worst of all. This Australian lady-webmaster did
not answer to my messages, although I was tracking her and saw she received
it. And, "of course", she did not remove my animated gif from her web site.

What makes this case the worst is that she put my animated gif novine.gif,
<http://www.powerup.com.au/~hoile/sjh_an11.htm> my little red devil reading
newspaper ("novine" in Croatian language means "newspaper"), at "her"
animated gifs collection even asking her visitors to feel free to use those
images on their web pages (!)

Hope somebody shall learn something out of this case:

The lesson (or just a question) is:
 Is such little theft worth this publicity on Internet?

Mario Profaca, Mario's Cybrspace Station
<http://mprofaca.cro.net/mainmenu.html>

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

Date: Thu, 16 Apr 1998 09:53:26 +1000
From: Stewart Fist <[email protected]>
Subject: Re: Cypherpunks break GSM digital cell phone encryption

Declan McCullagh <[email protected]> quotes TIME Magazine, April 20, 1998
as reporting: " Now crooks scanning the airwaves can remotely tap into a call
and duplicate the owner's digital ID. "We can clone the phones," brags Marc
Briceno, who organized the cracking. His advice: manufacturers should stick to
publicly vetted codes that a bunch of geeks can't crack in their spare time."

My understanding is that they managed to crack the code on the SIM or smart
card, not any radio-transmitted information.  They repeatedly asked the card
to identify itself, and so cracked it by brute force.

The article also says: ``What was even more intriguing than the security
threat, however, was that cracking the code yielded a tantalizing hint that a
digital key used by GSM may have been intentionally weakened during the design
process to permit government agencies to eavesdrop on cellular telephone conversations.''

This has been known for years.  The use of GSM in Australia, for instance, was
blocked on the day of the official launch because the security and police
services wanted an easier code to break.  At that time, I understand, they
just switched encryption off. This was also widely reported in Europe at the
time, and openly admitted.

The original A5 encryption was promoted as being "NATO level security" which
was a bit of overkill for a mobile phone that is probably going to be used
with an insecure wireline link, and often used in public places.

Now it appears that they've cut the 64-bit key down to an effective 54-bit by
adding trailing zeros to make it easier to crack.  It would still be a pretty
healthy sort of encryption even at this level however.

Stewart Fist, 70 Middle Harbour Road, Lindfield, 2070, N.S.W, Australia
+61 2 9416 7458  http://www.theaustralian.com.au/techno/columns/fist.htm

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

Date: Wed, 15 Apr 1998 11:33:45 -0400
From: Chuck Weinstock <[email protected]>
Subject: CFP: Dependable Computing for Critical Applications 7

 Call for papers: Seventh IFIP International Working Conference on
      Dependable Computing for Critical Applications (DCCA-7)
           January 6-8, 1999 in San Jose California, USA

Various versions of the CFP, together with additional information and links,
are available from the DCCA-7 Web page at http://www.csl.sri.com/dcca7 .
The paper submission deadline is 3 August 1998.

General Chair
Charles B. Weinstock, SEI, USA
Program Chair
John Rushby, SRI International, USA
Organized by
 IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance
In cooperation with (pending approvals)
 The Software Engineering Institute, Carnegie Mellon University
 IFIP Technical Committee 11 on Security and Protection
 IEEE Computer Society Technical Committee on Fault-Tolerant Computing
 EWICS Technical Committee 7 on Systems Reliability, Safety and Security

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

Date: 31 Mar 1998 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
.MIL users should contact <[email protected]> (Dennis Rears).
.UK users should contact <[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
  [volume-summary issues are in risks-*.00]
  [back volumes have their own subdirectories, e.g., "cd 18" for volume 18]
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

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

End of RISKS-FORUM Digest 19.68
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.