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 3 Issue 60

Saturday, 20 September 1986


o Sanity checks
Roy Smith
o Viking Flight Software working the `first' time?
Greg Earle
o A million lines of code works the first time?
Dave Benson
Herb Lin
o Re: Massive UNIX breakins at Stanford
Scott E. Preece
o Re: Protection of personal information
Andy Mondore
Herb Lin
o Announcement of Berkeley Conference on the SDI
Eric Roberts
o Info on RISKS (comp.risks)

Sanity checks

Roy Smith <allegra!phri!roy@seismo.CSS.GOV>
Fri, 19 Sep 86 16:43:39 edt
    I'd like to relate 3 incidents along the lines of people willing to
believe anything the computer tells them, what I call the "if it's on
green-bar, it it must be true" syndrome.

    Incident #1 was two weeks ago.  I got 2 items for $5.95 and $8.95
at our local Radio Shack.  There was no tax on this sale and I quickly came
up with $14.90 in my head (if that's not right, I'm going to be *really*
embarrassed).  The sales clerk grabbed a calculator and came up with $14.93.
I'm not so upset at the fact that he came up with the wrong sum, but that
he didn't apply the trivial check that if you have a bunch of numbers, all
ending in 0 or 5, the sum must also end in 0 or 5.  Moral:  Always check
your results for sanity and never trust the clerks in Radio Shack.

    Incident #2 was a few days later.  In a discussion of very large
memories I mentioned that 200 bits is the biggest address you would ever
need and that 2^200 was about 10^40 (see usenet's net.arch for the past few
weeks).  How did I come up with that?  Easy, I just fired up a desk
calculator program, typed "2^200" at it and it typed back "1.70141e+38".

    Now, I *knew* this was too small (at 3 or 4 bits per decimal digit
I expected about 10^65) so I tried it again.  Since it gave the same answer
again, I figured it must be right.  Of course the problem was overflow (you
would think that by now any time I see a Vax print out 1.7e38 a bell would
go off in my head).  This is even worse than the clerk in Radio Shack; here
I had 2 reasons to suspect the answer was wrong and I still blindly
believed what the computer told me!  Moral: Always check your results for
sanity and don't get a big head thinking you're smarter than the clerks at
Radio Shack.

    Incident #3 was a few years ago.  We got a FORTRAN program to
predict protein secondary structure (feed it a sequence and it says where
it's alpha-form and where it's beta).  We fired it up and it ran so we put
it into production use.  It showed a lot more beta then we expected, but it
never occurred to us to suspect the program — the algorithm was known to
slightly over-predict beta and we were perfectly willing to believe that
the outrageous amount of beta we were getting was due to that.

    To get to the point, the program was from a Vax and we were running
it on a pdp-11.  The input (3-letter codes) was stored in INTEGER*4's,
quitely truncated to INTEGER*2's by the compiler.  Most of the codes are
distinct in the first 2 letters so this was usually ok.  It was, however,
turning aspartic acid into asparagine (asp->asn) and glutamic acid into
glutamine (glu->gln); both those substitutions tend to result in more beta
form!  It was weeks before somebody spotted that the annotated sequence the
program printed out didn't match the input.  Moral #1: Always use sanity
checks, but don't blindly rely on them; if your check is "x > y", think
before you accept "x <> y" .  Moral #2: If the program provides aids like
echo printing of input, use them.  Moral #3: If you're modifying a program
or porting it to a new machine, do regression testing.

Viking Flight Software working the `first' time?

Greg Earle <elroy!smeagol!gorbag!>
Wed, 17 Sep 86 21:35:44 pdt
Correct me if I am wrong, but for any spacecraft that I know of, virtually
every major spacecraft function can be exaustively tested on the ground
before the thing ever leaves the pad.  About the only thing you can't test
(obviously) is the software to actually physically separate the lander from
the command module on descent into the atmosphere.  Everything else, to
my knowledge, can be covered pretty thoroughly.  The projects that I am
associated with, here at JPL, are involved with test sets that test all
the functions of the spacecraft Command Data Subsystem (CDS) which is also
called the Payload Data System (PDS) on Mars Observer.  In other words,
this exercises the flight software that resides in the command data subsystem,
and telemetry streams are initiated, commands are uplinked, etc. etc.

Now maybe we want to pick nits and say "Well it worked the first time in
Actual Outer Space Usage", which is true, but considering the amount of
testing done beforehand (we are now testing breadboard CDS's for missions
that won't launch until at least 1991), 'tis not all that surprising
when it works ...

    Greg Earle      UUCP: sdcrdcf!smeagol!earle; attmail!earle
    JPL         ARPA: elroy!smeagol!
        AT&T: +1 818 354 0876   earle@JPL-MILVAX.ARPA

Anonymous contribution

18 Sep 86 20:21:00 EDT
    that effect, from an SDI spokesman referring to a recent test.

Let's take this with a grain of salt.  I have seen a large system (over
100,000 lines of high-level language) "work the first time". By this I
mean that in the first live test of the system, it performed as designed
with no errors.  That software had been designed and programmed by a
small, close-knit group of experienced real-time programmers, and had
been extensively tested at the module level with drivers and stubs, and
also at the system level using a very realistic simulation. (Also bear
in mind that the first live test of *any* system is likely to be quite
conservative in its objectives; it's likely that only a small fraction
of all possible paths through the code will actually be exercised.) 
Furthermore, the 100K lines of code that made it to the first live test
were by no means the original, first-cut 100K lines written (although a
gratifyingly large percentage of them were, thanks to good design

If the SDI test were a similar situation — well-designed, thoroughly
pre-tested software that worked well on its initial, conservative live
test — then it's at least plausible.  If, on the other hand, the
spokesman actually meant "we coded up 1,000,000 lines and then tried
them and they all worked" — then I'd have to see some proof (in fact, a
*lot* of proof) before I'd believe it. 

A million lines of code works the first time?

Dave Benson <benson%wsu.csnet@CSNET-RELAY.ARPA>
Tue, 16 Sep 86 16:56:14 pdt
 |Heard on NPR's "All Things Considered" yesterday evening:
 |An Air Force Lt. Col., speaking about a kinetic energy weapons
 |test earlier this week, which apparently went better than expected
 |in several respects.  If this isn't an exact quote (I heard it
 |twice, but didn't write it down at the time), it's real close:
 |"We wrote about a million lines of new computer code, and tested
 |them all for the first time, and they all worked perfectly."

Hoo boy!  I would appreciate any and all leads by which I might track
this to some reliable source.  Thank you,  David B. Benson, Computer
Science Department, Washington State University, Pullman, WA 99164-1210.
csnet: benson@wsu

I found one! (A critical real-time application worked the first time)

Wed, 17 Sep 1986 12:44 EDT
    From: Dave Benson 

Re: Massive UNIX breakins at Stanford

"Scott E. Preece" <preece%ccvaxa@GSWD-VMS.ARPA>
Thu, 18 Sep 86 09:12:59 cdt
> From: reid@decwrl.DEC.COM (Brian Reid) The machine on which the initial
> breakin occurred was one that I didn't even know existed, and over
> which no CS department person had any control at all. The issue here is
> that a small leak on some inconsequential machine in the dark corners
> of campus was allowed to spread to other machines because of the
> networking code. Security is quite good on CSD and EE machines, because
> they are run by folks who understand security. But, as this episode
> showed, that wasn't quite good enough.

No you're still blaming the networking code for something it's not supposed
to do.  The fault lies in allowing an uncontrolled machine to have full
access to the network.  The NCSC approach to networking has been just that:
you can't certify networking code as secure, you can only certify a network
of machines AS A SINGLE SYSTEM.  That's pretty much the approach of the
Berkeley code, with some grafted on protections because there are real-world
situations where you have to have some less-controlled machines with
restricted access.  The addition of NFS makes the single-system model even
more necessary.

scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece

Re: Protection of personal information

Fri, 19 Sep 86 10:00:10 EDT
David Chase wrote in Risks 3.58 that at his university, students were
required to give a lot of personal information on a form before they could
sign up for on-campus job placement interviews and that by signing this
form, they authorized the university to release their transcripts to
potential employers.  He also complained about the use of the social
security number as the student number.

Here at RPI, I think the only form you are required to fill out before
getting on-campus interviews is a resume form.  I work in the Registrar's
office and we release a transcript only if we have received a signed
statement from the student authorizing release of the transcript to a
specific person or company.  As far as I know, we don't accept "blanket"

As for the use of social security numbers as student numbers — we also use
social security numbers for this purpose.  One of the reasons we do this is
that if you are receiving financial aid, we must verify your attendance
every semester to the agency supplying the aid.  Very often, this
verification is in the form of a computer-generated list or tape from the
agency and the only way to cross-reference their list to our file is via the
social security number.  It is usually difficult to do a computer-match on
name because of differences in how the names might be formatted.  There is
the same problem when a student has an on-campus job — the payroll office
needs to verify that the student is registered and they need the social
security number for tax purposes, so they prefer to use it as their primary
means of identifying the student (or any other employee).

In terms of requiring you to give us your social security number, federal
law prohibits us from requiring you to give it to us except for tax or
social security purposes.  However, the law has also been interpreted to
mean that we also have the option of not servicing you if you refuse to give
it.  (I don't think that has ever happened here, however.)

For the final word on what can and cannot be done with personal
information, I suggest you check the Family Rights to Privacy
Act (popularly known as the Buckley Amendment).

Protection of personal information

Thu, 18 Sep 1986 21:26 EDT
My understanding is that use of one's SS number must be authorized by law.
There are times when others ask, but you are not required to give it to them.

Under those circumstances, I don't believe it it is illegal to give a
fake SSN.  The way to protect yourself is to give your real SSN,
except for a small error that you can later blame on an entry error.

Announcement of Berkeley Conference on the SDI

Eric Roberts <roberts@src.DEC.COM>
Thu, 18 Sep 86 13:25:05 pdt
The Dave Redell/Hugh DeWitt panel (Saturday morning) should be of special
interest to RISKS readers and the rest of the program of general interest.


             A Conference on the Strategic Defense Initiative
          October 9-11, 1986, University of California, Berkeley

             Thursday Evening, 8:00-10:30, Wheeler Auditorium

Opening Debate:  "Technical Feasibility and Strategic Policy Implications
of the SDI"
   Andrew Sessler (moderator), Former Director of Lawrence Berkeley
      Laboratory; Member of American Physical Society Panel on Directed
      Energy Weapons.
   Lowell Wood, leader of "O Division," Lawrence Livermore National
   Richard Garwin, IBM Research Fellow; Adjunct Professor of Physics,
      Columbia University; Adjunct Research Fellow, Center for Science and
      International Affairs, Kennedy School of Government, Harvard
   Colin Gray, President, National Institute for Public Policy; Member of
      the President's General Advisory Committee on Arms Control and
   John Holdren, Professor of Energy and Resources, UC Berkeley; Chairman,
      U.S. Pugwash Committee; Former Chairman, Federation of American

               Friday Morning, 9:00-11:00, Sibley Auditorium

Legislative Hearing: "Keeping California Competitive in R&D: The Impacts of
Increased Military Spending, the SDI, and Federal Tax Reform" (This event
will be co-sponsored by the California Assembly Committee on Economic
Development and New Technologies.)
   Glenn Pascall, Senior Research Fellow, Graduate School of Public
      Affairs, University of Washington; President, Columbia Group Inc.
   Jay Stowsky, Research Economist, Berkeley Roundtable on the
      International Economy, UC Berkeley.
   Ted Williams, Chief Executive Officer, Bell Laboratories [invited].
   Robert Noyce, Vice-Chairman of the Board, Intel [invited].
   Ralph Thompson, Senior Vice-President for Public Affairs, American
      Electronics Association.
   John Holdren, Professor of Energy and Resources, UC Berkeley; Chairman,
      U.S. Pugwash Committee; Former Chairman, Federation of American

Documentary Film: "Star Wars: A Search for Security," produced by Ian
Thiermann for PSR, 11:30-12:00 and 2:00-2:30, Room 4, Dwinell Hall.

              Friday Afternoon, 3:00-5:00, Wheeler Auditorium

Panel Discussion: "The Effects of SDI on Universities"
   Marvin Goldberger (moderator), President, Caltech.
   Vera Kistiakowsky, Professor of Physics, MIT.
   John Holdren, Professor of Energy and Resources, UC Berkeley; Chairman,
      U.S. Pugwash Committee; Former Chairman, Federation of American
   Clark Thompson, Professor of Computer Science, University of Minnesota.
   Danny Cohen, Director, Systems Division, Information Sciences Institute,
      University of Southern California; Chairman, SDIO Committee on
      Computing in Support of Battle Management.

Please report problems with the web pages to the maintainer