Subject: RISKS DIGEST 12.42

Subject: RISKS DIGEST 12.42
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Monday 30 September 1991 Volume 12 : Issue 42

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents:
Dialup lottery (PGN)
Space Station Software Hubris (David Bremner)
Re: V-22 Osprey (Henry Spencer)
Re: Risks of computerized typesetting (Lauren Weinstein, Gene Spafford)
Re: Radio Shack computerized mailing list problem (John R. Levine, et al.)
Re: eelskin wallets and magnetic cards (Robert Ullmann, et al.)
Re: Have you tested your machine lately? (Bennet Yee, Henry Spencer)

The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with relevant, substantive
"Subject:" line. Others ignored! REQUESTS to [email protected]. For
vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 12, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
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.

----------------------------------------------------------------------

Date: Sat, 28 Sep 91 12:32:14 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: Dialup lottery

A followup on the Nintendo Lottery noted in RISKS-12.41 is contained in an AP
item from 28Sep91 regarding a Minnesota law forbidding minors from gambling:

Lottery officials and lottery vendor Control Data Corp. of
Bloomington say the game will have safeguards to prevent children
from gambling, including personal passwords for users.

I'm glad that solves the problem so easily. By the way, I will be East for a
week for the National Computer Security Conference, where I expect to see quite
a few of you. Among other things, Ken van Wyk (VIRUS-L and SEI.CMU) and I will
be on a panel Tuesday on the risks of distributing security information
electronically. That should be amusing, at least for the two of us.

A few of you have commented on some funny spellings in the masthead first line.
Please recall that on two-digit Wednesdays and Saturdays in September we have a
line longer than 80 characters -- resulting in the issue number getting TRUNCATED
unless I foreshorten the line a little.

------------------------------

Date: Mon, 30 Sep 91 12:10:51 PDT
From: [email protected] (David Bremner)
Subject: Space Station Software Hubris

In the Fall 1991 issue of Graduate Computerworld ( A free publication
consisting of promo articles on prospective employers ), there is an interview
with Julius Gabriel, manager of software engineering at Spar Aerospace.

Spar is doing the software for the Mobile Servicing Station; essentially a
mobile version of the Canada-Arm. Gabriel notes that "The entire space station
will be highly computerized, with a software program in excess of 10 million
lines of code". Apparently the MSS will be a rather small fraction of the
whole, about "half a million lines of code".

Master of understatement, Gabriel notes that "Once its up there it's difficult
to fix the software". The article notes that "Naturally, the entire software
process adheres to rigorous standards such as the military 2167A standard".
Gabriel makes some good points about the importance of software development
methodology, but what worries me is the attitude that writing ( working ! ) 10
million line programs is a solved problem, that all we have to do is use Ada
(TM AJPO) and mil-std 2167A, and everything will work fine.
David

References: Page 14, Fall 1991 _Graduate Computer World_
[email protected] ubc-cs!fornax!bremner

------------------------------

Date: Sat, 28 Sep 91 18:44:45 EDT
From: [email protected]
Subject: Re: V-22 Osprey (Wodehouse, RISKS-12.41)

>consider the case in which the triple sensors are not "reverse-wired" but
cross-wired (e.g. sensor 2 is connected to input 1 & vs). In this case, with
"all good" everything is fine. If 3 fails all is ok. However if 1 or 2 fails,
the other is reported failed, voted out...

Things can get even more interesting if there is more than one set of
wires to the sensors, e.g. for feedback control of some kind. The second
Saturn V test launch had a double engine failure in the second stage that
was traced to such a problem: one engine did indeed develop problems,
but the "shut down" command from the control computer went to the neighboring
engine instead.
Henry Spencer at U of Toronto Zoology utzoo!henry

------------------------------

Date: Sat, 28 Sep 91 18:01:41 PDT
From: [email protected] (Lauren Weinstein)
Subject: Re: Risks of computerized typesetting

This is a classic case where technology can render traditional publication
proofing useless if the technology is used inappropriately without
proper checks and balances.

In the traditional publishing environment, the galley proof usually
has a photographic relationship to the final product. "Blue line"
proofs for books are normally made from the same negatives that are
then used to create the actual printing plates.

The whole point of the galley or blue line proof is to give the author(s) an
accurate representation of the final appearance of their work for their
approval. When authors are placed in the position of approving a "proof" that
does *not* represent that actual output that will be used to create the final
plates, much of the point behind having the proof in the first place is lost.
In the case where a font happens to vary in an unexpected manner (as in the
case under discussion) this can be a rather serious problem.

Authors should refuse to sign off on their works until their publishers supply
them with a physical proof (not just an online representation unless it is a
direct scan of the actual proof itself) that accurately shows the final output
from the correct output device, complete with all fonts in their final forms.

--Lauren--

------------------------------

Date: 29 Sep 91 01:33:01 GMT
From: [email protected] (Gene Spafford)
Subject: Errata for "Practical Unix Security"

As reported in RISKS-12.41, Simson Garfinkel described how a non-standard font
set-up on a phototypesetter caused some problems with the printing of our book.

What follows is the announcement O'Reilly & Associates (the publisher) has made
about this error. No word yet on what they are going to do with (or to!) the
shop that did the printing! We breathlessly await the third printing to see
what goes wrong there. :-)

O'Reilly & Associates has discovered that in the first printing of
_Practical_UNIX_Security_ by Simson Garfinkel and Gene Spafford (June, 1991) a
formatting error caused the grave quotes (`) in the shell scripts in our final
PostScript files to be printed as forward quotes ('). Of course, this breaks
the scripts and is certainly not what the authors, editor, or publisher
intended.

An errata sheet is available from the publisher that corrects these shell
script examples and other minor technical errors found in the first printing.
Please telephone O'Reilly & Associates at 800-338-6887 (US & Canada) to obtain
a copy of this sheet. Alternatively, you may send email to [email protected], to
request a copy of the errata sheet -- be sure to include your surface mail
address.

We apologize for any difficulties these errors may have caused!

------------------------------

Date: 29 Sep 91 22:54:25 EDT (Sun)
From: [email protected] (John R. Levine)
Subject: Re: Radio Shack computerized mailing list problem

Joseph Poirer writes about getting a receipt with someone else's name on it
when he declined to identify himself at Radio Shack, and wonders if their
computer system can't handle a transaction without a name.

It turns out that this isn't a computer problem, it is simply a management
problem. Radio Shack employees get a bonus if they capture more than 95% of
their customer names, and the employees are reacting in a locally rational
way to anonymous customers. Rat Shack has severe penalties for employees
who make up names, but apparently using the wrong real name is so far OK.
It is easy to ring up a sale with no name, I get them to do it all the time.

Rat Shack claims they use the names only for their own mailing list which
they do not sell, but at least one person has reported getting junk mail
from other parties with the same distinctive misspelling as Rat Shack has.

Personally, if they hassle me when I decline to give my name, I make one up.
Sometimes when I'm in a bad mood, I make one up unprompted. Phooey.

John Levine, [email protected], {spdcc|ima|world}!iecc!johnl

[This incentive to capture your vita was also noted by a bunch of
other contributors, several of whom noted this discussion went on
earlier for some time in comp.dcom.telecom. I therefore omit a
whole slew of similar responses. You will understand if I do not
enumerate you all! PGN]

------------------------------

Date: 28 Sep 91 16:13:21 EDT
From: Robert Ullmann <[email protected]>
Subject: re: eelskin wallets and magnetic cards

Kraig Meyer [in RISKS 12.41]: "USC security also claims that keeping the card
in an eel-skin wallet will erase the magnetic strip (anyone have any idea why
this would be?)"

This is an old Urban Legend, about eelskin (or snake, alligator, etc) purses
and wallets. The explanation isn't some strange electro-magnetic effect of
reptile skin. It is that such things often (usually?) have magnetic clasps!

Apparently this has to do with the skin not having the mechanical strength of
(e.g.) leather; where a mechanical clasp would tear the eelskin under stress,
the magnetic clasp simply opens.
-- Robert Ullmann

[Not surprisingly, we have slithered down this path before, WAY
BACK IN RISKS-6.25 and RISKS-8.04 (Jane Dunlop Smith)!!! However, we
have some alert contributors who again noted the mag clasp. This time
* [email protected] (Robert J Woodhead)
* [email protected] (Dave Platt)
* [email protected] (David King) and
* [email protected] (Kent Borg)
all had puns on electric-eel-skins.
* Al Stangenberger <[email protected]>
noted the version that several women who carried magnetically
encoded BART (subway) tickets in their eel-skin wallets noticed
that the magnetic strips had been erased.
Also noting the bogosity of the magnetic clasp effects were
* [email protected] (Henry Spencer) and
* [email protected] (Rich Greenberg)

------------------------------

Date: Sat, 28 Sep 91 18:22:04 -0400
From: [email protected]
Subject: Re: Have you tested your machine lately? (Sandberg, RISKS-12.41)

The fact that division by zero does not generate a fatal error but gives a
special value is a property of IEEE 754. Likewise with 0/0 == ``Nan'' (Not a
Number), etc. I won't repeat the arguments as to why this may or may not be
appropriate, but if you'd look at the ``See Also'' section of the math(3M) man
page, you'd see references to several papers that address the design -- Kahan
(the principle designer of 754) is quite compelling as to why 754's behavior is
most reasonable.

Is this a risk of coding without being cognizant of industry standards? Coding
to an internal model of the machine that doesn't match reality?

>Also if you notice on the output that the results are different depending on
if you optimize or not.

The fact that your code outputs ``Nan'' when it should have given ``+Infinity''
or ``-Infinity'' is probably a compiler bug. From the excerpt of the output,
it appears that the behavior *with* optimization turned on is correct. This is
actually a little surprising, since typically the optimizer introduces bugs,
not the other way around. A risk of testing/debugging only that which we think
is hard/bug-prone and skimping on the rest?

Complaining about the compiler/floating point hardware to your vendor would be
quite appropriate; complaints about IEEE 754 should probably go to Kahan
instead. :) Risks of blame misattribution?

Bennet S. Yee Phone: +1 412 268-7571 Email: [email protected]
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890

------------------------------

Date: Sat, 28 Sep 91 18:58:48 EDT
From: [email protected]
Subject: Re: Have you tested your machine lately?

>We have an Alliant fx/800 computer...
... By default no action is taken on many of the exceptions.
... I do not know the exact reasons for this decision, it might have to
do with performance, but who cares if the machine is fast if the answers are
wrong?

Very probably it's a performance issue. I don't have any detailed
knowledge of the Alliant, but I do know that this is a generic problem
with attempts to build seriously fast computers: if you want to move
fast, you have to go pretty much in a straight line. Any situation
where a departure from sequential flow might occur, *and where it has
to occur in a predictable way*, incurs major complexity and potentially
serious delays to make sure everything is synchronized just in case.

Folks interested in such things should read "Putting UNIX on Very Fast
Computers", by Mike O'Dell, in the Proceedings of the Summer 1990 USENIX
Conference. Mike was Chief Computer Scientist at now-defunct Prisma, which was
trying to build a Cray-class SPARC. (USENIX can be reached, e.g. about
availability of proceedings, at [email protected].)
Henry Spencer

------------------------------

End of RISKS-FORUM Digest 12.42
************************