Subject: RISKS DIGEST 16.74
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Sunday 8 January 1995 Volume 16 : Issue 74
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** NO MORE nth-order incremental responses to old stuff for
***** the next two weeks, please. NEW STUFF ONLY. THANKS.
***** See last item for further information, disclaimers, etc. *****
Contents:
Software sensitive to cold? (Karol Fruehauf)
Revision Level, What Does It Mean??? (Mark Thorson)
Re: Cancelmoose, WSJ word usage, and vigilantism (Steward)
Re: ETS Electronic Testing (Simson L. Garfinkel)
Re: Fidelity error (Barry Margolin, Floyd Ferguson)
Re: My life as an International Arms Courier (A. Padgett Peterson)
Re: Israeli army, cellular phones, pizza (Michael Dahan, David Wadsworth)
Re: GIF (David Winfrey, Simson L. Garfinkel, John Mainwaring, Garrett P Nievin)
Re: Date/Time (Steve Sapovits, Mark Brader, Erann Gat)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: 07 Jan 95 09:46:38 EST
From: Karol Fruehauf <
[email protected]>
Subject: Software sensitive to cold? (Badener Tagblatt, January 7, 1995)
"The current extreme cold is causing troubles to the Rhatische Bahn (RhB)
[a private railway company in Switzerland, Ff]; the brand-new locomotives
can't cope and mainly the service of the Albula-route in Engadin [eastern
part of Switzerland, e.g. St.Moritz, Ff] suffers breakdowns. The main
switch of the Ge 4/4 III type locomotives gets frozen and the oil supply
control software goes out of service.
With a heating equipment for the main switch and a new version of the oil
supply control software all problems should be resolved."
The new version of the software will be most likely delivered with cold
resistant bits and bytes preventing them to shrink under low temperature
conditions. Another solution could be to equip them with skates so that the
bits and bytes can function on ice too.
Karol Fruhauf, INFOGEM AG, CH-5401 Switzerland
----------------------------------------------------------------------
Date: Sat, 7 Jan 1995 17:27:43 -0800
From:
[email protected] (Mark Thorson)
Subject: Revision Level, What Does It Mean???
How should a revision level be interpreted? Here's a quick guide for anyone
short of a clue:
0.1 WE GOT A REALLY GREAT NEW WAY TO DO THINGS !!!
<0.9 Not ready for prime time.
0.9 We think it works, but we won't bet our lives on it.
1.0 Management is on our case; seems like a low risk.
1.01 Okay, we knew about that. All known bugs are fixed.
1.02 Fixes bugs you won't see in 27,000 years, i.e. more
than three times the age of the universe.
1.03 Fixes bugs in the bug fixes.
1.04 All right, this REALLY fixes all known bugs.
1.05 Fixes bugs introduced in rev 1.04.
1.1 A new crew hired to write documentation.
1.11 From now on, no comma after "i.e." or "e.g.".
1.2 Somebody actually changed a functional feature.
2.0 New crew hired to write software. Old crew blamed for
bugs.
2.01 New crew sending out resumes to placement agencies.
3.0 Re-write the software in another language, go back
ten squares.
.. return to line 0.1
----------------------------------------------------------------------
Date: Fri, 6 Jan 1995 23:48:25 -0500
From:
[email protected]
Subject: Cancelmoose, WSJ word usage, and vigilantism (Haley)
>Cancelmoose is not a "vigilante", as he does not act alone; there is
>substantial agreement amongst the Usenet administrators that have
>contributed to this debate that these actions are necessary.
Not to be hopelessly pedantic, but as the post was disagreeing with
the WSJ's word choice:
vigilante- a member of a vigilance committee; any person executing
summary justice in the absence or breakdown of legally constituted
law enforcement bodies. Now also, a member of a self-appointed group
undertaking law enforcement but without legal authority, operating
in addition to an existing police force to protect property etc.
within a localized area. - New Shorter Oxford Dictionary
It appears to this poster that, in fact, the operator of Cancelmoose
-is- a vigilante, executing summary justice on behalf of the
vigilance committee consisting of the USENET administrators
among whom the 'vote' was taken.
[email protected]
----------------------------------------------------------------------
Date: Sat, 7 Jan 1995 20:02:10 -0800
From:
[email protected] (Simson L. Garfinkel)
Subject: ETS Electronic Testing
Although I have seen much in the past week about ETS and its electronic
testing system, I have seen little in the way of first-hand reports by
people who took the test.
I am one of those people. Here is my report.
In the fall of 1992, I had the mistaken notion that I wanted to go to
graduate school in the fall of 1993. I got the GRE application and
discovered that it was too late for me to take the standard written test
and still make my application deadlines. It was possible, however, for me
to pay an additional fee (under $100, but more than $20) and take the
electronic version. This seemed like a godsend, so I willingly parted with
my money and awaited my response.
I got a form back from ETS approx. three weeks later. I was to call up the
local testing center (in Cambridge, a few blocks from MIT), and make an
appointment. I did this.
On the appointed day, I showed up at the ETS testing center. They seemed
very disorganized. The center was a quarter of the floor of a medium-sized
office building. There was a reception desk up front, a waiting area, and
rows of offices with windows. Across from the offices was the "testing
room" --- a long, narrow room. There were tables along the walls, computers
on the tables, chairs, and windows that overlooked the offices. The
arrangement, apparently, was to make it difficult for people taking the
test to see other people's screens, and easy for people to look into the
room and see if we were cheating.
I presented two forms of identification, which the receptionist
scrutinized. I then waited in the reception area until the appropriate
time. Three other people showed up. We were then led to the testing area. I
sat down at one machine, and the test began.
I should say here that I found taking the test on the computer to be a much
more enjoyable experience than taking the test on paper. The test is
self-paced. You have a little count-down timer in the corner of your screen
showing you how many minutes and seconds are left in a particular section.
You can abort the section at any point and go to the next section.
The test looks much the same as the regular test: diagrams or reading
comprehension paragraphs, with questions. You answered the question by
clicking on a bubble --- just as if you were filling it in with a pencil.
You could also mark questions. You could switch to an outline view that
showed every question how you had answered it, and whether or not it was
marked. You could click directly to a question.
Was the test susceptible to cheating? Absolutely. Quite simply, we were
not watched. There was intermittent talking between two of the test takers
on the day of my test. I could see screens of other test-takers. Infact,
one of the students seemed to doing the same questions that I was doing.
ETS said that one of the advantages of the computer-test is that the exam
will be able to adopt to the student in real-time. This will make the exam
more precise, allowing it to zero-in on the student's exact abilities. In
my experience, though, I didn't see any such adapting. (I vaguely recall
that ETS said that the adapting wasn't being used the year that I took the
test, but it may be online now.)
Between each section, we were given a short break. At the end of the test,
I was given the chance to cancel the entire test. If I didn't want to do
that, I could view my result. However, if I viewed my result, that made it
permanent.
I got my score and left. Instead of taking the regular 3 1/2 hours, I was
finished in two.
As I said, it was a very enjoyable experience.
----------------------------------------------------------------------
Date: 8 Jan 1995 15:08:45 -0500
From: Barry Margolin <
[email protected]>
Subject: Re: Fidelity error
On Godfrey: My interpretation of the letter was that the complexity of the
tax code is what prevents them from automatic the transcription fully. It
takes a human accountant to go through the financial records and determine
what should be copied to the distribution calculation.
While I doubt that it's actually impossible to automate this, it's quite
conceivable that the complexity has delayed implementation of such measures.
Companies only have finite resources to automate their procedures.
On Flatau:
> ... It also was quite apparent when I balanced my check
>book at the end of the month.
Isn't that precisely what happened? An accountant screwed up, and when the
auditors reviewed the books they discovered the error and corrected it.
Frankly, I'm surprised at RISKS people flaming Fidelity for this error.
IMHO, this is an example of a company whose procedures *worked*. As we all
know, no process is infallible, and checks are necessary to catch the
errors. Of course it would be nice if the checks always occurred before the
failures became public, but the important thing in this case is that the
checks occurred before checks were cut (sorry for the pun).
Barry Margolin BBN Internet Services Corp.
[email protected]
------------------------------
Date: Sat, 7 Jan 95 10:07:45 CST
From:
[email protected] (Floyd Ferguson)
Subject: Re: Computing error at Fidelity's Magellan fund
I see two RISKS: The implication that this mistake only happened because
manual steps were involved, and the risk of having infrequent but highly
important tasks that require non-standard procedures (like "manual"
calculations in a largely computerized environment).
>>Kathy Godfrey
[email protected]
Maybe there is also a cultural RISK?? Magellan Fund does not expect
to lose billions and billions of dollars. Manually entering data that
is unexpected or unpleasant or unwelcome surely must be more prone to
error. Perhaps a computer version of a freudian slip?? So, procedures
for manual entry of data need to take into account the potential
emotional/affective content of the data being entered.
[What about fraudian slips? PGN]
Floyd Ferguson
[email protected]
----------------------------------------------------------------------
Date: Sat, 7 Jan 95 10:21:39 -0500
From:
[email protected] (A. Padgett Peterson)
Subject: Re: My life as an International Arms Courier (Blaze, RISKS 16.73)
Unfortunately, the disclaimer at the end of Mr. Blaze's posting makes it
impossible to extract the single paragraph I wished to comment on (another
RISK in itself) so I will have to wing it. [Nice observance! PGN]
The RISK a government takes in enacting such laws is that people will try to
act within them. To me one of the most powerful strengths of the USA is that
a large portion of the citizenry feel free to point out just how absurd some
laws are by insisting on their enforcement. If everyone did, whether out of
"creative anarchy" as here or pure fear of the consequences as exists in
unnamed countries (fortunately regimes based on fear never seem to last very
long since stagnation is inevitable).
IMHO, unenforceable laws are bad laws primarily because they degrade respect
for all laws (look at speed limits for one example). Of course many laws are
broken simply because they are unknown (does everyone have a leash for their
alligator ?), obscure, and/or unenforced.
Further, where enforced, people quickly learn the right words to say (when
I built a home for my hobby, on my first application I said "garage" and
was told that for the size it needed steel doors and a commercial fire
sprinkler system. It immediately became a "garage/workshop" and so came under
le$$ re$trictive residential requirements).
The bottom line is that it takes people like Matt to take the time and
trouble to point out the absurdities in order to get them "fixed" - after
all in the best of worlds, that is what bureaucrats are for. IMHO doing
something like this is worth it provided you never have to do it again.
Padgett
ps wonder what would be the RISK of making up an official appearing
document for example from the "Department of Stepanographic Affairs"
and using for the exportation of encoded ducks ?
----------------------------------------------------------------------
Date: Sun, 8 Jan 1995 12:15:26 +0200
From:
[email protected] (Michael Dahan)
Subject: Israeli army, cellular phones, pizza
The flap here in Israel regarding cellular phones began when newly inducted
soldiers brought the phones to basic training at boot camp. The concern had
less to do with security risks but rather socio-economic concern: Soldiers
who could afford cellular phones (which are ridiculously expensive in Israel
and serve as status symbols) and those who couldn't. One of the most
important features of the Israeli Army is that it is an army of the people:
many and women from the age of 18 serve two (for women) and three (for men)
years, and then do reserve duty once a month till the age of 55. The use of
cellular phones by new recruits caused concern for the melting pot
characteristic of the army and serves to introduce additional stress between
those who can afford the phones and those who can't. The pizza on the other
hand is another story....
Michael Dahan Dept. of Political Science Hebrew University Jerusalem, ISRAEL
[email protected]
------------------------------
Date: Sun, 08 Jan 1995 10:53:03 GMT
From:
[email protected] (David Wadsworth)
Subject: Re: Soldiers and Cellular telephones
The problem with cellular telephones in Military/Emergency service use is
that they work too well! In an emergency people get rather discouraged when
their incredibly expensive radio system is overloaded, and unusable, but a
simple cell phone works perfectly well. If you are in an emergency
situation, and you are reduced to whistling into a microphone in morse code
to try to get your message through an overloaded radio channel, then, if you
have a cell phone, you will use it regardless of security.
Of course, in some cases the cell phone may be more secure than other means
of communication!
David Wadsworth
----------------------------------------------------------------------
Date: Sat, 7 Jan 1995 06:28:02 -0500 (EST)
From: David Winfrey <
[email protected]>
Subject: Patent problems in replacing GIF
RISKS-16.72 contains some discussion of the GIF/LZW patent problem,
including a suggestion that some other standard (such as JPEG) be defined.
Unfortunately, JPEG contains patented (by IBM) compression code.
Many compression algorithms, including the simplest form of run-length
encoding, are patented.
See rtfm.mit.edu:/pub/usenet/news.answers/compression-faq/part[1-3]
for details, patent numbers, and excerpts from the mind-numbing
legalese in which patents describe inventions.
The same FAQ also points out that LZW is patented by both Unisys
and IBM, the patent office having failed to notice that both
patent applications described the same algorithm.
David Winfrey
[email protected]
Capital PC User Group, Rockville MD
------------------------------
Date: Sat, 7 Jan 1995 20:02:16 -0800
From:
[email protected] (Simson L. Garfinkel)
Subject: more on GIF (decompression)
It is my understanding, based on a conversation with Richard Stallman two
years ago, that the Unisys patent on LZW only covers compression, and not
decompression. This is the reason that the GNU gnuzip compression program
can decompression "compressed" archives without violating any (known)
patents.
This, of course, means that there is a simple and reasonably transparent
solution to the current GIF crisis:
1. Adopt a new compression standard for GIF.
2. All newly created GIF files will be in this standard.
3. Continue to support decompression of GIF files compressed with LZW,
because that does not violate the Unisys patent.
For a compression algorithm, we could use the simpler compression algorithm
used by programs like PGP (I think that it is straight LZ, rather than LZW),
or we could use the algorithm that gnuzip uses (which is better at
compression than LZW, but executes more slowly).
Simson
------------------------------
Date: Fri, 6 Jan 1995 18:31:00 -0500
From: "john (j.g.) mainwaring" <
[email protected]>
Subject: Re: CompuServe-Unisys GIF Tax Protest
In RISKS 16.72, Peter Bishop refers to the recently announced
UNISYS/COMPUSERVE patent restriction and recommends switching over to
use the Free Software Foundation's GZIP. This may not solve the
problem. In the same issue of RISKS, Tim Oren of Compuserve pointed
out that the restriction had been imposed entirely by Unisys, and that
Compuserve wished as much as the rest of us that it would go away. I
am not sure what compression algorithm ZIP & GZIP use, but I was under
the impression that they use LZW, just like GIF. If so, I should
imagine unisys will be leaning on the FSF and PKWare and anyone else
they can find who uses LZW in their software.
It would be very interesting to see the opinion of someone with a
knowledge of patent law on how a patent can be obtained on something
that has been as widely published, apparently without notice of
restriction, as LZW has been.
John Mainwaring
[email protected] The usual disclaimers may apply
------------------------------
Date: Sat, 7 Jan 1995 18:35:06 -0500 (EST)
From: Garrett P Nievin <
[email protected]>
Subject: Error in CompuServe/Tim Oren's msg
I believe Tim Oren of CompuServe has made an error in chronology.
When the GIF standard was initially developed in 1987, Unisys was not
"pursuing" a patent for the LZW algorithm; the patent had already been
awarded, in 1985.
Garrett P. Nievin
----------------------------------------------------------------------
Date: Thu, 5 Jan 1995 18:33:08 -0500 (EST)
From: Steve Sapovits <
[email protected]>
Subject: Re: Date/Time
This discussion brings several time-related bugs from my past to mind.
One of the more mundane was the October bug. We introduced some new
date/time functions into our code sometime in the spring or summer.
They all seemed to work fine. When October came around, things started
behaving strangely (obvious "core walks" for you UNIX folk). The problem?
Months were zero-based (0-11) but were displayed one-based (1-12). The
code used the zero-based number to calculate the number of digits required
for display. Simple coding error. The bigger problem was a lack of unit
testers to test all ranges of dates instead of relying on the normal passage
of time. When the problems first showed up it had been months since we had
worked on the date/time code so it was not immediately suspected.
A more interesting bug which shows just how likely it is for time to not be
accurate if it's not fetched atomically showed up when we had our product
running on a 286-based UNIX (XENIX I think). I forget the exact details,
but we had your basic C language MIN() type macro, which looked something
like this:
#define MIN(x, y) (((x) < (y)) ? (x) : (y))
Simple enough. Until someone did something like this:
least_time = MIN(time((long *) NULL), old_time);
[ the time() function in UNIX returns the number of seconds since the epoch ].
This looks innocent enough, but it expands so that there are two time()
calls -- one during the comparison and one to get the value the expression
evaluates to. Our expectation was that either the original x or y would be
the result of using the macro. Instead, some cases evaluated to x plus some
number of seconds -- the number of seconds we gotted swapped out on that
pathetic system between the two calls.
Steve Sapovits, Telebase Systems (610) 293-4724
[email protected]
------------------------------
Date: Thu, 5 Jan 1995 19:45:38 -0500
From:
[email protected] (Mark Brader)
Subject: Re: Dates in a 4GL (Moore, Risks-16.71)
[I could not possibly use all of the responses received on
this subject. I chose just a few, ignoring a few very fine points
that would be useful to someone involved in a particular system.
Mark Brader wrote a nice note on leap seconds, which, however, seemed
gratuitous here. Pete Carah <
[email protected]> noted we
are now up to 18 accumulated leap seconds. Martin Ewing
<
[email protected]> warned about nonmonotonic clocks. Several
folks had "fixes" for nonatomic clock reads. Paul Robinson's note
generated a welter of messages. I recommend we wait until NEXT
January, and try again. PGN]
Actually, it's even worse than Dave is saying. See, UTC was adopted in
1961, but the leap second system was not adopted until 1972. For at least
some of the years in between, when adjustments in UTC were needed, the *rate
of time* was changed. That is, instead of extra seconds, there would be
*longer* seconds (and proportionately longer milliseconds). So the true
conversion of a time stored in milliseconds since some time in 1582 is
complicated indeed!
Recommended reading: "Greenwich time and the discovery of the longitude"
by Derek Howse (1980, Oxford University Press, ISBN 0-19-215948-8).
Mark Brader SoftQuad Inc., Toronto
[email protected]
------------------------------
Date: Fri, 6 Jan 95 16:47:59 PST
From:
[email protected] (Erann Gat)
Subject: Re: Dates and times not matching in COBOL
Actually, there are TWO bugs. The T$ in line 160 [which should be 150]
should be T1$. The program specification was that it should make N calls to
DATE$ and 2N calls to DATE$, so these really are bugs, not just alternative
interpretations.
E.
----------------------------------------------------------------------
Date: 22 December 1994 (LAST-MODIFIED)
From:
[email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <
[email protected]>
(Dennis Rears <
[email protected]>). UK subscribers please contact
<
[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<
[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.
CURRENT ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username,
password;
[email protected] and WAIS are alternative repositories.
Risks can also be read on the web at URL
http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to
[email protected])
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot send E-mail to
[email protected] .
------------------------------
End of RISKS-FORUM Digest 16.74
************************
