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 18 Issue 37

Thursday 22 August 1996

Contents

o Karpov versus the world via Internet
PGN
o SSN problem hits a Congressman
Stanton McCandlish
o Easy answer on porno?
Tim Barmann via Dave Farber and Stanton McCandlish
o Rich folks embrace digital privacy and anonymous markets
Peter Wayner
o Re: Internet Explorer security problem
Thomas Reardon
o Inability to tinker not confined to hardware
Scott Alastair
o Re: Computer testing of nuclear weapons
Robert Herndon
Mark Stalzer
Barry Jaspan
Frank C. Ferguson
o Measuring software time to repair
Stu Savory
o Long-running systems
Martyn Thomas
o Call for Participation: SEI Conference on Risk Management
Carol Biesecker
o Info on RISKS (comp.risks)

Karpov versus the world via Internet

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 22 Aug 96 14:46:39 PDT
An unusual kind of Internet chess game will be held next week in Finland,
sponsored by Telecom Finland.  Anatoly Karpov will be pitted against the
consensus of a collection of on-line participants, estimated to be around
50,000 in number, where after each of Karpov's moves the wannabes get 10
minutes of real time to think, and a Telecom computer will pick the most
popular move.  Check out http://www.tele.fi/karpov for details.

What are the risks?

  1. What if 100,000 opponents show up and overwhelm the website?

  2. Will a dumbed-down consensus result?  Can a few master-level players
     have any impact over a horde of average players?

  3. How can any coherent strategy emerge from such a consensus strategy?

  4. Could the resulting somewhat randomized strategy actually be more
     effective than a more coherent strategy?  (Garry Kasparov had an
     interesting time figuring out IBM's Deep Blue strategy, and beat it
     with a less coherent approach than he might normally have taken.
     See RISKS-17.79.)

  5. Could Kasparov hack his way into tele.fi and reprogram the software
     so that only HIS move was tabulated?  Certainly the organizers could
     do that, but it would spoil the fun.

  6. Could Karpov use a Finnish anonymizer and then, if he lost, repudiate
     the results by claiming it was really Kasparov who was playing?


SSN problem hits a Congressman

Stanton McCandlish <mech@eff.org>
Thu, 22 Aug 1996 11:35:54 -0700 (PDT)
I received a press call this morning asking about Social Security Numbers
and database privacy in general, from a journalist covering a story that
should have happened years ago.

A US Congressman running for Governor of New Hampshire was found to have
two SSNs by local journalists, who ran a story on it. (It's illegal to
obtain 2 SSNs in most circumstances, so one supposes this seemed newsworthy).
After the story ran, it turned out that the other SSN belonged to a teenager,
and that the legislator had been assigned the number (presumably in some
marketing or DMV or other error-prone database) by mistake. Despite the
situation not being the legislator's fault, his chances for election to
the Governor post have been damaged by the bad reportage, possibly ruined.

At this point, I don't have the name of the legislator, nor of the paper
and journalist(s) who reported on this.


Many obvious RISKs that have come up before plenty of times in RISKS:

1) SSNs are not a good system - they are neither truly unique
identifiers, nor is the system even close to immune from errors or fraud.

2) Even "minor" data entry errors in databases of personally identifiable
information can ruin careers and otherwise wreck people's lives, but there's
not really any easy way to detect these errors or to fix them until they
cause a personal, or sometimes far broader, catastrophe.

3) There is no real accountability, even aside from privacy issues. State
laws are scattershot and disparate, affording little privacy protection
and even less recourse when negligence wreaks havoc. They are so
different from state to state that even an industry-generated code of
conduct doesn't arise. At the federal level, it's even worse.

4) Reporting on technical topics, like information held in databases, can
be rapidly screwed up if the reporters do not take care to get the facts,
but simply report what seems obvious on the surface. (C.f. Time's
"Cyberporn" cover story for another infamous example.)

5) Blind trust in technology - "the computer is always right" - can lead to
quite harmful mistakes. It appears that the reporters who jumped on this
story accepted it as a given that the legislator had obtained two SSNs
for some nefarious purpose, and missed the far more likely possibility:
data entry error by a third party.

[This is based on what I've been told about these events and the
reportage of them. I have yet to see the original articles, though I
expect to get them shortly.  So, some of this criticism is best considered
hypothetical, until I do have the articles.  I cannot, of course, be
certain of the accuracy of the characterization by one journalist of
another and his/her work.]

As for why I say this should have happened a long time ago, this is the
first time I've heard of something like this happening to a policymaker.
Hopefully the nature of the problem will sink in and we'll see some action
to establish accountability and privacy-protection requirements.  At very
least, the dismal failure of the SSN may become more apparent to Congress,
who have simply not appeared to grasp the nature of the problems to date.
The new crypto-awareness on the Hill could use a strong booster shot of
general privacy awareness.

Stanton McCandlish  Electronic Frontier Foundation  mech@eff.org
"http://www.eff.org/~mech/"

  [This saga is quite skimpy, but is the best available at the
  moment.  I hope someone can fill in the details for us.  PGN]


Easy answer on porno? (Tim Barmann via Dave Farber)

Stanton McCandlish <mech@eff.org>
Thu, 22 Aug 1996 12:16:18 -0700 (PDT)
  [Via Dave Farber <farber@central.cis.upenn.edu>]

>From: Timothy Barmann <tim@cybertalk.com>
Subject: Warning from Family Circle Magazine

Got this amusing/disturbing press release from *Family Circle Magazine*,
apparently to promote an upcoming article. It reads:

>CERTAIN COMPUTER FILE LETTERS INDICATE PORNOGRAPHY: POLICE CHIEF
>
>New York -- Parents can safeguard their children against pornography on
>the internet by watching for files stored on a computer's hard drive or
>diskettes that end in the letters -PCX, -GIF, -GL, TIF, or -JPG, according
>to the current (September 17) issue of Family Circle.  "Those are the
>graphic image files that may be pornographic, and parents should know what
>they illustrate," says Police Chief Alfred Olsen, who monitors online
>predators in Pennsylvania.

I'm surprise that TXT was left out, which of course is the format used to
distribute sexually explicit words as well.

Timothy Barmann, *Providence Journal-Bulletin*  tim@cybertalk.com
401-277-7369  http://www.ids.net/~tim/  http://www.ids.net/cybertalk/


Rich folks embrace digital privacy and anonymous markets

Peter Wayner <pcw@access.digex.net>
Tue, 20 Aug 1996 21:18:10 -0400
Two items from the recent news:

1) The August 7th edition of the WSJ has a front page story on the divorce
of cellular phone king, Craig McCaw. Here's the salient phrase, "... Mr.
McCaw says in an interview via a wire-line phone to which he entrusts all
sensitive conversations because he is leery of eavesdropping on his cellular
calls." Given that the call was at least partly on the record, I wonder how
he handles his truly sensitive calls.

2) The August 20th edition of the NYT describes the effects of the recent
settlement between NASDAQ and the SEC. The NASDAQ marketplace is essentially
a computer network that links a group of dealers who use the system to make
announcements like "I want to buy Microsoft for 92 dollars/share." A
brokerage firm will often make a profit on the difference and not pass it on
to their customers. If someone breaks the spread, all of the brokers suffer
but the customers generally gain a small advantage. The SEC now has audio
tapes of some dealers using collusion and social pressure to keep the
spreads up between the price the shares are offered to buy and sell.

There is also another market ran by Reuters known as "Instinet" and it is
anonymous. No one knows who is offering to buy and sell shares. If someone
breaks from the pack and starts offering slightly more money for a
particular issue, there is no easy way for the dealers to retaliate. It's
all anonymous. The article suggests that prices are often fairer for the
people who use Instinet. Of course it is only open to big folks like
institutional investors. Presumably it is not truly anonymous and the SEC
could unwind the trades if it wanted to investigate, say, insider trading.


Re: Internet Explorer security problem (Felten, RISKS-18.36)

Thomas Reardon <thomasre@MICROSOFT.com>
Thu, 22 Aug 1996 15:49:33 -0700
  >We have discovered a security flaw in the current version (3.0) of
  >Microsoft's Internet Explorer browser running under Windows 95.  An
  >attacker could exploit the flaw to run any DOS command on the machine
  >of an Explorer user who visits the attacker's page.

We now post the virus warning dialog on local files (file: urls).  We have
always posted it on remote files (http: urls).  Note that the root of the
problem is not Java or the browser, but in macro-enabled applications.  IE3
has a mechanism to warn users about safety of documents when used with
common macro-enabled applications.  We are have updated Microsoft Word such
that by default it will not run macros embedded in documents.

-Thomas


Inability to tinker not confined to hardware

"Scott Alastair (Exchange)" <ScottA@logica.com>
Wed, 21 Aug 1996 15:09:33 +0100
People can't tinker with software either these days ... for example,
there is no programming language supplied with Windows 95.

>From this, a RISK is that a program of any degree of triviality may be seen
by a lay person as miraculous. I wrote a Word for Windows macro to generate
chess board positions out of sheer necessity - I needed pictures for a
magazine article I was writing and no software I had could generate them
easily. I then realised that my macro might be useful to other people. So I
uploaded it to an archive site - and the response was phenomenal, with
emails coming in by the dozen praising what I have done. Yet the macro is
made up of about fifty lines of code, there are no devious tricks and the
algorithm used to generate the chess board from user input is relatively
simple. I am a software engineer; if I was incapable of writing such a macro
I would wonder whether I was fit to be called a software engineer.

Who was it who wrote that "any sufficiently advanced technology is
indistinguishable from magic"? They are right, and they are becoming more
than right.

Alastair Scott <scotta@logica.com>


Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)

Robert Herndon <robert.herndon@Central.Sun.COM>
Wed, 21 Aug 1996 18:12:24 -0600
Frank Ferguson <ferguson@dmapub.dma.org> notes in RISKS DIGEST 18.36 that
the U.S. Department Of Energy has signed a US$94M deal with IBM to develop
a new supercomputer designed specifically to simulate nuclear explosions.
Frank's conclusions, however, don't follow.

The U.S. DOE is almost certainly the worlds' largest consumer of high-speed
computers used for simulation, and has in fact been instrumental in the
funding and development of these computers.  Richard Rhodes' books on
the development and construction of the first A and H bombs makes this
abundantly clear, as do many other books on the subject, and others on
other subjects (e.g., Richard Feynman's book that mentions his activities
during WWII).  Many U.S. DOE atomic labs already have large supercomputer
centers devoted to simulation.

While the purpose of the computers is to simulate nuclear events, their
intended purpose is not generally to eliminate all nuclear tests.  The
computer codes are worth discussion.  They are, as a former chairman of
CDC noted in a speech many years ago, the human race's best understanding
of nuclear events.  As a result, these codes are highly classified.  A
great many complex, coupled, and inter-related phenomena occur during an
explosion.  Among them are radiative, particle, and shock phenomena.  The
need for models of these phenomena was probably first determined by Hans
Bethe, several years before the first A bomb explosion, and it was also
he who first developed the idea of Monte Carlo (probabalistic) simulation.

While the physics of each individual aspect of a detonation is well
understood, their coupling is very complex.  E.g., radiative opacity
is determined in part by temperature, which is affected by radiative
and particle absorption.  Many of the constants affecting these
phenomena and their couplings cannot be determined accurately by
a priori computation, and must be measured or approximated.

As a result, the computer models are the only way, other than actually
detonating a device, of accurately estimating the yield and efficiency
of a new design.  In complementary fashion, the only way of reliably
improving the accuracy of the simulation codes is fashioning devices
and measurement equipment and testing them.  This is in fact done.

Indeed, I have been given to understand by several knowledgeable people
that the purpose of nuclear tests is most often to verify improvements to
the computer models.  It is a deep-rooted need of humans to understand
the universe.  The codes modeling the detonation of nuclear devices would
appear to be monuments to this (cold-war fear, too, I imagine).  The rapid
development of the neutron bomb (er, "enhanced radiation device") would
appear to be a testament to the reliability and accuracy of these codes.
Certainly, the current efficiency of nuclear devices is such that extinction
of the human race can be safely assured, if such a goal is considered
desirable.  It becomes perhaps questionable, then, what additional
sophistication in the simulation and design of nuclear devices is intended
to accomplish, beyond satisfying this curiosity.

The risk is slight that the U.S. will design, build, and deploy nuclear
devices that fail to work due to failures of the computer models.  Fear
that physical/computer models might not be reliable was definitely
responsible for tests of cruder-than-necessary bombs (e.g., the USSR's
first A and H bombs, and several early U.S. devices (see Rhodes' books)).

The risk seems many orders of magnitude greater that, due to test bans,
the U.S. will spend large sums of money simulating and designing nuclear
devices that it cannot test, manufacture, or deploy.  In the absence of
test ban treaties, the risk is that the U.S. will detonate additional
devices to verify the more complex models that the faster computers will
allow (highly probable).

Robert Herndon


Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)

Mark Stalzer <stalzer@macaw.hrl.hac.com>
Thu, 22 Aug 1996 13:53:13 -0700
In RISKS-18.36 Frank C. Ferguson <ferguson@dmapub.dma.org> takes some
issue with the idea of relying on computers to design nuclear weapons.
He writes in part:
>I guess eliminating an actual explosion, or "rapid disassembly" as the Air
>Force labels it, would reduce a lot of risks, wouldn't it?  Hmmmm.
>
>I suspect we would soon be building weapons that would never work when the
>real trigger was actually squeezed.

Computers are useful for many simulations related to nuclear weapons
other than designing clever little devices that rapidly disassemble in
spectacular ways. A few examples are:

a. predicting the destructiveness of a particular device with known
 characteristics (determined by testing) when used in a particular area.
b. predicting the fallout in various geographic areas and weather conditions.
c. finding out what happens if a device is accidentally smashed, eg.
is unintentionally dropped from a plane (this has happened many times!),
does it blow up or is the bomb stuff contained?
d. performing fusion energy experiments prior to building the apparatus.
e. refining existing designs and exploring completely new concepts.

Many tasks involve taking known weapons and exploring their behavior in
situations where real testing is impossible. Even if the US stopped all
weapons design, there would have to be a lot of simulation just to
explore the capabilities, limitations, and safety related issues of the
current stockpile.

Some WWW references to IBM's and Intel's new machines and their
applications are:
  http://www.austin.ibm.com/Cover/Announce.960726/doepress.html
  http://www.ssd.intel.com:80/tflop.html
It should be noted that weapons work is just a part of what's planned
for these next generation supercomputers.

Mark Stalzer, mas@acm.org

  [Other comments on this topic also received from
     "Christopher Duro" <cduro@softkey.com>
     nelson@berlioz.nsc.com (Taed Nelson)
     Jerry Bakin <bakin@haas.berkeley.edu>.
  PGN]


Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)

"Barry Jaspan" <bjaspan@MIT.EDU>
Wed, 21 Aug 1996 15:06:07 -0400
I recently pointed out how the plot of the movie _The Running Man_ was
the same as a something suggested here in RISKS.  So I cannot avoid
mentioning:

<> to use the new computer ... to determine which country wins a war without
<> actually fighting the war.

The original Star Trek episode "A Taste of Armaggedon" was based on exactly
this premise.  There is nothing new under the sun...

Barry

  [Noted in greater detail by "Jonathan I. Kamens" <jik@cam.ov.com>.  PGN]


Re: Computer testing of nuclear weapons (RISKS-18.36)

"Frank C. Ferguson" <ferguson@dmapub.dma.org>
Thu, 22 Aug 1996 14:56:43 -0400 (EDT)
  [In response to Jonathan Kamens noting Star Trek was 30 years ago.]

Actually I think the ancient Chinese were the first.  They simply assembled
opposing armies on opposite hilltops while the intermediaries met in the
valley.  They decided which army was most likely to win and then they all
returned home.

Frank Ferguson


Re: Measuring software time to repair

Stu Savory <savory.pad@sni.de>
Wed, 21 Aug 1996 10:03:08 +0200
Further to David Holland's comments...

Here (at Siemens Nixdorf Informationssysteme) incoming bug-reports
are classified 1 through 4 in severity level as perceived by the user.
They are also classified according the department responsible for the
code (1 through N). For each of these 4*N classes we have the historical
statistical distributions of (inter alia) bug fix times and bug densities
as well as improvement trends (and some other correlations ;-)

Inasmuch as one is able to predict the future statistically from the past,
we are able to say something like "There is a (50/90/99%) chance that this
bug will be fixed within time T".

I don't think you can do much better than this in the long run. I tried
training a neural net last year, but the prediction accuracy doesn't seem to
be much better (usual statistical test).

Dr. Stuart Savory  Dept. of Quality & Customer Satisfaction.


Long-running systems

Martyn Thomas <mct@praxis.co.uk>
Wed, 21 Aug 1996 10:56:22 +0100 (BST)
We have had a request from a client to rerun the training course on how to
start a system we delivered to them. It hasn't stopped for 18 months and
they have lost confidence that they can restart it if they need to do so.

So, it isn't only systems that get patched and warm-booted that lose the
ability to be cold-booted.

Is this a risk arising from delivering high-quality software?

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:  +44-1225-444700.   Email:   mct@praxis.co.uk  Fax: +44-1225-465205


Call for Participation: SEI Conference on Risk Management

Carol Biesecker <cb@SEI.CMU.EDU>
21 Aug 1996 20:40:10 GMT
Call for Participation - Software Engineering Institute (SEI)
Conference on Risk Management: Managing Uncertainty in a Changing World
Hotel Cavalier, Virginia Beach, Virginia, April 7-9, 1997

Keywords: acquisition, programs, projects, systems, and software

Note:  this is an abbreviated call for participation [and excerpted for RISKS].
       For complete information, please see
          http://www.sei.cmu.edu/products/risk97

The SEI Conference on Risk Management will provide a forum that brings
together representatives of government, industry, and academic managers.
Practitioners, change agents, and researchers who use and explore risk
management, system development and acquisition will detail the latest
methods, tools, and techniques in the field.

This conference will provide a unique opportunity to
* Increase your awareness
* Advance your knowledge and skills
* Exchange ideas and experiences with experts
* Learn the latest methods, tools, and techniques and best practices
  of acquisition, systems development, and risk management
* Find out what's new, what's going on, and what could be useful for you

September 19, 1996: deadline for submitting papers and workshop proposals

For more information about the conference, contact--
SEI Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone  412 / 268-5800
FAX    412 / 268-5758
Email  customer-relations@sei.cmu.edu
World Wide Web  http://www.sei.cmu.edu

Please report problems with the web pages to the maintainer

Top