The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 19 Issue 59

Friday 13 February 1998

Contents

o Prisoner released due to program design flaw
Richard Fahey
o California legislation proposed to limit Y2K liability
Terry Carroll
o Report on ATC Outages
Peter B. Ladkin
o Markus Kuhn and Ross Anderson's Soft Tempest
Martin Minow
o High-tech car AA call-outs
Pete Mellor
o Re: Crash of A-320, Strasbourg
Pete Mellor
o Re: robots.txt
Bertrand Meyer
o Re: Dangerous handling of null variables
Anthony W. Youngman
o Re: Netscape, Fortify & the NSA
Vin McLellan
Ian Goldberg
o Privacy on the Line, Diffie and Landau
Martin Minow
o REMINDER: ISOC 1998 Network and Distributed Security Symposium
Dave Balenson
o Info on RISKS (comp.risks)

Prisoner released due to program design flaw

"Fahey, Richard (CDSI)" <FaheyR@cobra.brooks.af.mil>
Mon, 02 Feb 98 08:43:00 CST
Sorry that I do not have much specific information on, or identifiable
sources for, this story - it was reported in my local newspaper (San Antonio
Express-News), and my copy was recycled before I thought of posting it here
(being a new RISKS reader - I promise to do better next time!). Some of the
details may be misremembered, but the gist is correct.

Seems like a Dallas prisoner was temporarily transferred from one prison to
another (from a federal prison to a state prison?) so that he could serve as
a witness in somebody else's trial. Apparently, one of the computer systems
involved recognized that he was on "temporary assignment" and absent from
the original prison - all well and good, except that after 30 days of
absence the system defaulted to flagging him as no longer being incarcerated
in the original prison. Once the trial in which he was a witness ended, he
was released from the "loaning" prison and was released. Although he was
eventually put back in prison, since this man was in for a dangerous crime,
this episode is pretty alarming.

Richard Fahey


California legislation proposed to limit Y2K liability

Terry Carroll <carroll@tjc.com>
Fri, 30 Jan 1998 17:07:28 -0800 (PST)
This bill, if enacted, would limit recovery in actions for damages resulting
from a "computer date failure," i.e., Y2K failures.  Under the bill (if
passed), in a lawsuit for a Y2K bug, the plaintiff could recover only the
reasonable costs of correcting the bug, and damages resulting from bodily
injury.

As I read this, if, for example, a bug in a money management program caused
the system to send out checks in appropriately, you would not be able to sue
the software company to recover the money you lost (assuming you couldn't
get a refund from the improperly paid parties), and you wouldn't be able to
recover for the check-bounce fees imposed by your bank because your balance
was not sufficient to cover all the incorrectly-issued checks.

The bill seems to apply to contracts as well as to torts (such as
negligence), and there's no provision specifically limiting it to contracts
entered into after the date of enactment (however, it does permit a contract
to override this provision and expressly allow for further damages).

I've added the bill to my Copyright Resource Page (a misnomer -- I now have
a lot of stuff besides copyright, this being one example) at
<http://www.aimnet.com/~carroll/copyright/faq-home.html>.  I have both a
text copy and a PDF version (for those who would like the official
printings).

Here's the most pertinent part of the bill.  For the rest (definitions,
clarifications, etc.), please see the above-referenced URL.

  (a) Notwithstanding any other provision of law, in any
  action to recover damages resulting directly or indirectly from a
  computer date failure, including any action based on an alleged
  failure properly to detect, disclose, prevent, report on, or
  remediate a computer date failure, the damages that may be recovered
  shall be limited to either or both of the following, according to proof:
    (1) Any damages resulting from bodily injury, excluding emotional
  injury, to the plaintiff proximately caused by the defendant's conduct.
    (2) Any costs reasonably incurred to reprogram or replace and
  internally test the relevant computer system, computer program or
  software, or internal hardware timer, to the extent those costs are
  incurred as a proximate and direct result of the defendant's conduct.

Terry Carroll  Santa Clara, CA  carroll@tjc.com


Report on ATC Outages

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Wed, 11 Feb 1998 12:12:17 +0100
Outages (complete failures, a distinct from degradation of service due to
partial failures) of air traffic control computer systems, particularly
those at the U.S. Air Route Traffic Control Centers (ARTCCs) have been a
subject of continuing interest in RISKS (a keyword search on the archive
showed well over a hundred references, many of which refer to partial
failures or outages).

The U.S. National Transportation Safety Board (NTSB) prepared a report in
January 1996 (NTSB/SIR-96-01) on ATC system outages, dealing with incidents
between September 12 1994 and September 12 1995 and assessing the FAA's
modernisation program. There is a significant `legacy' problem with some of
the systems, and the scope of the FAA's Advanced Automation System (AAS),
which has been in development since 1981, was significantly revised
downwards when the contract for the `be all to end all' system was cancelled
by the FAA in mid-1994 because of continual schedule slippage and cost
overruns. The NTSB report discusses the architecture of the display systems
in the ARTCCs, the nature of the outages (4 power failures, 7 computer
problems), and the FAA's upgrade plans (which crudely amount to replacement
of legacy systems in an evolutionary manner, rather than a redesign). In the
11 incidents, only one operational error (loss of separation) was reported,
although all involved degradation of service (i.e. delays) ranging from the
trivial (1) to the extreme (485). The report also notes that many
controllers do not appear to be aware of the full range of functions still
available to them during partial degradation.  The board concludes that the
system remains `very safe', even though the failures have a significant
economic impact, but is concerned about the safety implications of the
increasing number of failures of the older equipment.

The AAS is considered a `high-risk program' by the U.S. General Accounting
Office (GAO), which has produced a series of reports, the latest from 1997
being on the WWW. A `high-risk program' is one at `high risk for waste,
fraud, abuse and mismanagement' (!).

The NTSB report is now available on the WWW in the compendium
`Computer-Related Incidents with Commercial Aircraft', which also contains
links to the GAO reports: http://www.rvs.uni-bielefeld.de -->
`Computer-Related Incidents..' --> `U.S. Air Traffic Control Center Outages
and the Advanced Automation System'.

Other recent additions to the compendium include the Rapport Preliminaire of
the French DGA on the A330 test flight accident in Toulouse (Mellor,
RISKS-16.19; Jackson, Ladkin, 16.22, Ladkin, 16.23; Hollnagel, 16.31;
Ladkin, 16.39); the final report on the Lauda Air B767 accident (Leyland,
11.78; Grodberg, Kopetz, Morris, Philipson, 11.82; Neumann, 11.84; Mellor,
11.95; Leveson, 12.16; Leveson, 12.69); the 1985 China Air B747 accident
(Trei, 3.79); and the 1983 Eastern Airlines L1011 Common Mode Failure
incident (not itself computer-related, but I believe relevant for
understanding common mode failures resulting from imperfect maintenance, as
in the 1996 Aeroperu B757 accident, Ladkin, 18.51; Neumann, 18.57; Ladkin,
18.59).

I am very grateful to Hiroshi Sogame of the Safety Promotion Committee of
All-Nippon Airways for his public service in preparing various of these and
other reports for the compendium.

Peter Ladkin  ladkin@rvs.uni-bielefeld.de  http://www.rvs.uni-bielefeld.de


Markus Kuhn and Ross Anderson's Soft Tempest

Martin Minow <minow@apple.com>
Sun, 8 Feb 1998 18:34:18 -0800
An interesting article on "Software Tempest" -- here's a short
notice posted by Peter Gutmann to the Cryptography e-mail list:

> There's a fascinating paper on software anti-TEMPEST (and, in general,
> TEMPEST-related) measures by Markus Kuhn and Ross Anderson available
> from http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf.  It describes
> both how to make TEMPEST eavesdropping difficult using only software,
> and how to build TEMPEST-friendly software.

A much longer and more detailed announcement (with some background notes by
one of the authors) was posted by John Young to the Cypherpunks e-mail list.

> To: ukcrypto@maillist.ox.ac.uk
> Subject: It is really me - the story of Soft Tempest
> Date: Sun, 08 Feb 1998 15:09:40 +0000
> From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>

$The Washington Post$ gives a highly distorted account of some very
important scientific work we have done. I suggest that list members read our
paper - <www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf> - for themselves before
getting carried away.

The story is as follows. Bill G gave our department $20m for a new building,
and his people said that what they really wanted from our group was a better
way to control software copying.  So it would have been rather churlish of
us not to at least look at their `problem'.

Now the `final solution' being peddled by the smartcard industry (and
others) is to make software copying physically impossible, by tying program
execution to a unique tamper-resistant hardware token. We wouldn't like to
see this happen, and we have already done a lot to undermine confidence in
the claims of tamper-proofness made by smartcard salesmen.

So Markus and I sat down and tried to figure out what we could do for the
Evil Empire. We concluded that

(1)  large companies generally pay for their software;
(2)  if you try to coerce private individuals, the political backlash
     would be too much;
so
(3)  if the Evil Empire is to increase its revenue by cracking down on
     piracy, the people to go after are medium-sized companies.

So the design goal we set ourselves was a technology that would enable
software vendors to catch the medium-sized offender - the dodgy freight
company that runs 70 copies of Office 97 but only paid for one - while being
ineffective against private individuals.

We succeeded.

In the process we have made some fundamental discoveries about Tempest. Army
signals officers, defence contractors and spooks have been visibly
flabberghasted to hear our ideas or see our demo.

In the old days, Tempest was about expensive hardware - custom equipment to
monitor the enemy's emissions and very tricky shielding to stop him doing
the same to you. It was all classified and strictly off-limits to the open
research community.

We have ended that era. You can now use software to cause the eavesdropper
in the van outside your house to see a completely different image from the
one that you see on your screen. In its simplest form, our technique uses
specially designed `Tempest fonts' to make the text on your screen invisible
to the spooks. Our paper tells you how to design and code your own.

There are many opportunities for camouflage, deception and misconduct.  For
example, you could write a Tempest virus to snarf your enemy's PGP private
key and radiate it without his knowledge by manipulating the dither patterns
in his screen saver. You could even pick up the signal on a $100 short wave
radio. The implications for people trying to build secure computer systems
are non-trivial.

Anyway, we offered Bill G the prospect that instead of Word radiating the
text you're working on to every spook on the block, it would only radiate a
one-way function of its licence serial number.  This would let an observer
tell whether two machines were simultaneously running the same copy of Word,
but nothing more. Surely a win-win situation, for Bill and for privacy.

But Microsoft turned down our offer. I won't breach confidences, but the
high order bit is that their hearts are set on the kind of technology the
smartcard people are promising - one that will definitively prevent all
copying, even by private individuals. We don't plan to help them on that,
and I expect that if they field anything that works, the net result will be
to get Microsoft dismembered by the Department of Justice.

Meantime we want our Soft Tempest technology to be incorporated in as many
products as possible - and not just security products!

So to Rainier Fahs, who asked:

> If these rumors are true, I guess we will face a similar discussion on
> free availability in the area of TEMPEST equipment. Does privacy
> protection also include the free choice of protection mechanism?

I say this: our discovery, that Tempest protection can be done in software
as well as hardware, puts it beyond the reach of effective export
control. So yes, you now have a choice. You didn't before,

Ross Anderson

  [Tempest foo-gets! PGN]


High-tech car AA call-outs

Pete Mellor <pm@csr.city.ac.uk>
Sun, 18 Jan 1998 11:41:09 +0000 (GMT)
>From the $London Evening Standard$ of 18 Jan 1998:

  Drivers are defeated by clever cars

  Breakdowns caused by lost keys and confusion over sophisticated car
  security systems overtook flat tyres for the first time in an analysis of
  calls to the AA.  Of the 4.5 million call-outs last year, the most,
  825,424, were due to flat or faulty batteries, followed by 269,070 because
  alarm systems or locks failed.

Peter Mellor, Centre for Software Reliability, City University,
London, p.mellor@csr.city.ac.uk

  [In Britain, AA is presumably the Automobile Association.  PGN]


Re: Crash of A-320, Strasbourg (Siniakov, RISKS-19.58)

Pete Mellor <pm@csr.city.ac.uk>
Sat, 31 Jan 1998 16:23:00 GMT
Is this a joke? If so, how did it get past our trusty moderator?
(Book now and avoid the April 1st rush! :-)

The crash of the A320 on final approach to Strasbourg in 1992 was most
probably due to the fact that the crew were using the "vertical speed" mode
of the autopilot to control their descent instead of the "flight path angle"
mode, and somehow failed to notice this. The result of this "mode confusion"
was that they descended three times as fast as was shown for the approach
path on the plates for Strasbourg.

This is only the "most probable" cause, since there are still uncertainties
about the last moments of the flight.

I summarised the findings of the accident report (and included some
speculations of my own) in my paper:- ``CAD: Computer-Aided Disaster'', High
Integrity Systems, Vol. 1, Iss. 2 (Oxford University Press: 1994) pp 101-156

I will leave it to others who have studied the relevant accidents to comment
upon the relevance of the "resonance characteristics of both the solar
system and outer space" to those.

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422 p.mellor@csr.city.ac.uk

  [Ah, yes, thanks to all of you who responded so strongly to this item.  PGN]


Re: robots.txt (Meyer, RISKS-19.57)

Bertrand Meyer <bertrand@eiffel.com>
Sun, 1 Feb 98 15:45:41 PST
I continue to receive mail on my robots.txt comments.  Those who disagree
with my criticism are (I must say) the majority, but not by far unanimity,
and there are interesting nuances in the disagreements.  I found all the
contributions very enlightening.

I will continue to add all messages received (unless contributors specify
otherwise) to the Web page, which is now in place:
  http://www.eiffel.com/private/meyer/robots.html

Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel
<Bertrand.Meyer@eiffel.com>, http://www.eiffel.com


Re: Dangerous handling of null variables (Jeays, RISKS-19.58)

"Anthony W. Youngman" <wol@thewolery.demon.co.uk>
Sun, 1 Feb 1998 00:45:31 +0000
> The treatment of null values is arguably reasonable once it is
> understood - null values simply fail all comparisons with non-null
> variables.  ...

Nowhere does it tell us which language. Java, VB, what? I think it's
rather important to know. In all the languages I know there is no
genuine null value, just something along the lines of "equate null to 0"

Anthony W. Youngman  wol@thewolery.demon.co.uk

  [Lots of other messages on this topic.  TNX.  PGN]


Re: Netscape, Fortify & the NSA (Wilson, RISKS-19.57)

Vin McLellan <vin@shore.net>
Tue, 27 Jan 1998 03:00:13 -0500
John Wilson <jowilson@mtu.edu> worried about what unscrupulous folk,
unwilling to acknowledge or respect interests other than their own, might
inflict on the public now that Netscape has decided to release the source
code for the Netscape 5.0 browser.

What Mr. Wilson overlooks, perhaps, is what some unscrupulous folk,
unwilling to acknowledge or respect interests other than their own, have
already done to tens of millions of Internet users -- and what they were
able to get away with largely because Netscape's source code was
unavailable.

By forbidding the export of web servers and browsers with strong crypto to
non-American users (with a few narrow and humiliating exceptions,) US
policymakers have left the commercial, professional, and personal
correspondence and web-based transactions of millions of non-American
citizens all but naked to eavesdropping by criminals (petty and organized,)
industrial spies, gossip-mongers, aggressive office-pols, wannabe
blackmailers, rogue cops, managers with feudal delusions, and curious 14
year-olds with access to a contemporary PC (or -- if they they want to pop
secrets free within hours -- the computational resources of a typical
college computer lab.)

The image and reputation of the US, and of American engineering and
technology, has suffered grievous harm so as to allow the NSA to gain what
transient enlightenment it could from it's world-wide "Echelon" sweeps of
the data lines and communications spectrum. Reaction to the scheduled
release, today, of a report by the Civil Liberties and Interior Committee of
the European Parliament on the NSA's systematic snooping on all European
telephone, fax, and digital communications may indicate how bitter that
resentment has become.  (Swedish parliamentarians were outraged recently to
discover that the confidentiality of encrypted traffic on their Lotus Notes
system was apparently dependent on the self-restraint of the NSA -- which
demanded partial access to the Notes crypto-key before the product was
shipped abroad.)

The web -- and in particular, Netscape's browser, due to its popular success
and widespread use -- has become the focus of much concern and attention
from those who believe that privacy and optional confidentiality are
fundamental to the dignity and liberty of any man or woman, anywhere.  SSL,
the encrypted channel built into the WWW spec, offered the first encryption
systems that was universally available, to the far reaches of the global
Internet.  The problem was, only Americans got strong (128-bit) crypto.  US
export policy allowed vendors to ship only weak easily-broken 40-bit crypto
in browsers exported to non-Americans, so the browsers freely downloaded off
the Microsoft and Netscape ftp sites world-wide were almost always insecure,
providing security of poor quality by design and government fiat.

Non-American webservers can offer strong-crypto alternatives to the
innovative American products which paced the technology -- and even the
crippled export-level American webservers can have their weak SSL encryption
enhanced by java applets (Brokat's Xpresso <www.brokat.de>) or
proxy/translators (C2's SafePassage <www.c2.net>) -- but it was only a few
months ago that Farrell McKay's remarkable freeware product, Fortify, became
widely available. <http://www.fortify.net>

Fortify allows anyone anywhere to upgrade a Netscape browser (Navigator v3
or Communicator v4) with weak or export-strength crypto into one with the
128-bit SSL capabilities for confidentiality (and secure e-commerce) that
Americans take for granted when they do business on the web.  An executive
with one of the big international auditing firms told me a month ago that
Fortify is "all over Africa," particularly in banking.  "It's free, and it's
legally available from its British website.  They'd be idiots not to use it!
I recommend it to all my international clients."

McKay's program installs itself directly in the Netscape browser to upgrade
it's SSL code, so that anyone with a export-quality browser can get a
128-bit strong-crypto link when he connects to a webserver that is itself
capable of establishing a strong SSL connection.

Unfortunately, McKay's magic did not extend to strengthening the S/MIME
crypto has added encryption for electronic mail to recent versions of both
the Netscape and the Microsoft browsers.  McKay gave international users of
Netscape a secure 128-bit SSL channel, but neither he -- nor, apparently,
anyone else -- has been able to do the same with the S/MIME routines which
were also crippled and weakened to 40-bit crypto, by government order,
before export.

The web is popular, but e-mail is still the "killer app."

Strong SSL, now universally available, enables many types of form-based
transactions on the Web -- but freely-available strong S/MIME for private
mail will break the dam.  Some dream it could change the world.  Farrell
McKay fervently believes that getting the Netscape source in circulation
among those who can pick it apart is the gateway to a future in which
everyone can expect their mail to be confidential (at least until some local
lawmen shows up, with proper authority to demand access from one of the
correspondents.)

"I live in the hope that there will be entire armies of enthusiastic
programmers all busily building strong crypto facilities into the v5.x
releases," he exulted in a note he sent me yesterday from Australia. "This
move really opens up a huge number of possibilities for the international
community."

Many American think that's just great, on balance. ("All men are created
equal," and stuff like that.)  Virtually all non-Americans have no doubt.
Much of the world is hoping that electronic commerce will be the backbone of
the 21st Century economy -- and you practically have to rate a limousine in
Washington, D.C., before you can believe that international finance and
trade will go online if the merchants, bankers, and businessmen believe that
American spooks have rigged a party-line, and may or may not be listening.

Having Netscape browser source-code in circulation won't change much
overnight, of course. Given US restrictions on the export of privacy
products, the release of the Netscape source code will doubtless be
restricted too.  Netscape's cryptographic modules will either not be
released in source, or will be forbidden for export. Still, with all _but_
the Netscape privacy code accessible to clever programmers world-wide, it
becomes all but certain that -- as Netscape cryptographer Tom Weinstein
suggested yesterday -- "some enterprising individuals outside the US (will)
replace the missing pieces."

Odd what Americans have to do to get a quality product to the world market,
huh?


Re: Netscape, Fortify & the NSA

Ian Goldberg <iang@cs.berkeley.edu>
Sun, 1 Feb 1998 15:45:39 -0800
Actually, the moment I started playing with McKay's wonderful program, I
noticed that it didn't activate strong S/MIME, so I fixed it.  Although I am
(currently) in the US, I use Fortify because (at least the last I checked)
there was no strong-crypto version of 4.04 for Linux.

Now, I don't actually _use_ S/MIME, so I can't say for sure if it works, but
the option to encrypt email with strong crypto is certainly presented to the
user in my version.  When I told McKay about this, he said that he had done
a similar thing, and it was in testing.

Another interesting point about Fortify: Fortify contains _no crypto_.  The
version of Netscape that is internationally available actually has
_full-strength_ crypto in it.  I believe this has something to do with the
deal that was made that will allow full-strength crypto to be exported, but
only if it is used with special servers (like some banks).

The Netscape binary contains a table that lists all the available crypto
routines, and along with each is a flag that indicates whether it should
always be available (for the 40-bit stuff) or only available when talking to
the special servers (for the good stuff).  There is also some sort of
integrity check to make sure you don't mess with the table.

All Fortify does (as far as I can tell) is disable the integrity check, and
then set all the SSL crypto routines in the table to "always available".  It
is straightforward to make it set the S/MIME routines in the same way.

Now, of course, I can't _send you_ my version of Netscape with the strong
S/MIME.  It's very unclear to me whether I can send you my patched version
of Fortify (all it does is set some bits in a table, remember).  And, of
course, I'm not 100% positive the S/MIME is working.  On the other hand, if
someone who uses Linux (though the fix should be trivial to port to other
systems) wants to email me, and can convince me that he is a U.S. or
Canadian citizen, understands the EAR regs, will not violate them, and will
report on the usability of strong S/MIME, then I'll send my patches to
Fortify along.

   - Ian


Privacy on the Line, Diffie and Landau

Martin Minow <minow@apple.com>
Fri, 30 Jan 1998 18:23:00 -0800
Risks readers may be interested in a new book on the politics of privacy:

    Whitfield Diffie and Susan Landau
    Privacy on the Line - The Politics of Wiretapping and Encryption
    Cambridge: The MIT Press
    ISBN 0-262-04167-7

This book provides an overview of cryptographic history, particularly as it
has influenced -- and been effected by -- public policy, national security,
and law enforcement. It not a technical book but, specifically, a book about
the politics of cryptography. From the book jacket:

  Whitfield Diffie and Susan Landau argue that if we are to retain the
  privacy that characterized face-to-face relationships in the past, we must
  build the means of protecting that privacy into our communication systems.

  This has not proved simple, however. The development of such protection
  has been delayed -- and may be prevented -- by powerful elements of society
  that intercept communications in the name of protecting public safety,
  intelligence and law-enforcement agencies see the availability of strong
  cryptography as a threat to their functions.

Martin Minow minow@apple.com

  [Excellent book.  I read it cover to cover, and it
  held my attention better than many spy novels.  PGN]


REMINDER: ISOC 1998 Network and Distributed Security Symposium

"David M. Balenson" <balenson@tis.com>
Wed, 11 Feb 1998 00:00:23 -0500
1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
March 11-13, 1998, Catamaran Resort Hotel, San Diego, California
Sponsored by the Internet Society
Program Chairs: Matt Bishop and Steve Kent

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss98
EARLY REGISTRATION DISCOUNT DEADLINE:  ==> 13 Feb 1998 <==

KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security
Products Group at Bell Laboratories, Lucent Technologies

THIS YEAR'S TOPICS INCLUDE:
- Internet and Intranet security
- Implementation issues for electronic commerce
- All-optical networks security
- Secure single login
- Timestamping protocols
- Remote password protocols
- Mobile agent systems security
- Java security
- Trust management
- Traffic analysis of TCP gateways
- Secure bootstrapping
- Firewalls and IP security

NEW THIS YEAR!  PRE-CONFERENCE TECHNICAL TUTORIALS

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
  Phone: +1 703 648 9888 Fax: + 1 703 648 9887
  E-mail: ndss98reg@isoc.org
  URL: http://www.isoc.org/ndss98/

Please report problems with the web pages to the maintainer