The RISKS Digest
Volume 19 Issue 11

Monday, 28th April 1997

Forum on Risks to the Public in Computers and Related Systems

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

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

Contents

Java security flaw
Dirk Balfanz/Drew Dean/Edward Felten/Dan Wallach
Mad Cows: Trust the computer
Charlie Lane
Chicken Little, where are you when we need you?
A. Padgett Peterson
Poltergeist beds
Mich Kabay
Microsoft redefines comic strips!
Marc Salverson
Computer Contributes to 747 Tail Scrape
Mike Rogers
Death by Equifax
Chuck Jerian
Re: Hairiest Bug Stories
Henry G. Baker
When software vendors drop products
Mark Seecof
Re: Elevators vs stairs: the risks of distrust
Geert Jan van Oldenborgh
Re: Air-collision risk due to improved --i.e., GPS-- accuracy
Hal Lewis
Re: IVHS: fly-by-wire risks
David Alexander
Risks of what everyone "knows"
A. Padgett Peterson
Re: IVHS vehicles and safety assumptions
Kevin Clifton
Re: Cyberstalker: house invasion a hoax
Michael Shiplett
YOMDSTCS: Yet One More DST-Change Story
Varda Reisner Bruhin
Crypto '97: Information and Registration
Bruce Schneier
Info on RISKS (comp.risks)

Java security flaw

Edward Felten <felten@CS.Princeton.EDU>
Mon, 28 Apr 1997 15:05:58 -0400
We have found a serious security flaw in version 1.1.1 of the Java
Development Kit (JDK) and version 1.0 of the HotJava browser, both from Sun.
These systems allow digitally signed applets.  If an applet's signer is
labeled as trusted by the local system, then the applet is not subject to
the normal security restrictions.  The flaw we found allows an applet to
change the system's idea of who signed it.  The applet can get a list of all
signers known to the local system, determine which if any of those signers
is trusted, and then the applet can relabel itself so it appears to have
been signed by a trusted signer.  The result is that the applet can
completely evade Java's security mechanisms.

JavaSoft says the flaw will be fixed in the next release (1.1.2) of the JDK.
The Netscape and Microsoft browsers are not affected, since they do not
currently support the JDK 1.1 code-signing API.

Dirk Balfanz, Drew Dean, Edward Felten, Dan Wallach; Secure Internet Progr.Grp,
Dept. of Computer Science, Princeton Univ.  http://www.cs.princeton.edu/sip/

  [This is another instance of old RISKS story — a surprisingly large
  portion of the entire infrastructure must be trustworthy, including pieces
  you might not have realized were critical.  (That statement is perhaps
  best thought of as a corollary to Les Lamport's classical statement, ``A
  distributed system is one in which the failure of a computer you didn't
  even know existed can render your own computer unusable.)  PGN


Mad Cows: Trust the computer

Charlie Lane <CLane@iee.org>
Fri, 25 Apr 1997 12:43:11 -0700
This is another anecdote along the lines of previous cases of people
trusting computers.

BBC radio reported this morning that the European Commission had written to
the UK government that it is not happy for mainland UK to export beef based
on veterinary certification of BSE-free herds which itself would be derived
from (paper) records from the farms.  However, Northern Ireland, where they
have apparently had computerised records for some time, is, it seems, a
completely different question.

One gathers that what the computer says about the movements of livestock is
considered much more trustworthy than what mere mortals commit to paper.  Do
any UK farmers read comp.risks?  It would be interesting to hear their views
on perceived reliability of computerisation.

Charlie Lane


Chicken Little, where are you when we need you?

"A. Padgett Peterson" <PADGETT@hobbes.orl.mmc.com>
Wed, 23 Apr 1997 9:44:49 -0400 (EDT)
In the local paper, *Orlando Sentinel*, 23 Apr 1997, in the briefs on the
front page of the Business section (formatting mine):

  INTERNET SITE CONTAINS VIRUS

  A computer virus is circulating on the Internet with the name AOL4FREE.COM
  that destroys files on users' hard drives, the U.S. Department of Energy
  says.  Computer users who download and run the "Trojan Horse" program -
  either from an online service or an e-mail message - will see all the files
  on their hard drive wiped out, the department said.  A Trojan Horse program
  is software a user has to load onto his or her computer.  The program which
  can attack any DOS, Windows 95 or Windows 3.1 operating system - also
  could plant obscene messages in someone's computer system.

As everyone here knows, AOL4FREE.COM started out as Yet Another E-Mail Hoax.
Then the CIAC (DOE) issued an advisory stating towards the bottom that it
was a hoax, but rumoured to be a real trojan and if anyone had one please
send it in.  Within 24 hours they had one.

True, what they received was more in the line of a "Stupid DOS Trick" that
would take less than five minutes to create, debug, rename AOL4FREE.COM (is
really an .EXE but DOS does not care), and send to CIAC but did meet the
letter of what the warning described.  A Self-Fulfilling Request.

And so CIAC issued yet another advisory stating that "Forsooth, it exists"
the assumption being that since they had received a copy, it was widespread.
In the Big Print.  Buried in the small print toward the bottom were certain
disclaimers but who reads that far ? (note - sent a "constructive criticism"
to CIAC immediately).  That the above has been picked up by the media was
inevitable.

The RISK ? People read into postings what they want to and the Internet is
"The sum of all their fears."

Would be funny except for the number of phone calls I know this will cause...

Padgett  http://www.freivald.org/~padgett


Poltergeist beds

"Mich Kabay [NCSA]" <Mich_Kabay@compuserve.com>
Thu, 24 Apr 1997 10:48:28 -0400
COUPLE WIN DAMAGES FOR `POLTERGEIST' BEDS (PA News, 10 April 1997)

Retired UK social worker Frederick Watts, 62, and his wife Jean, spent 2,800
pounds on high-technology beds, which they believed would help his
arthritis.  Instead, they suffered an ordeal that a judge described as like
being haunted by an electronic poltergeist.  They have received more than
4,000 pounds damages after the beds developed a mind of their own and shook
them awake in the middle of the night.

Key points:

* Sleepezee Beautyrest bed was supposed to provide soothing vibrations and
allow head tilt using a remote control.  The bed would shift into gear
randomly at all hours of the day and night and also tilt up suddenly.

* Best guess is that the bed controls were affected by radio-frequency
interference (RFI).

* Judge ruled in favour of the plaintiffs and awarded them 1,000 pounds
(~US$1600).  He ordered the dealer to remove the beds and refund their
purchase cost.

* Judge explicitly stated that in his opinion, makers of complex electronic
equipment should ensure that it is properly shielded against RFI: "If one is
going to market expensive beds, one should take into account the possibility
of interference and guard against it.  It is not as if their home was full
of gadgets like the den of James Bond or Goldfinger.  It is just an ordinary
house."

[This case supports the view that improvements in security will occur as a
result of civil litigation.]

M. E. Kabay, PhD, CISSP (Kirkland, QC) / Director of Education, National
Computer Security Association (Carlisle, PA) / http://www.ncsa.com

  [Put that bed on a French train and you'd have a Waggin' Lit.  PGN]


Microsoft redefines comic strips!

Marc Salverson <marc@colsa.com>
Fri, 25 Apr 1997 12:43:21 -0500
Here's a specific spell-check Risk...
it's short & more towards being amusing than being an actual risk.
Marc Salverson <marc@colsa.com> Network Analyst, Advanced Research Center (ARC)

> This simple piece of Americana!  Microsoft is at it again!  All my life,
> when I read comics, I thought the "zzzz" in those little balloons
> indicated someone was sleeping!  Boy, did I miss the boat, and it took me
> all these years to figure it out!  All that wasted time!

> With the help of Bill Gates (the man who avoided changing the light bulb
> by redefining darkness as the standard), I have, indeed, seen the light.
> Now, I finally know what all those "sleeping" people in those comics had
> on their minds!

> If you want to see what I'm babbling about, start your Microsoft Word, type
> in "zzzz" (without the quotes, of course) and hit the spell check.  Now you
> too can be enlightened.

> Daniel P. Mellen  <dan.mellen@msfc.nasa.gov>

  [I note that MS could be either MicroSoft or Marc Salverson.
  For those of you who do not live in the world of the former
  (beware of the former-in-the-Dell computer), the results reside
  in http://www.csl.sri.com/~risko/zzzz.html — for a while.  PGN]


Computer Contributes to 747 Tail Scrape

Mike Rogers <MikeRogers@compuserve.com>
Fri, 25 Apr 1997 14:56:30 -0400
On 19 Feb, 1996, a Boeing 747-400 Combi aircraft scraped its tail along the
runway when taking off from Toronto Airport.  A contributing cause to this
incident was that the center of gravity (C of G) had been calculated
incorrectly and was outside of the limits for the aircraft.  (The Combi
aircraft is one that carries cargo on the main deck behind the passenger
compartment.)

In summary, the computer-related events were:

1.  The computer program that calculated the aircraft weight and balance had
been used by load agents for several years without any reported errors in
calculations.

2.  The program was modified to account for the size of cargo pallets.  This
modification was not believed to affect cargo carried on the main deck of
the 747-400 Combi.  The program was not fully tested.

3.  The load agent entered the information for the flight in question and
accepted the weight and C of G that were calculated.  While the weight of
the aircraft was calculated correctly, the C of G was calculated as 22.3%
mean aerodynamic chord (MAC) when it was in fact 35% MAC.  The aft limit for
take off was 32.5% MAC.

4.  The aircraft scraped its tail along the runway while taking off.  Also,
during climb, the aircraft was found to be very tail heavy and near full
down stabilizer trim was required to maintain the proper climb.

5.  The flight crew advised the company that they believed that there was an
error in weight and balance of the aircraft because of the way that it was
flying.  At the same time, load agents preparing another flight had
encountered problems with the program and were performing a manual
calculation.  The airline then took immediate action to ensure that no
further flights were dispatched using the modified program.

The scenario was one that is familiar to risks readers: a software change
was made, testing was incomplete, and people accepted the results as the
program had worked in the past.  Fortunately, there were no injuries and the
damage to the aircraft was minor.

The complete report from the Transportation Safety Board of Canada is
available at http://bst-tsb.gc.ca/air/ea96o0030.html.


Death by Equifax

Chuck Jerian <jerian@pocari.engr.sgi.com>
Fri, 25 Apr 1997 14:05:28 -0700
Sometime around 1988 the Social Security administration killed me on their
computer system.  The IRS wanted to know why I was still paying taxes.  It
took my congressman Tom Campbell to get resurrected on that system, they
"Rescinded the record of my death".  In fact, now it seems that I have
never been dead.

This is a better result than in the movie "Brazil" — where Mr Buttle was
killed to match the government records.

I can't get Sprint Long Distance service, and I almost couldn't join the
credit union; I can't get a Bank America checking account.  That's because
Equifax Financial Information has a copy of the old Social Security
information.  This information is confidential but the Equifax 800 number 1
888 395 3134 proudly says we have real government records from Social
Security.  We won't take your word that you are alive.  Social Security
(Sunnyvale Office) tells me my records are secure.

Perhaps Equifax has obtained (stolen?) old records from some poor underpaid
public servant.  Or perhaps they are lying to me about the source of their
information.

They don't talk to dead people though, or give them any more information.
Perhaps if I mail them a statement of benefits and earnings from social
security, an original, they may reconsider that I have died.

The Social Security office in Sunnyvale said to me, "This is a record for
you use only, just to evaluate your Social Security Benefits, do not give it
to anyone."  "If they got our records before, ask them to get them again the
same way".

By the way, a search of yahoo finds that one can buy equifax records from
various information vendors with a membership fee and a small amount per
record, including your current job.

  [Later message appended:]

I've done more looking on the Internet; why ask a government official when
you can use hotbot or yahoo?

Your privacy ends when the government thinks you're dead.  E.g., check out
http://www.ancestry.com/ssdi/advanced.htm for the Social Security Death
Index.  Everyone who the government issues a social security number to who
dies is added to a Social Security Death Index which is published on CD Rom.

Now death is irreversible at present, so one can imagine a procedure where
we only add new dead people to the list.

What happens if someone is killed in error?  You can remove the person from
the list, but most people probably will just add new dead people to their
list who aren't on it already.  Making a person alive is not typical.

I must have been published on a previous Social Security Death Index, and
now that I am alive again so to speak, I am not on any current or recent
such index.  Still, anyone who has the old sets who just adds people to the
list will think I'm dead, and this has many annoying consequences.

Perhaps a system that marks all errors explicitly would be handy, so that
users of the data can make a correction.

Yours Resurrected, Chuck Jerian


Re: Hairiest Bug Stories (Sapovits, RISKS-19.10)

Henry G. Baker <hbaker@netcom.com>
Tue, 22 Apr 1997 16:16:57 -0700 (PDT)
You might enjoy my recent ACM SIGPLAN Notices article on this very subject
of programs that are too complex and should be rewritten from scratch: 'When
Bad Programs Happen to Good People', ACM SIGPLAN Notices 32, 3 (March 1997),
27-31. It is also available on the web at:
  ftp://ftp.netcom.com/pub/hb/hbaker/sigplannotices/gigo-1997-03.html

Henry Baker  http and ftp://ftp.netcom.com/pub/hb/hbaker/home.html


When software vendors drop products

Mark Seecof <Mark.Seecof@latimes.com>
Tue, 22 Apr 1997 17:39:21 -0700
[After reading Peter Mellor's message about PARSLEY, people may pepper you
with follow-ups.  I hope those don't cumin so fast that you give them a
chile reception.  I don't want to wine--I may have been hitting the oregano
brownies too hard--but I think many of us Dill-bert followers have saffroned
from the opposite problem, not lack of up-*dates* but...]

The opposite problem to the software vendor who changes the name of a
product just to abrogate update agreements and force customers to repurchase
the base functionality with the latest amendments is the software vendor who
just drops a product entirely.  For example, I use Lotus' Improv
spreadsheet.  No doubt for good business reasons, Lotus abandoned that
product (emitting, as vendors will, some insincere remarks about
"incorporating its features into our other products," 1-2-3 in Improv's
case).  If Lotus doesn't want to spend development effort on Improv anymore,
well, okay.  But they won't even sell me more licenses to use the code I
have on new PC's.  (They also won't give me or anyone else the source code
to repair and maintain the product.)  This is crazy.  I suppose it's a
computer echo of an old RISK--can't get a new copy of a book if the
publisher stops reprinting it--but it seems much more irritating when the
copying is trivially easy.  People have discussed the problem in the context
of customized systems--and proposed damage-limiting measures like "source
code in escrow"--but we don't seem to have a suitable mechanism to protect
people from the withdrawal of mass-market software.


Re: Elevators vs stairs: the risks of distrust

Geert Jan van Oldenborgh <oldenbor@knmi.nl>
Wed, 23 Apr 1997 17:33:53 +0200
In the last few issues a few people commented on the RISKs of trusting (new)
technology, citing the elevator vs. stairs.  The exact numbers escaped me,
but elevators are a few orders of magnitude *safer* than stairs, which are a
major cause of injury and death.  Just because you are used to stairs and
feel more in control does not mean it's safer.  The same holds for a
surprising number of issues.

Geert Jan van Oldenborgh  work: oldenbor@knmi.nl  else: gjvo@xs4all.nl

  [A problem with (particularly old) elevators is that you may get stuck
  between floors.  That does not happen very often on stairs.  PGN]


Re: Air-collision risk due to improved --i.e., GPS-- accuracy

hal lewis <hlewis@physics.ucsb.edu>
Tue, 22 Apr 1997 15:13:15 -0700
The observation that there is an increased risk of mid-air collision from
improved navigational accuracy simply completes an illogical process that
began more than fifty years ago.

There really aren't many aircraft in the sky. If you count an active
airspace about five miles high (25000 ft) and 3 million square miles over
the United States, you end up with an airplane roughly every ten thousand
cubic miles, so random flying produces a fantastically low collision
probability. (Work it out.) Of course the aircraft aren't uniformly
distributed, but I have personally flown for many hours across the country
without seeing another aircraft, except near busy airports (where control is
indeed important---in the end everyone is aiming for a runway). The sky has
three dimensions, and air traffic control in the vast majority of airspace
has at best a neutral impact on safety.

So the FAA and its predecessors over the years progressively eliminated two
of the three protective dimensions through what is called air traffic
control. Aircraft are now required to fly largely (not always) on prescribed
tracks (airways), changing the horizontal plane to a collection of lines
(goodbye one dimension), and at prescribed discrete altitudes, often integer
multiples of a thousand feet (goodbye another), thereby greatly increasing
the probability of collision. To reduce this iatrogenic collision risk we
have then created an elaborate air traffic control system, which almost
reduces the collision probability to what it would have been if aircraft
flew randomly---except near busy airports. The purpose of the system is not
to reduce collision probability, but to make the controller function more
important.

Of course I've indulged a little poetic license in the above, but the
fundamental error of cramming the aircraft into an infinitesimal fraction of
the available airspace persists to this day and makes no safety sense. It
does make the controller's job easier.

When I learned to fly long ago the principal radio navigational aids were
the famous L/MF A/N ranges (the transmitters emitted Morse code for A
(dot-dash) and N (dash-dot), interlocked in space and time in such a way
that if you were on a specific radial line you heard neither letter, but a
continuous tone). All sensible pilots knew that it is safer to be a bit
sloppy about following that line, which could be inhabited by other
aircraft. Over the years we have steadily thrown away the bulk of the
safety-enhancing airspace, while increasing the role of regulation, and now
we have occasional mid-air collisions at altitude in an essentially empty
sky. It will get worse.

Hal Lewis


Re: IVHS: fly-by-wire risks (Hoffman, RISKS-19.10)

David Alexander <davea@caplin.demon.co.uk>
Wed, 23 Apr 1997 16:37:37 +0100
Alan Hoffman's posting brings back some painful (literally) memories.
I suffered from this happening:

I flew F4 Phantoms for the RAF and back in the early 80's I was on approach
when I suffered total electrical failure. Without the 'wiggly amps' I lost
the use of the 'Stability Augmentation system' and an uncontrollable right
roll element occurred. There was insufficient height (approx 700' with a
rate of descent of > 200' per minute (F4s glide in the way that bricks
don't) to deploy the RAT [*] and I had to eject. I was lucky to escape with
my life, spent 6 months in hospital and rehabilitation, was discharged and
ended up driving a keyboard instead....

David Alexander  Caplin Cybernetics Corporation  Windmill Business Village
Brooklands Close, Sunbury-on-Thames Middlesex TW16 7DY, England  01932 778172

  [* Added note: RAT stands for Ram Air Turbine...you pull a handle and a
  miniature turbine pops up from the top of the port engine cowling and
  generates limited power for those get-you-home systems.  The only trouble
  is it takes time to deploy, spin up and recycle the circuit breakers, so
  there's a minimum altitude for use, which I can't now remember after 15 or
  so years.  David]


Risks of what everyone "knows"

"A. Padgett Peterson" <PADGETT@hobbes.orl.mmc.com>
Tue, 22 Apr 1997 16:40:08 -0400 (EDT)
Re: IVHS vehicles and safety assumptions (Mintz, RISKS-19.08)

> ... It seems the newer jets (e.g., F-22) are NOT designed to be
> aerodynamically stable ...

Well, not quite. "unstable" in this context does not mean quite the same
thing as you might expect: in simplest terms when you pull the stick back in
a "stable" airframe, the nose goes up. In an "unstable" aircraft, the tail
goes down. Bit like a forklift. What this means is that it responds to
control input faster, quite valuable in an attack aircraft. Does make
carrier takeoffs a bit chancy though.

Is just the latest example of what has been known for years: air combat is
unsafe at any speed and if you tell a fighter pilot that you can provide a
faster turn rate but there is going to be some risk, guess what the decision
will be.

Padgett

ps the Titanic was "unstable" also and look where it got her...


Re: IVHS vehicles and safety assumptions (Mintz, RISKS-19.08)

"Kevin Clifton" <kev@vela.ca>
Tue, 22 Apr 1997 16:04:37 -0600
The concept of a combined vehicle/highway system that can be 'trusted' to
stop a vehicle in danger of collision raises some interesting ideas.

Take the deer that jumped in front of my car on the highway last night: had
I a cup of hot coffee in my hand, or been eating, or similarly distracted, I
probably would have hit the poor beast.  But in a world where my intrepid
car were charged with accident avoidance, I could not only drink my coffee,
but perhaps type some e-mail, send a few faxes, and still have a hand free
to yap on my cell phone.  Truly, this would be a grand invention, allowing
me to devote even fewer mental cycles to directing my vehicle down the
road... although not likely saving me from Bambi.

What is really interesting is the idea of a sudden obstacle: unlike a
pedestrian, who would slowly approach the road, the deer suddenly imposed
itself in my path, well inside my stopping distance.  Only our good luck
prevented a collision - but how would my 'intelligent' vehicle react?
Given some sort of radar-based collision detection and avoidance, I can see
great sport for bored pranksters, dropping sheets of aluminum foil from
overpasses into the path of 'intelligent' vehicles.  Perhaps dumping a few
kilos of shredded foil into traffic would be fun, in order to really foul
the works.  Or perhaps that pesky 'intelligent' police car behind me could
be tricked into emergency braking with a well-timed burst of chaff... or
perhaps he could apprehend me by 'spoofing' my collision-detection gear.

One thing is certain, this would be a genuine, fundamental shift in the
physics ('laws'?) of traffic.  It would be tremendously interesting to watch
as drivers attempt to adapt to this new traffic paradigm.

Kevin Clifton,  Senior Consultant, Vela Information Management Consultants
Saskatoon, Sk., Canada  306.668.5214 (V)/ 306.668.5216 (F)


Re: Cyberstalker: house invasion a hoax (Re: Pfeifle, RISKS-19.10)

michael shiplett <walrus@ans.net>
Tue, 22 Apr 1997 19:34:02 -0400
While ``obvious'' possibilities often go overlooked, I don't think that was
necessarily the case here.

In an MSNBC report I saw Sunday (first time I had heard the story of the
``spooky house''), the son denied on camera that either he or his friends
were behind the ruse. The mother made a comment about this being one of the
first scenarios they (she and her husband) had considered. Perhaps MSNBC
reporters just don't have the impact of the local constable...

michael


YOMDSTCS: Yet One More DST-Change Story

SweetGeek {Varda Reisner Bruhin} <varda@varda.org>
Tue, 22 Apr 1997 19:29:38 -0400 (EDT)
A different spin on the MS/DST-change story (and one I haven't heard from
anyone else):

My husband uses both W95 and NT on his PC at work.  The Monday after the
switch, he boots up into NT, it kindly asks him if he wants to change to
Daylight Time, he says yes, it does...

Later that day, he reboots because he has to use W95 for a particular app...
W95 doesn't "remember" that the change was already made via NT (although the
system clock was indeed, of course, changed machine-wide).  Bob says yes at
W95's prompt, not knowing whether that's needed or not...

Turns out, of course, that the net result was a "double-adjustment"...  In
this case, since it was Bob who made both changes, he immediately realized
the problem and fixed it — but if it had been 2 different users, (perhaps)
no one would've known/noticed (at least for a while), and the box would've
had the wrong time...

(Yes, I know this one's minor compared to most of the others reported
here; but it's still yet another bug...)

Varda Reisner Bruhin   <varda@varda.org>   http://www.varda.org/~varda/


Re: GMT and UTC (RISKS-19.10)

michael shiplett <walrus@ans.net>
Tue, 22 Apr 1997 19:28:11 -0400
US NIST has an explanation of the difference between GMT and UTC at
    http://physics.nist.gov/GenInt/Time/world.html

In brief, GMT is defined relative to the motion of the earth while UTC is
based on atomic clocks.

As a related issue Nick Maclaren recently noted in comp.protocols.time.ntp
leap seconds create the problem that ``to convert `Unix times' to real times
cannot be done without knowing both the time and when it was stated''.
[dejanews Message-Id: 5ibbme$odq@lyra.csx.cam.ac.uk].

michael

  [Huge number of messages on this topic.  I could not run them all.  PGN]


Crypto '97: Information and Registration

Bruce Schneier <schneier@counterpane.com>
Fri, 25 Apr 1997 15:19:08 -0500
CRYPTO '97  -  17-21 August 1997  -  Santa Barbara, California, USA

Crypto '97 is the 17th international conference on cryptology held at the
University of California Santa Barbara, sponsored by the International
Association for Cryptologic Research (IACR).

Information, a registration form, a list of accepted papers, and other
sundry information can be found at http://www.iacr.org.  Or you can send
e-mail to schneier@counterpane.com and receive general information and a
registration form.

Bruce Schneier

Please report problems with the web pages to the maintainer

x
Top