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 20 Issue 45

Thursday 17 June 1999

Contents

o eBay embarrassed by crash of system and plunge of stock
NewsScan
o Risks of e-mail borne viruses, worms, and Trojan horses
Bruce Schneier
o Not trusting virus scans
Paul Hoffman
o Risks of virus detectors blocking RISKS!
MAILsweeper
o Supremes uphold law barring indecent speech online
NewsScan
o Trouble for DoubleClick
Monty Solomon
o Human error called culprit in 3 rocket launch failures
Lindsay Marshall
o More troubles with PDF
Joe McCauley
o Re: A THAAD Day in Black Rock
Danny Cohen
o Re: GPS and collision risks
Peter B. Ladkin
o GPS and collision risks in marine navigation
Chris Bruce or Bruce Chris?
o Re: Risks - Depending on a *.xxx convention for file types
Rumy Driver
o More on "Unwanted wildcard match"
Nick Brown
o REVIEW: "Corporate Espionage", Ira Winkler
Rob Slade
o Info on RISKS (comp.risks)

eBay embarrassed by crash of system and plunge of stock

"NewsScan" <newsscan@newsscan.com>
Tue, 15 Jun 1999 07:25:48 -0700
The fallout from the 22-hour system outage last week of eBay, the popular
Internet auction site, has resulted in an 18% tumble of that company's
stock.  Analysts seem to regard the technical problems as normal growing
pains.  Michael Bernstein of the Gartner Group regards eBay's technical and
investor problems as relatively minor, and explains: "It's a fiasco like
this that will force a company to really fix the problem."  (AP/*San Jose
Mercury News*, 14 Jun 1999; NewsScan Daily, 15 June 1999)
http://www.sjmercury.com/svtech/news/breaking/merc/docs/000266.htm

  [Earlier eBay troubles were reported in RISKS-20.38.  PGN]


Risks of e-mail borne viruses, worms, and Trojan horses"

Bruce Schneier <schneier@counterpane.com>
Tue, 15 Jun 1999 16:48:25 -0500
Looking back from the future, 1999 will have been a pivotal year for
malicious software: viruses, worms, and Trojan horses (collectively known as
"malware").  It's not more malware; we've already seen thousands.  It's not
Internet malware; we've seen those before, tool.  But this is the first year
we've seen malware that uses e-mail to propagate over the Internet and
tunnel through firewalls.  And it's a really big deal.

Viruses and worms survive by reproducing on new computers.  Before the
Internet, computers communicated was through floppy disks.  Hence, most
viruses propagated on floppy disks, and sometimes on computer bulletin board
systems (BBSs).

There are some obvious effects of floppies as a vector.  First, malware
propagates slowly.  One computer shares a disk with another which shares a
disk with five more, and over the course of weeks or months a virus turns
into an epidemic.  Or maybe someone puts a virus-infected program on a
bulletin board, and thousands get infected in a week or two.

Second, it's easy to block disk-borne malware.  Most anti-virus programs can
automatically scan all floppy disks.  Malware is blocked at the gate.  BBSs
can still be a problem, but many computer users are trained never to
download software from a BBS.  Even so, anti-virus software can
automatically scan new files for malware.

And third, anti-viral software can easily deal with the problem.  It's easy
to write software to block malware you know about.  You simply have the
anti-virus scanner search for bit strings that signify the virus (called a
"signature") and then execute the automatic program to delete the virus and
restore normalcy.  This deletion routine is unique per virus, but it is not
hard to develop.  Anti-viral software has tens of thousands of signatures,
each tuned to a particular virus.  Companies release them within a day of
learning of a new virus.  And as long as viruses propagate slowly, this is
good enough.  My software automatically updates itself once a month.  Until
1999, that was enough.

What's new in 1999 is e-mail propagation of malware.  These programs -- the
Melissa virus and its variants, Worm.ExploreZip worm and its inevitable
variants, etc. -- arrive via e-mail and use e-mail features in modern
software to replicate themselves across the network.  They mail themselves
to people known to the infected host, enticing the recipients to open or run
them.  They don't propagate over weeks and months; they propagate in
seconds.  Anti-viral software cannot possibly keep up.

And e-mail is everywhere.  It runs over Internet connections that block
everything else.  It tunnels through all firewalls.  Everyone uses it.

It's easy to point fingers at Microsoft.  Melissa uses features in Microsoft
Word (and variants used Excel) to automatically e-mail itself to others, and
Melissa and Worm.ExploreZip make use of the automatic mail features of
Microsoft Outlook.  Microsoft is certainly to blame for creating the
powerful macro capabilities of Word and Excel, blurring the distinction
between executable files (which can be dangerous) and data files (which,
before now, were safe).  They will be to blame when Outlook 2000, which
supports HTML, makes it possible for users to be attacked by HTML-based
malware simply by opening an e-mail.  Microsoft set the security
state-of-the-art back 25 years with DOS, and they have continued that legacy
to this day.  They certainly have a lot to answer for, but the meta-problem
is more subtle.

One problem is the permissive nature of the Internet and the computers
attached to it.  As long as a program has the ability to do anything on the
computer it is running on, malware will be incredibly dangerous.  Just as
firewalls protect different computers on the same network, we're going to
need something similar to protect different processes running on the same
computer.

This cannot be stopped at the firewall.  This type of malware tunnels
through a firewall using e-mail, and then pops up on the inside and does
damage.  So far the examples have been mild, but they represent a proof of
concept.  And the effectiveness of firewalls will diminish as we open up
more services (e-mail, web, etc.), as we add increasingly complex
applications on the internal net, and as crackers catch on.  This
"tunnel-inside-and-play" technique will only get worse.

And anti-virus software can't help much.  If a virus can infect 1.2 million
computers (one estimate of Melissa infections) in the hours before a fix is
released, that's a lot of damage.  What if the code took pains to hide
itself, so that a virus won't be discovered for a couple of days.  What if a
worm just targeted an individual; it would delete itself off any computer
whose userID didn't match a certain reference?  How long would it take
before that one is discovered?  What if it e-mailed a copy of the user's
login script (most contain passwords) to an anonymous e-mail box before
self-erasing?  What if it automatically encrypted outgoing copies of itself
with PGP or S/MIME?  Or signed itself; signing keys are often left lying
around the system.  Even a few minutes of thinking about this yields some
pretty scary possibilities.

It's impossible to push the problem off onto users with "do you trust this
message/macro/application" messages.  Sure, it's unwise to run executables
from strangers, but both Melissa and Worm.ExploreZip arrive pretending to be
friends and associates of the recipient.  Worm.ExploreZip even replied to
real subject lines.  Users can't make good security decisions under ideal
conditions; they don't stand a chance against a virus capable of social
engineering.

What we're seeing here is the convergence of several problems: the
permissiveness of networks, interconnections between applications on modern
operating systems, e-mail as a vector to tunnel through network defenses and
as a means to spread extremely rapidly, and the traditional naivete of
users.  Simple patches won't fix this.  There are some interesting
technologies on the horizon that try to mimic the body's own immune system
to automatically deal with unknown malware, but I am not very optimistic
about them.  Sure they'll catch some things, but it will always be possible
to design malware specifically to defeat the immune systems.  A large
distributed system that communicates at the speed of light is going to have
to accept the reality of viral affections at the speed of light.  Unless
security is designed into the system from the bottom up, we're constantly
going to be fighting a holding action.

Melissa:
http://www.zdnet.com/zdnn/stories/news/0,4586,2233116,00.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2234121,00.html

Worm.ExploreZip
http://www.zdnet.com/zdnn/stories/news/0,4586,2274306,00.html
http://www.wired.com/news/news/politics/story/20160.html
http://www.symantec.com/press/1999/n990614d.html

Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com


Not trusting virus scans (Re: Karger, RISKS-20.45)

Paul Hoffman / IMC <phoffman@imc.org>
Tue, 15 Jun 1999 14:21:42 -0700
[On the other hand,] I ran *two* virus checkers against an attachment I got
last week, and both said it was fine, so I opened the attachment. It was the
new ExploreZip worm. Virus checkers inherently don't work on viruses that
are newer than your last update of the settings file. In this case, I had
the latest version of both checkers, but the virus was "too new" for either
of them.

Paul Hoffman, Director, Internet Mail Consortium


Risks of virus detectors blocking RISKS! (retitled by PGN)

<MAILsweeper@health.gov.au>
16 Jun 1999 07:51:24 +1100
[Original Subject: A copy of Melissa Virus may have been detected in a message]
  [NOTE: At least the intended recipient was CC:ed.  PGN]

    CONTENT VIRUS ALERT!

This is an automated response to inform you that a potential Melissa
computer virus (or variant) has been detected in an inbound electronic mail
message to:

   [...]@health.gov.au

   Date: Tue, 15 Jun 1999 12:07:31 -0700 (PDT)
   From: owner-risks@csl.sri.com
   [Subject: RISKS-20.44]

The message has been quarantined to prevent further propagation of the
virus.  Please remove the virus from the original document(s) or program(s)
and send again.  If you wish to discuss this matter, please contact the
postmaster as indicated below.

  Email: postmaster@health.gov.au
  Phone: +61 2 6289 7828
    Fax: +61 2 6289 4928

    [So, which part of RISKS-20.44 looked like Melissa herself?  Presumably
    the CERT Advisory which told where to get the advisories?  PGN]
       [BankBoston Gatekeeper Server also blocked the issue, but did NOT
       CC: the intended recipient.  I also had a note from Lindsay Marshall
       (who handles the RISKS redistribution for the UK); he also reported
       receiving such bounces.  PGN]


Supremes uphold law barring indecent speech online

"NewsScan" <newsscan@newsscan.com>
Tue, 20 Apr 1999 10:20:26 -0700
The U.S. Supreme Court has upheld a lower court ruling that affirmed the
constitutionality of a provision of the Communications Decency Act of 1996
that makes it a crime to transmit a "communication which is obscene, lewd,
lascivious, filthy or indecent with intent to annoy, abuse, threat or harass
another person."  The provision had been challenged by a San Francisco
company that had developed the "annoy.com" Web site to let people send
anonymous (and allegedly "indecent") messages to public officials. (AP 19
Apr 1999, http://www.usatoday.com/life/cyber/tech/cte912.htm; NewsScan DAILY,
20 Apr 1999)


Trouble for DoubleClick

Monty Solomon <monty@roscom.com>
Tue, 15 Jun 1999 23:44:37 -0400
Barely 24 hours after DoubleClick said that it would acquire marketing
research company Abacus Direct for $1 billion in stock, privacy coalitions
announced that they would file complaints with the FTC, contending that the
merged entity would pose a threat to consumer privacy. The merger, which
would help DoubleClick build the ultimate online database of consumers,
brings the company closer than any other to achieving every online
marketer's dream. But along the way, DoubleClick may have stumbled into a
consumer-backlash nightmare.

[Jacob Ward: http://www.thestandard.com/articles/display/0,1449,5017,00.html]


Human error called culprit in 3 rocket launch failures

<Lindsay.Marshall@newcastle.ac.uk>
Wed, 16 Jun 1999 12:38:34 +0100 (GMT)
<http://www.flatoday.com/space/explore/stories/1999b/061699e.htm> is a Florida Today article
that claims that typos in software caused the loss of three rockets.

Lindsay http://catless.ncl.ac.uk/Lindsay

  [The article claims that the 30 Apr 1999 Titan 4B failure (RISKS-20.39) is
  being blamed on a shifted decimal point in the software for the rocket's
  upper stage.  PGN]


More troubles with PDF

"Joe McCauley" <mccauley@davesworld.net>
Tue, 8 Jun 1999 09:56:01 -0500
The article in RISKS-20.43 from Bryan O'Sullivan about troubles printing a
PDF document reminded me of my own experience with PDF around tax time.  I
moved last year and had to file two different state tax returns in addition
to my federal return.  I downloaded some of the tax forms and publications I
needed from the web, all of which were in PDF format, and ran into several
cases of PDF forms that looked fine on my Win95 PC display but not so good
when I printed them on a LAN-attached Laserjet printer:
 - Some of the Federal publications and instructions printed without any
   spaces between the words (luckily the forms themselves came out fine,
   at least the ones I needed);
 - The Illinois form IL-1040 was unusable; apparently it couldn't handle a
   character graphic about halfway down the first page and didn't print any
   of the rest of the form after that;
 - Many of Massachusetts tax forms are color-shaded and use colored
   areas in parts of the forms.  When printed on a Laserjet, which doesn't
   support color, all these colors were replaced by shades of gray, making
   some parts of the forms difficult or impossible to read.
Some of these problems may have been due to my local computing
environment (though I think at least the Mass. forms should have been
available in non-color versions).  All illustrate the risks associated with
assuming PDF is a stable and reliable format for online distribution of
forms and documents.

Joe McCauley


Re: A THAAD Day in Black Rock (PGN, RISKS-20.43)

Danny Cohen <cohen@rand.org>
Tue, 15 Jun 99 13:34:38 PDT
Antimissile missile hits flying target on 7th try

An expensive experimental antimissile missile did Thursday what it had been
unable to do on six previous attempts: Hit a flying target.  A white puff of
smoke in the southern New Mexico sky marked where the Army's Theater
High-Altitude Area Defense, or THAAD, missile struck a target missile, which
left a squiggly white trail of vapor just to the west.  [Source: CNN item,
10 Jun 1999, http://cnn.com/US/9906/10/missile.test.ap/

  [RISKS always seeks good success stories -- although this one must qualify
  as only a relative success, considering the previous failures.  However,
  we receive very few RISKS-relevant success reports, and do not want
  readers to conclude that there are no successes.  But in the long run,
  it does seem that there are very few risk-free successes.  PGN]


Re: GPS and collision risks (Wood, RISKS-20.44)

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Wed, 16 Jun 1999 14:03:09 +0200
> [...] The probability of a collision between aircraft using GPS on
> established air routes is significantly higher than between aircraft
> using conventional navigation aids because of the greater accuracy of
> navigation using a GPS.

Intuitively, I doubt this. Here's the reasoning.

To begin with, let us consider flight along, say, US Federal Airways.

Firstly, (a) separation in instrument meteorological conditions is ensured
by ATC. No change in risk here. Secondly, (b) aircraft flying under
instrument flight rules in visual meteorological conditions are flying in
cruise at different altitudes (thousands of feet) than those flying under
visual rules (thousands + 500 feet). Thirdly, although I cannot find it in
the US Aeronautical Information Manual (AIM), (c) pilots of aircraft flying
visually on designated airways have *always* been advised to keep the airway
centerline/fix to one side of them - yes, the same side (actually, this is
well-known pilot lore all over). This takes care of the climb/descent
problem. US Federal Airways extend horizontally to 4 nautical miles (4.6
statute miles) each side of the centerline.

Federal Airways are defined by VOR transmitters not more than 50nm from any
point on the airway that they are defining. Even though a signal may be
distorted, all receivers will be receiving the same distorted signal, so any
individual variation must be in the individual receivers in the aircraft. I
can see no way of demonstrating either than pilots fly more accurately to
GPS guidance than they do to VOR guidance, or that VOR reception is
generally sloppier than the accuracy to which visual pilots are flying an
airway (my experience, in fact, is quite the opposite, as would be that of
most instrument flight instructors trying to get their proteges to hold a
VOR course, I would suppose!). Unless one or the other of these can be
demonstrated, one could not conclude that flying behavior on airways had
changed significantly with the introduction of GPS.

But suppose that one could demonstrate somehow that people were flying more
accurately with GPS guidance. Then to conclude that the risk of collision
was higher, one would have to show that the protocols (a)-(c) above were not
in general being followed. Since (a) and (b) are enshrined in aviation
regulations, and (c) in good practice/pilot lore, I doubt this would be easy
to demonstrate.

One other way to show that the risk of midair collisions had increased would
be to show that there had been more midair collisions since GPS use became
prevalent, and that this was not just a statistical fluctuation.  Well, I
don't know for sure, but I don't think there have been more.  Even if there
had, the cause of the phenomenon would have to be determined, and for the
above reasons it would be very hard to show that it was due to
suddenly-increased accuracy of flying of VFR pilots.

So much for airways. On to other possibilities. Perhaps Wood was thinking of
pilots wanting to fly to point X and lots of them all getting exactly to
point X. If point X are the published GPS coordinates of an airport, there
exist procedures to follow well before one gets to point X, which have been
designed to alleviate the possibility of midairs in the neighborhood of an
airport. One would have to imagine that somehow pilots are ignoring these
procedures because they have a GPS, and I don't see how one could show any
such thing. If point X is some specific sightseeing point, then I grant that
there may be an increased need for vigilance since now one can navigate
precisely to X. However, I don't know what the proportion of such flights
would be, and I doubt that they are representative of most flights (It would
seem appropriate to reiterate the usual warnings to pilots about increased
traffic density in the vicinity of sightseeing attractions.)

Finally, I should note the article in Risk Analysis 17(2):237-248, 1997, by
Robert Patlovany entitled U.S. Aviation Regulations Increase Probability of
Midair Collisions, brought to my attention by Hal Lewis (who, by the way,
has written a fine, fine book on making decisions called Why Flip a Coin?,
New York: John Wiley & Sons, 1997, which I found very entertaining as well
as enlightening and have promised for two years to review for Risks, but
haven't yet. Hal's got a great writing style. Read it. So there). Patlovany
uses "a purely stochastic Monte Carlo model [..] to compare the relative
midair collision course probabilities and mean closing velocities of four
systems of rules for aircraft cruising altitudes as a function of altitude
error: (1) current U.S. federal rules, (2) random altitudes, and (3)
[etc...] The calculations verify that (1) federal rules increase collision
course probabilities by about four times more than for a chaotic system of
aircraft cruising at randomly selected altitudes, (2) risk is directly
proportional to the level of compliance, and (3) [etc]."

Note that Patlovany is considering cruising flight only, and altitudes, that
is, vertical displacement, not the horizontal displacement which I take to
be the relevant factor for evaluating Wood's GPS vs. VOR contention.

Prof. Peter Ladkin Ph.D., Univ. Bielefeld, Technische Fakultaet, D-33501
Bielefeld (Germany) http://www.rvs.uni-bielefeld.de +49 (0)521 106-5326/5325


GPS and collision risks in marine navigation (Re: Wood, RISKS-20.44)

Bruce Chris <chris.bruce@hyder.com>
Wed, 16 Jun 1999 11:00:06 -0000
Lloyd Wood's comment regarding the probability of a collision between
aircraft using GPS on established air routes applies equally to marine
navigation. Navigation using electronic aids is generally from waypoint to
waypoint. A "marine" waypoint is often a fairway buoy marking the end of a
channel into a harbour or perhaps a buoy marking a shoal area at sea or a
headland to be rounded. Vessels head from all directions towards the
waypoints. A good lookout is necessary! This topic has had mention in the
marine press for some years.

It also reminds me of the use of radar for collision avoidance at sea
leading to what is known as Radar Assisted Collisions!


Re: Risks - Depending on a *.xxx convention for file types

"Rumy Driver" <Rumy.Driver@sybase.com>
Wed, 16 Jun 1999 13:40:41 -0500
This is to note we are still paying for the archaic way of using the *.xxx
extension  for defining the file type.

This is only on Windows platforms which are a legacy of DOS days.

In most other platforms files have 2 parts (e.g. MacOS)
part1     resource fork
     Contains the actual meta-data - program that created file, date of
creation, date of last modification ....
part2     data fork
     Actual data

Now in the DOS-legacy world it is soooo easy to rename a file to another
extension and the file morphs itself.  This is the sneaky trick/way used to
spread the latest virus/worm.

Another suggestion for *.ZIP files is NOT to double-click them and launch,
but to use the Classic mode of WinZip and check what is in the ZIP archive
before extraction. This would have let people know that it's a EXE file and
they could have taken precautions(?).

Another suggestion is not to have a completely homogeneous environment
(reminiscent of the potato"e" (apologies to Dan Quayle) famine)

Rumy Driver, Sybase Technical Support


More on "Unwanted wildcard match" (RISKS-20.44)

BROWN Nick <Nick.BROWN@coe.int>
Wed, 16 Jun 1999 18:45:08 +0200
I received quite a lot of mail on this subject.  A couple of people
helpfully tried to explain what they thought was the problem, based on their
knowledge of DOS, but "assuming" that NT works that way, which it doesn't.
(RISKs of assuming next-generation systems are infelicity-compatible, I
guess.)

Yes, in DOS, the wildcards *1.LNK and *.LNK are identical, since DOS treats
* to mean "everything up to the period" (and there can only be one period).
However, NT's wildcard matching does more or less what you'd expect - it's
quite close to, say, how DCL does it under VMS.  My problem is that it
matches both the visible and the invisible filenames.

For example, if I do this:

C:\>copy afile.txt longname2.txt
C:\>copy afile.txt longname1.txt
C:\>copy afile.txt longname4.txt
C:\>copy afile.txt longname3.txt
C:\>dir /x long*.*
   LONGNA~2.TXT  LongName1.txt
   LONGNA~1.TXT  LongName2.txt
   LONGNA~4.TXT  LongName3.txt
   LONGNA~3.TXT  LongName4.txt

> and delete *1.TXT, I "only" lose the first two files.
>
Footnote: Microsoft have, however, faithfully re-implemented in NT the
wonderful DOS bug whereby, if you change a file's extension while copying it
using a partial-match wildcard, the copy is done as if you said /A for
ASCII.  For example, if I have WINWORD.EXE and I want to copy it to NICK.XXX
and I'm feeling lazy, I might say
>   COPY W*.EXE NICK.XXX
without putting the /B switch on the COPY command.

> Try it - you'll get a file truncated to the offset of the first ctrl-Z
> character in the original.

Thanks also to the person who pointed out that the automatic note appended
to all outgoing e-mails from our site (saying that our domain name has
changed), which PGN didn't chop off as he sometimes does with voluble sigs,
contained a reference to a site which didn't work.  Apparently this went
wrong about two weeks ago.  Of the 80000 or so Internet E-mails we have sent
out since then, nobody else has bothered to mention the problem.  This must
mean something.

Nick Brown, Strasbourg, France   http://dct.coe.int/info/emfci001.htm


REVIEW: "Corporate Espionage", Ira Winkler

Rob Slade <rslade@sprint.ca>
Tue, 15 Jun 1999 08:39:25 -0800
BKCRPESP.RVW   990424

"Corporate Espionage", Ira Winkler, 1997, 0-7615-0840-6,
U$26.00/C$34.95
%A   Ira Winkler
%C   3875 Atherton Road, Rocklin, CA   95765-3716
%D   1997
%G   0-7615-0840-6
%I   Prima Publishing
%O   U$26.00/C$34.95 800-632-8676 916-632-4400 fax: 916-632-1232
%P   365 p.
%T   "Corporate Espionage"

This readable and realistic guide to becoming professionally paranoid has a
special emphasis on data security and high tech companies, but can be very
useful to pretty much anyone.

Part one looks at espionage concepts.  Chapter one, and the introduction
that precedes it, points out that information is one of the primary sources
of value in any business.  Chapters two through five look at the basic ideas
for any examination of data security, those of risk, value, threat, and
vulnerability.  Presented in terms, and with examples, that anyone can
understand, they nevertheless form the foundation for examining security and
protection for computer and communications systems as well as the sales "red
book" for next quarter.

Part two presents a variety of case studies.  Winkler concentrates on the
non-technical, relatively simple, and devastatingly effective "social
engineering" aspect of break-ins.  Chapter six is a compilation of tactics
used in various penetration tests.  One particular test is outlined in
chapter seven.  Chapters eight to eleven detail actual espionage cases
carried out by foreign companies.  A different penetration test is presented
in chapter twelve.  A third party account of a "crack" is discussed in
chapter thirteen.

Part three outlines what you can do to protect yourself.  Chapter fourteen
describes a significant list of countermeasures to take, starting with an
effective education program.  Finally, chapter fifteen presents a large
scale program for overall security.

This book is very down to earth, and very real.  Unlike any number of
"hacker" books, it doesn't attempt to impress the reader with displays of
arcane knowledge: it doesn't have to.  Technical details are almost
non-existent, making the text an excellent choice for use in educating any
level or type of employee on the need for security.

copyright Robert M. Slade, 1999   BKCRPESP.RVW   990424
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer