The RISKS Digest
Volume 21 Issue 21

Thursday, 25th January 2001

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…


RISKS moved to new mail server and list server program
Mike Hogsett
Look ahead + Cache == oops
Lindsay Marshall
QP -> UL?
Mark Brader
Osprey: A Spree? Us pray?
Travelocity exposes customer information
Monty Solomon
Network Solutions exposes e-mail addresses
Name withheld by request
Microsoft websites blacked out — but what happened?
Declan McCullagh
401k mixup
Jeremy Epstein
Risks of owning a cute domain name
Interesting Web risk
Lindsay F. Marshall
Re: Organiser Bugs
Peter B. Ladkin
Two-billion-dollar theft
S Harris
Another Y2K+1 glitch — sorta
George C. Kaplan
Re: Millennium error, or "something like that"
Amos Shafir
Re: 54 weeks in a year?
Espen Andersen
Bob Dubery
Markus Kuhn
Stan Sieler
Info on RISKS (comp.risks)

RISKS moved to new mail server and list server program

<Mike Hogsett <>>
Fri, 19 Jan 2001 15:07:31 -0800

As part of the process to transition our mail server from our old, slow,
dusty one to our new, fast and shiny one, we had to move all of our mailing
lists to the new server.  Of these lists, RISKS is the most heavily used.
The list file itself contains over 7000 e-mail addresses (many of which are
redistribution addresses).

During the process of subscribing all e-mail addresses to the new list,
there was unfortunately a short period of time when the list was
unmoderated.  Inevitably, a SPAM message managed to get through! I managed
to catch and stop the message before it was sent to all list members, but
unfortunately it was sent to at least 2, but not more than 1949 addresses.
[PGN: I heard from about 10 thus far.]

During the next few days, we will be tweaking the configuration for the new
RISKS list.  I would like to take this opportunity to apologize in advance
for any hiccups we have during this process.

If any RISKS list members notice any problems with the list, please do not
hesitate to e-mail me at so that I can address these
issue promptly.  As before, all subscription and unsubscription requests
should be sent to  For problems regarding
subscription and/or unsubscription requests please send e-mail to either or

Thank you,

Michael Hogsett, System Administrator
SRI International Computer Science Laboratory

  [One of the benefits of the new majordomo service is that I will no
  longer have to wade through the several hundred bounces that I get on
  each issue.  Many thanks to Mike for a major (domo arigato) effort.  PGN]

Look ahead + Cache == oops

Wed, 17 Jan 2001 13:07:37 +0000 (GMT)

I just received a message about an error from the RISKS Web server saying
that the latest edition - named on the front page - was not a valid issue.
It would seem that the request was sent through a cache through which
someone had previously requested the page *before* it really did exist and
so the error reply was cached under the name of the genuine page. The error
is generated dynamically so I can't just divert the reply to a fixed page,
so I will have to turn caching off on error returns.  Obvious?  Probably,
but I didn't think of it (no surprise there then) and I haven't seen in it
any lists of stupid Web programming errors!

Lindsay  <>

QP -> UL?

<Mark Brader <>>
Tue, 23 Jan 2001 14:03:45 -0500 (EST)

There have, for some years, been a number of scams whose victims are tricked
into making what they think is an ordinary phone call, but actually incur
surprisingly high charges some or all of which go to the scammer.  Apparently
an urban legend (UL) is now circulating on the Internet saying that these
charges can go as high was $2,400 per minute.  This is false, but in a
current thread in comp.dcom.telecom, John R. Covert says it was reported as
fact (due to inadequate checking) by Boston radio station WBZ.

Linc Madison now suggests that the origin of this UL is MIME quoted-printable
(QP) encoding.  We've probably all seen this at some time: any character
that "might not get transmitted correctly" turns into an = sign followed by
two characters giving its numerical value in hexadecimal; for example, if
you spell "role" with a circumflex accent in ISO 8859-1, it becomes "r=f4le".

Messages containing QP are supposed to be identified by MIME header lines
that say so, and restored transparently to their 8-bit form by one's news or
mail reader.  But some people use older software that doesn't understand
MIME.  And sometimes a message gets quoted in QP form with the header lines
stripped off.  This is especially likely to happen with a repeatedly forwarded
message like an Internet ULs — or in a digest environment like Risks.

Now $ is not usually considered a character that might not get transmitted
correctly, but it *is* special to UNIX shells, so someone might cautiously
configure it to be encoded.  And what's $ in hexadecimal, in ASCII and the
ISO 8859 character sets?  24.  So, as Linc says, "Thus $25/minute turned
into =2425/minute, which some helpful human turned into $2425/minute.
If you ever see a spam claiming $242,425/minute, just remember you saw it
here first."

(British pounds have a similar problem to a lesser degree.  The pound sign
in ISO 8859-1 is hexadecimal A3, so in similar circumstances 25 pounds could
turn into 325 pounds.  I think a case of this actually has come up in Risks.)

Mark Brader, Toronto <>

Osprey: A Spree? Us pray?

<"Peter G. Neumann" <>>
Thu, 25 Jan 2001 10:00:36 PST

A U.S. Marine commander has admitted falsifying the maintenance records of
the tilt-rotor V-22 Osprey squadron, which has long been plagued with
problems and whose development has been highly contentious throughout the
previous two decades.  (See RISKS-11.94, 11.96, 12.13, 12.15, 12.40-42,
12.60, 12.73.)  The doctored records include assigning flight-worthy
indications to Ospreys that could not fly, presumably in an attempt to
justify the viability of the aircraft.  This is of particular concern
following the two crashes in 2000 (in which 23 marines died).  (See
RISKS-21.14.)  [Source: Article by Elizabeth Becker and Steven Lee Myers,
*The New York Times*, 20 Jan 2001, National Edition p.A7; PGN-ed]

Travelocity exposes customer information

<Monty Solomon <>>
Tue, 23 Jan 2001 00:14:10 -0500

A security breach at Travelocity recently exposed the personal information
of up to 51,000 online travel company's customers who had participated in a
site promotion.  Customer names, addresses, phone numbers, and e-mail
addresses were revealed because of an inadequately protected directory --
possibly for up to a month.  This resulted from new servers cutover from San
Francisco to Tulsa.  [Source: Troy Wolverton, CNET, 22 Jan 2001]

Network Solutions exposes e-mail addresses

<Name withheld by request>
Thu, 25 Jan 2001 10:04:44 PST

You'd think they'd know better.  Network Solutions, which issues most .com,
etc. domain names, sends promotional mail to the e-mail addresses of domain
holders.  They include a URL for the recipients to use to remove themselves
from that mailing list.  If you use that URL, it replies that
  "<associated email address> has been removed".

However, the URL uses a simple "id=NNNNNNN" field to specify the name to
remove, apparently with no validation.  Not only could someone easily rig up
a program to run through all IDs sequentially and remove each one from the
Network Solutions mailing list, in the process it would also be possible to
gather the e-mail addresses of the accounts involved, which could provide
a wonderful mailing list for targeted spams.

Microsoft websites blacked out — but what happened?

<Declan McCullagh <>>
Wed, 24 Jan 2001 16:30:58 -0500

Millions of people have been prevented from visiting dozens of Microsoft
websites today.  [For extensive discussion on this, visit Declan's Web site:
with background at
To subscribe to POLITECH, visit
See also a later report:

401k mixup

<Jeremy Epstein <>>
Wed, 24 Jan 2001 07:49:37 -0500

Off by one errors are common.  Another one just caused people to get the
wrong 401(k) statements, disclosing information like social security
numbers, birth dates, and balances to the wrong person.  This has occurred
before: see RISKS 19.26 for example, with a posting by an anonymous



Risks of owning a cute domain namei

Mon, 15 Jan 2001 04:20:13 -0600 (CST)

As owner of the domain "", I find myself receiving more than my
share of spam.  Upon casual inspection, it seems this is no accident.
In the process of registering for various Web sites or software usage,
it appears that certain people have been avoiding spam by claiming that
their e-mail addresses are "", "", and
similar variants.

Interesting Web risk

<"Lindsay F. Marshall" <>>
Sat, 20 Jan 2001 20:34:31 +0000 (GMT)

A quote from a message sent to a list I am on:

>Or HTML being rendered automagically without some restriction of
>functionality, even if *that* is done within tcl/Tk instead of an
>external program. (Think "Web bugs". When some scientific conference
>requested that submissions be sent in HTML, I used a <BODY BACKGROUND=>
>pointing to my Webserver and presto, not only did I see in the Web logs
>who was refereeing my paper - highly confidential info, as far as
>confidentiality goes in academia -, I could even tell how thoroughly
>they had read it in the first place!! 8-} )
>(To add insult to injury, when these guys confirmed receipt of
>submissions, they sent Word *.DOC's, which included a list of the last
>ten files loaded into Word - and they had chosen to name the files by
>submission number *and contact author*. Oooooooops again - the names of
>authors whose papers were rejected are the *other* confidential data in
>scientific conferences ... Oh, did I mention that the first version of
>their Call for Papers read "please send HTML, double spaced, no more
>than ... pages"?)

Re: Organiser Bugs

<"Peter B. Ladkin" <>>
Wed, 10 Jan 2001 02:20:12 +0100

Kamens [RISKS-21.19] in reply to Berman [RISKS-21.18] asked:

>>About 4 years of notes and phone numbers lost (yes you can back it up
>>to a computer - The backup kit cost about the same as the organizer).
> And what is the "cost" of reconstructing the four years of notes and
> phone numbers?  I can't imagine that it's less than it would have cost
> to buy and use the backup kit.

The answer misses the point (I had considered a more forceful formulation of
the same assertion).

I suffered a disgraceful degradation of my Palm III over, I guess, about 3
months. I'd been using it for about 2 years, had become reliant on it, and
backed it up regularly. My backup was purely that, and had no GUI, because
it was Linux freeware recompiled for Solaris.  I wanted just a backup, not a
computer interface to the Palm.

The Palm quit one day. Soft reset didn't reset. Hard reset didn't work.
Dead. I went home. First problem I had ever seen in two years of
operation. Two hours later, I found that indeed my hard reset appeared to
have reset the device. I reloaded it from backup. No calendar entries from
the last 3 months (disaster: some of them were vital for legal
proceedings). None of the recent entries in my address db were there. I
looked at the file modification dates on the backup machine.  Many had not
been modified for months, despite my regular backups; even those which
showed more recent modification dates appeared to have older data.

The on-screen notifications "<filename> backed up" (or whatever it was) had
just been lies, for an indeterminate period of time. This is not hard to
understand. But when it happens to you, it is cognitively hard to believe.

There is no simple way to duplicate paper-based algorithms. Whatever you
have on paper, you can photocopy once a month and keep somewhere else, and
you are guaranteed that the original and the copy remain unaltered; if one
disappears, you know it right away and can use the other.

Try to duplicate that with a computer. Suppose I had had what I missed: a
GUI interface to the backup. The GUI shows me a tiny fragment of one
largeish database at a time. What would it take for me to tell that
something was missing, and that that was not the only thing missing, and
that each time I backed up, something more went missing? What would it take
for me to notice that the db had remained approximately static, although I
had made new entries (maybe the new entries were there, but consider
behavior in which new entries were made at the expense of older ones)?
Exactly what algorithm would you suggest that I use to ensure my digital
organiser plus backup had the same or better trustworthiness properties as
my paper version?

Much, even most, of the discussion on recovery from failure of
computer-based processes assumes that the failure is catastrophic, sudden,
and overtly remarked, and that previous states were veracious.  In other
words, that the computer system breaks just as a tire punctures. Well,
that's not the way things always work. Digital systems also fail "live", and
that is not just theory.

I spent some years seriously trying to develop paper-free work. Now,
everything remotely important to me goes on paper, even when written on a
machine. For much of it I ensure there are two spatially separated paper
copies. I mostly use the paper copies for backup; even on-line backup via
scanners. it isn't perfect, but I recommend the practice, and shall continue
to do so until someone offers me usable algorithms for digital devices with
properties at least as durable as those of the paper-based ones they will


Two billion dollar theft (Re: CIOs: "What, Me Worry?" RISKS-21.19)

<S Harris <>>
Fri, 12 Jan 2001 02:10:48 -0500

>> ... Meanwhile, a 1999 survey found that Fortune 1000 companies lost
>> more than $45 billion in thefts of proprietary information that
>> year.  [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001]

In RISKS-21.19 Mark Hull-Richter writes:

> I am HIGHLY skeptical of all claims of losses by large corporations.
> How does this $45 billion number come about?  How does a company arrive
> at the amount of money they actually lost due to theft of proprietary
> information?

I can give a first hand account of a $2 billion theft of proprietary
information to illustrate how these exaggerated figures get manufactured.
Back in 1989 I worked at a Toronto software development company that did
lots of work with the Unix operating system, and licensed the Unix source
code from AT&T for about $60,000 a year.

Night after night someone was logging in to the computers from a dialup line
to download chunks of the Unix source code.  Somebody at the company noticed
this, called in the police, who traced the connection to an ex-employee,
raided his house and seized his home computer.  Apparently the ex-employee,
a software development manager, who had recently left the company, missed
having access to the Unix source code and wanted to grab a copy of it for
personal study.  Satisfied that the source code had been recovered, and that
this wasn't a case of espionage or sabotage, the company would have been
happy to let the matter drop.

But the cops insisted on laying charges and it appears that they leaked the
story to the media.  All three Toronto newspapers (Toronto Sun, Toronto Star,
and the Globe & Mail) reported that the police had foiled a $2 billion theft!

Why wasn't this as a $60,000 theft of a commercial source code license?
Or at the very most a $500 theft of an educational license, since the
ex-employee's intended use was only to study it?

Well it seems that the police had called up AT&T and asked them "How much is
Unix worth?"  The answer was $2 billion.  AT&T gave Unix an asset value of
$2 billion on their books.  The police equated a little mischief to the cost
of acquiring total ownership of AT&T's Unix System Laboratories and all its
intellectual property!

In this case, the large corporation gave an accurate estimate to a bogus
question.  It was law enforcement (and sloppy fact checking by the media)
that twisted the story.

But you know, even the $2 billion asset value seems suspect to me now
because AT&T sold Unix to Novell in 1993 for just $270 million (see  Novell in turn sold it to
SCO in 1995 for a paltry $54 million (6M SCO shares at about $9 each is $54M,
see  But if AT&T
overestimated by tenfold, the police still exaggerated by 4 million fold.

Another Y2K+1 glitch — sorta

<"George C. Kaplan" <>>
Thu, 18 Jan 2001 14:59:50 -0800

The Extreme Ultraviolet Explorer (EUVE) satellite was launched in Jun 1992
to do astronomical observations in the extreme ultraviolet (100 - 1000
angstroms).  Its primary mission was planned for something like 18 months,
but a series of extensions has kept the satellite running ever since,
operated by UC Berkeley and NASA.  Money is finally running out, and it's
scheduled to shut down on 31 Jan 2001.

On 1 Jan 2001, a planning system that checks observing plans against
operational constraints suddenly failed.  A Y2K+1 bug?  Not quite.  Many of
the constraints are based on the relative positions of the sun, moon, and
planets.  (e.g. "Don't point the telescopes at the sun.")  A
solar/lunar/planetary (SLP) ephemeris file which provides this information
to the planning system was valid only through 31 Dec 2000.

OK, someone forgot to do the annual update, right?  Nope.  Solar system
motions are well-known and predictable over long time periods.  The SLP file
covered a 10-year period; it was the only one ever used by the mission.  No
provision was made for updating the file, since at the time EUVE was
launched, nobody expected the mission (even with extensions) to last through

So it's a classic problem of legacy software and data.  The original
programmers are long-gone.  Nobody knows quite where the original file came
from, and the (binary) format is different from SLP data used on more recent
missions operating with similar constraints.

At this point it's unlikely that an updated file will be available before
the mission shuts down, so the operations team at UC Berkeley is just
bypassing the SLP checks.  That's a risky choice, but reasonable, given that
they have only a couple of more weeks of operations.  You have to wonder
what they would have done if the mission had been extended for another year,

George C. Kaplan, Communication & Network Services, University of California
  at Berkeley   1-510-643-0496

Re: Millennium error, or "something like that" (Jacobsen, RISKS-21.19)

<Amos Shafir <>>
Thu, 18 Jan 2001 09:26:51 +0200

Well, Flex doesn't know about such a rule mainly because there isn't one;
the Gregorian leap year rules are just for 4/100/400 years, no 1000-year
rule (nor 4000 or 10000, which I have also heard about).  In this note
at least it's quoted as "something like that", but such errors have also
found their way into code, such as the PostScript code quoted in the note
by Eric Lindsay which immediately followed the one above in RISKS 20.19;
I wouldn't be surprised to find out that such code was responsible for
some Y2K bugs (it seems not all of them have been discovered yet).

The RISK here of course, that of generating code out of algorithms that
the programmer knows at "something like that" level, instead of taking the
trouble to check out the facts before coding.

Amos Shapir <>

Re: 54 weeks in a year? (RISKS-21.18)

<Espen Andersen <>>
Sun, 14 Jan 2001 05:38:49 +0100

The discussion of the Norwegian State Railway (NSB) troubles with the
2000/2001 transition focuses on fairly advanced causes, such as the
54-week situation.  The discussants (including our esteemed moderator)
seem by this to believe that the NSB is a competent and responsible
organization.  As recent events (such as a horrible rail accident with
19 dead where it turned out the railroad had a number of Single Point of
Failure situations, or the fact that the new high-speed "Signature"
trains had been built with axles that cannot tolerate high speeds and
turns at the same time) has shown, this organization has completely lost
the public's confidence (as witnessed by the recent, forced departure of
its CEO), as has its locomotive supplier ADTranz.

My hypothesis is that the 2000/2001 bug was a regular millennium bug,
found in 1999.  The problem was then "fixed" by turning the clock back
one year to buy time, and promptly forgotten.  Now NSB and ADTranz has
turned back the clock back once again.  This time, with the newspaper
and RISKS interest, they are unlikely to forget.

Espen Andersen <>, Norwegian School of Management (
+47 6755 7177 European Research Dir., The Concours Group

Re: 54 weeks in a year?

<"Bob Dubery" <>>
Mon, 15 Jan 2001 08:35:48 +0200

Standards are great - but it's RISKy to assume that they are being adhered
to just because they're published and sensible.

I led a y2k remediation project in 1999. I saw the source code for literally
thousands of programs. Some code anticipated a leap year, but never exactly
to the standards (IE the code would have accepted 1900 as a leap year). Very
seldom were date and time presented in any kind of standard format. I'm
willing to bet that if I asked all the programmers at my office what ISO and
RFCs are not all of them would know about ISO, and less than half would have
heard of RFCs - and nearly all of them wouldn't see the point.

This sounds disparaging, I know. I'm a programmer myself, so I do know
whereof I speak. I never worked for an employer that stipulated adherence to
any ISO standard. I have dealt with 3 "Web design houses" who had no
knowledge of RFCs.

If standards had been adhered to then why did we have a Y2k problem? And why
do we know have systems unable to roll into 2001?

Re: 54 weeks in a year? (Tridal, RISKS-21.20)

< (Markus Kuhn)>
14 Jan 2001 12:07:49 GMT

> I've tried to find a year that has 54 weeks using the ISO definition,
> but failed.

A detailed discussion of the ISO 8601 international date and time
notation standard, including a proof for why years can only have
either 52 or 53 weeks according to the international standard week
numbering scheme, can be found on

ISO 8601 has been adopted as a national standard in quite a number of
countries over the past few years and it seems to enjoy rapidly
increasing popularity. Computer experts should definitely make
themselves familiar with it.

Apart from standardizing a consistently bigendian numeric date and time
notation, it should also encourage in particular US users to finally
give up the awkward, error prone, risky, ambiguous and inefficient am/pm
time-of-day notation in favour of the modern and elegant international
standard 00:00-23:59 notation.

The antique 12h am/pm notation that is still so widely used in the US
even in airport time tables has *many* disadvantages like:

  - It is longer.
  - It takes somewhat more time for humans to compare two times in 12h
  - It is not clear, how 00:00, 12:00 and 24:00 are represented. Even
    encyclopedias and style manuals contain contradicting descriptions
    and a common quick fix seems to be to avoid "12:00 a.m./p.m."
    altogether and write "noon", "midnight", or "12:01 a.m./p.m."+
    instead, although the word "midnight" still does not distinguish
    between 00:00 and 24:00 (which are the standard notations for
    midnight at the start and at the end of a specified day).
  - It makes people occasionally believe that the next day starts at
    the overflow from "12:59 a.m." to "1:00 a.m.", which is a quite
    problem not only when people try to program the timer of VCRs
    for shortly after midnight.
  - It is not easily comparable with a string compare operation, so it
    doesn't automatically sort correctly in alphabetical listings.
  - It is not immediately obvious for the unaware, whether the time
    between "12:00 a.m./p.m." and "1:00 a.m./p.m." starts at 00:00
    or at 12:00, i.e. the am/pm notation is certainly more difficult
    to understand.

I don't understand, why in the US only the military and computer
programmers see the many obvious advantages of the modern standard
time notation. Perhaps the somewhat odd way of pronouncing the full
hours in US English as "eighteen hundred", which the US military
seems to have introduced, as opposed to the more natural
"eighteen o'clock" for 18:00 might have scared the civil
world from adopting it as well.

Those interested in the above might also want to read the neighbour
Web page

It describes another well-established highly elegant global standard
that could — if it were finally also adopted in the US and Canada --
eliminate a long list of risks and inconveniences in international
document exchange and in the use of photocopying machines: A4 paper.

Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
mkuhn at   <>

Re: 54 weeks in a year?

<Stan Sieler <>>
Mon, 15 Jan 2001 11:21:50 -0800 (PST)

> Doesn't the problem of 54 weeks in a year depend on how week numbers are
> calculated?

Of course it does!  Our modified paper, at,
makes that clearer than the original version.  Unfortunately, version 2.0
of the paper never got posted at

> The ISO standard for dates and times (ISO 8601) works differently by
> starting weeks on a Monday (that's not the important bit) and making Week 1

Yep.  But, as we point out, standards don't matter if you're doing it
differently.  And, some people definitely do it differently.  One of our
customers uses the "Sunday is first day" logic, and ran into the 54 week

Stan Sieler <>

Please report problems with the web pages to the maintainer