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…
(Bruce Sesnovich - Sun ECD Information Architecture)
Subject: computer error and learned helplessness
In RISKS 6.38, Eric Herrmann relates his experience with a spurious electronic
debit. Fortunately, the bank discovered its error and Eric eventually got his
$60 back without having to raise a fuss. However, I believe that in general
such erroneous debits ought to be contested. Unless I am mistaken, the burden
of proof then falls on the banks to prove the cardholder has in fact withdrawn
the money.
The ATMs I'm familiar with here in Massachusetts are monitored by hidden
cameras, and I imagine the same is true of ATMs in other states. The banks
have recourse to the photographs taken by these cameras when a transaction is
contested.
Though I've not had the pleasure of contesting a debit to my account, I believe
my bank requires a nominal (~$5) service charge to investigate a transaction.
The fee is a hedge against slews of fraudulent appeals and is refunded if your
claim is borne out.
Eric's decision to "eat the $60 loss" seems to me an example of a pervasive
computer RISK: the learned helplessness that afflicts many people when
confronted with computer-related bureaucratic injustices.
I do not intend this message as a put-down of Eric. I believe many people
would have made the same choice he made. But who among us would have
complacently accepted being short-changed $60 by a human teller or a store
cashier?
Eric's statement: "but...I couldn't prove anything," reflects a common
attitude that, where computers are concerned, "you can't win, so why even
bother trying?" Isn't this attitude the flip side of overreliance and
unquestioning trust? In both cases there is the unwillingness to challenge
the myth of the computer's monolithic infallibility. Debunking this myth, it
seems to me, ought to be a goal of every concerned computer professional.
Bruce A. Sesnovich, Sun Microsystems, East Coast Division, Billerica MA
In Risks volume 6, issue 38, Paul Smee (Smee@AUCC.AC.UK) writes:
"I recently objected to a sales assistant trying to charge me an
amount I knew was wrong. 'The till [US cash register] says it's 12
pounds', she insisted. 'Why don't you believe it?'"
I was interested to find recently that ill-founded faith in the output
of calculating machinery has been with us as long as possible.
Consider the following (whose attribution should be obvious):
On two occasions I have been asked [by members of
Parliament!], "Pray, Mr. Babbage, if you put into
the machine wrong figures, will the right answers
come out?"
I am not able rightly to apprehend the kind of con-
fusion of ideas that could provoke such a question.
Sad to say, the modern public is no more wary of GIGO than were 19th
century MPs.
Ephraim Vishniac ephraim@think.com
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214
In RISKS 6.36 David Andrew Segal (dasegal@brokaw.LCS.MIT.EDU) relates an incident involving an ATM deposit that wasn't registered by the bank's computer. I am often amazed at the number of people who trust banks, stores, restaurants, etc, to never make mistakes. Apparently it is too much bother (or simply too difficult) to ever reconcile statements or verify receipts. Add to this the ability of computers to replicate human errors a thousand times a second, and we have a real RISK, for which there can be no technical solutions. This is a real [Sorry. The last word got lost! PGN] Darin I speak for myself, not for my employer.
Several years ago, I was using a calculator to add a series of numbers. The result "felt" wrong, so I did it by hand and found that the calculator had malfunctioned — for every digit on the display, 8's looked like 6's because one of the LED segments failed to light up. If I had been doing something more complicated than addition, I probably would never have spotted the problem. Maybe calculators should have some sort of "self-test" program built in which would be automatically invoked when the unit is powered up? Al Stangenberger Dept. of Forestry & Resource Mgt. forags@violet.berkeley.edu 145 Mulford Hall - Univ. of Calif. uucp: ucbvax!ucbviolet!forags Berkeley, CA 94720 BITNET: FORAGS AT UCBVIOLE (415) 642-4424
In RISKS-6.34 Joe Dellinger comments:
[discussion about linking and having variables change mysteriously]
> ... And if you don't happen to have the source code for one
>of the libraries that gets linked in, such as the FORTRAN runtime library,
>THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might
>get overlayed in this way...
Well, it's a known, long standing problem. In the natural environment of
Unix V6 (cooperative software development, all sources available) it was a
reasonable implementer's choice. In some other environments, not so.
The ANSI committee is aware of it, and has made a well-known work-around
(reserved leading underscore) part of their proposal. If the
only-available-in-binary library is part of the C language run-time system,
it is blatantly illegal.
This doesn't help much if it is a bought-in product: the general solution
to this requires a fair bit more work, equivalent to specifying an
Ada[tm]-quality linker as part of the language definition. I claim that
_that_ is easy. Others disagree.
It remains a risk.
David Collier-Brown, Geac Computers International Inc., 350 Steelcase
Road,Markham, Ontario, CANADA, L3R 1B3 (416) 475-0525 x3279
{mnetor yunexus utgpu}!geac!daveb
> ... if you don't happen to have the source code...
> THERE REALLY IS NO WAY YOU CAN KNOW AHEAD OF TIME what variable names might
> get overlayed in this way...
Actually it's not QUITE that bad. You can find out, but the procedure is
obscure and painful and nobody does it. (See the "nm" command, which can
be convinced to give you a list of all the global names in a library.)
The real problem here is not Unix-specific: name-space pollution. Smart
library writers are careful to use systematic naming conventions that a
user is unlikely to duplicate. The ANSI X3J11 C-standardization effort is
in fact trying to require this for the standard libraries.
Even less-permissive linkers can cause trouble when the internal name
spaces of libraries overlap.
Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
The described problem is not the fault of the linker, but of the design
of the Fortran language. If two programs each contain the line
COMMON /PC/PC
and they are compiled separately, then there is no mechanism by which
the compiler can declare that one program defines PC and the other
program uses PC. Subsequently, the loader must accept one or many
COMMON declarations to mean that a single object should be established
and all the declarations connected to it.
The risk, then, is in writing software in a thirty-year-old language
whose design preceded much of our understanding of software risks.
The C language definition rode on this convention to some extent; the
declaration "int pc;" outside a function is equivalent to "extern int
pc;". To declare a variable in a way that ensures ownership, initialize
the variable, e.g., "int pc=0;". (Of course, this will still silently
match the Fortran COMMON statement above.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
The following posting appeared in comp.sys.mac this evening. If you have any information about the virus reported in this posting, please speak up! From: borton@net1.ucsd.edu (Chris Borton) Subject: I've got a virus and I don't like it Date: 8 Mar 88 02:04:12 GMT Organization: UCSD Network Operations Group This is a warning and plea for more information, if anyone has any. We just discovered a virus in some of our systems (not all) at work today, and it has permeated my system at home as well. The symptoms are simple: INIT 32 in System File nVIR resources in various applications and the System File. This sucker is tricky — it is getting itself loaded before any INITs do (we believe the INIT 32 is just a teaser), like PTCHs do, but it isn't in PTCH. Our two best programmers spent today tracing through it and still haven't found a real solution other than offloading and re-initializing. To our knowledge it is non-malicious (yet). The nVIR resources are usually small, sometimes 8 bytes, sometimes ~360. If you remove them from both System and ResEdit, the virus won't let you run ResEdit because it is looking for those resources and can't find them. It occasionally beeps when running a program. We have no idea what installed this. We are fairly certain it originated from one of the many small programs that come over the net. Many of these would be perfect 'carriers' — little demo program that's an "aww, that cute, now let's trash it." I'm not putting down these programs, just pointing out what I feel is obvious. I don't believe this is any cause for panic — it hasn't done any known harm yet. I would, however, like to get to the bottom of this! If it's a joke, I don't find it very funny. (unless it de-installs itself completely after April Fool's Day :-)). If it is someone's graduate thesis, you get an A-. But enough is enough! Chris "Johann" Borton, UC San Diego ...!sdcsvax!borton borton@ucsd.edu BORTON@UCSD.BITNET
For anyone interested, I have compiled all the virus messages I could
find on virus, trojan horse and related topics from RISKS, Computers and
Society, INFO-IBMPC and INFO-MAC. The uneditted file runs to 70 pages.
(Anyone wanna publish a book?) For those in Canada, The Globe and Mail for
Monday, March 7, 1988, page C15, under the title "Devilishly clever viruses
may be lurking to devour your data" is telling everyone that you can recover
from a Trojan attack through a warm boot.
(And how many nanoseconds is your reaction time?)
[And James Ford <JFORD1%UA1VM.BITNET@CUNYVM.CUNY.EDU> has the
DIRTY DOZEN listing from Eric Newhouse on hacked/trojan/virus programs...
Much too much for posting. But there are no LAST words on this one. PGN]
>A quick warning about PC-LOCK (shareware). If.........version 1.0.....
I didn't know that one could consider PC-LOCK shareware.... :-)
Just as a note......the version of PC-LOCK that we're using here is
Version 3.0 on IBM PC/XTs. Also, the included text (reprinted without
permission) states the latest enhancements available on Version 3.0....
(quote)
Thank you for buying PC-Lock version 3.0. We believe you will
find it to be an effective and convenient security system for
your IBM-PC/XT/AT or compatible. Version 1.1 was reviewed in the
June 23, 1987 issue of PC-Magazine and listed among "The Best of
the Best Utilities." Version 3.0 provides enhanced security and
several new features including:
Simplified multi-system installation,
An administrator password,
Multiple user passwords,
Support for large hard disks,
Support for multiple hard disks,
Works with the EGA controller/display,
Ability to prevent user's from breaking out of AUTOEXEC,
and others described below.
(unquote)
The recent talk about setting time backwards reminds me of something that happened on the MIT Multics about 10 years ago. The Multics system clock counts time as number of microseconds since midnight, Jan 1, 1901 (well, maybe 1900, not sure). The microsecond clock value at the time when a file is created is used as unique identifier for the file; there is suitable gating to ensure that on a multi-processor machine, two processors don't get an identical clock value. In order to ensure that file unique IDs really are unique within a system, the Bootstrap system would not allow the ops to bring the Multics O/S up if the clock (set manually within BOS) was before the recorded time of the last shutdown. (Why HIS didn't put in a permanent battery backed up clock was always a source of wonder, but is another question.) One day, after a shutdown, the Ops mistakenly (finger trouble) input a date which was something like 2 days in advance of the real date — e.g. 14 March rather than 12 March — and started the Multics service. On realizing their error, they shut down Multics (back to BOS) to change the date to the correct one. The system would then not let them restart Multics. In that case (and after a couple of hours of poking thru microfiche) the system programmers decided it would be quicker just to leave the machine down for two days, than it would be to try to hack the system code to let them boot, and to ensure that there were no bad side-effects. (And, they thanked the gods that the Op had only missed by a couple of days, rather than getting the month, or worse, the year, wrong.) Ultimately, a 'fix' arrived, which consisted merely of having BOS query the Ops for confirmation if they tried to bring up Multics with a date-time more than a set interval after the previous shutdown. [I tried to GREP this one out of the RISKS archive, but did not find it. However, it is my vague recollection that this tale might have been related here somewhen in the distant past. Excuse me if you saw it before. PGN]
We seem to have had a flurry of problems with Feb 29. Please don't forget to watchout for Day 366 on Dec 31.
Here is the list of sources relating computers and SDI that I compiled.
Thanks to the people who sent me sources.
Dan Jones
Adam, John A. and Paul Wallich, "Part 1- Mind-boggling
complexity" IEEE Spectrum, September, 1985.
Bellin, David and Gary Chapman, Eds. "Computers in Battle".
Harcourt Brace Jovanovich 1987. in particular: "Computers in the
Strategic Defense Initiative" by Steve Berlin and Eric Roberts.
"The Strategic Computing Program" by Jon Jacky, (which includes
discussion of SCP's relationship to SDI).
Benson, David B., "The Second Labor of Hercules: An essay on
software engineering and the Strategic Defense Initiative".
Washington State University Computer Science Department, 1986.
Boffey, Philip: "Software seen as obstacle in developing 'Star
Wars'.", The New York Times, Sept. 16, 1985.
Buchsbaum, S.: "SDI software: the telephone analogy. Path I: the
software will be reliable.", Physics & Society, 16:2, April,
1987, p. 6.
Dahlke, K.: "SDI software, Part II: the software will not be
reliable.", Physics & Society, 16:2, April, 1987, p. 8.
Eastport Study Group: "A report to the director, Strategic
Defense Initiative Office.", December, 1985.
Eastport Study Group, "Summer Study 1985", Department of Defense
(SDIO).
Fletcher J.C. et al, "Report of the Study on Eliminating the
Threat Posed by Strategic Nuclear Missiles, Vol 5: Battle
Management, Communications and Data Processing" (Unclassified)
Department of Defense. Govet Printing Office, 1984.
Jacky, Jonathan: "The 'Star Wars' defense won't compute.", The
Atlantic, June, 1985.
Lin, Herbert, "Software and Star Wars: An Achilles Heel?"
Technology Review.
Lin, Herbert, _Arms and Artificial Intelligence: Applications of
Advanced Computing_, "Software and Systems in Strategic Defense",
book editor is Allan Din, publisher Oxford, January 1988.
Lin, Herbert: "Software for ballistic missile defense.", MIT
Center for International Studies, Report C/85-2, 1985.
Lin, Herbert, "The development of software for ballistic-missile
defense.", Scientific American, December, 1985, p. 46.
Myers, Ware, "Can Software for the Strategic Defense Initiative
ever be error free?" IEEE Computer, November 1986.
Myers, W., "The Star Wars Software Debate" Bulletin of the Atomic
Scientists, February 1986.
Nelson, Greg, and David Redell, "The Star Wars Computer System"
25 June 1985. (Available from CPSR)
Nelson, Greg and David Redell, "The Star Wars Computer System"
Abacus, Winter 1986.
Nelson, Greg and David Redell, "Could We Trust the SDI Software?"
Chapter 5 of "Empty Promise" by the Union of Concerned
Scientists, Beacon Press, 1986. ISBN 0-8070-0413-8.
Office of Technology Assessment, "Strategic Defenses" Princeton
University, Press 1986. ISBN 0-691-02252-6.
Ornstein, Severo M. "Loose Coupling : Does it Make the SDI
Software Trustworthy?" October 1986. (Available from CPSR)
Parnas, David L., "Why Communication Systems are Not Like SDI" 8
December 1985. (Available from CPSR)
Parnas, David L., "Software and SDI" 3 December 1985.
(Available from CPSR)
Parnas, David L., "Software Aspects of Strategic Defense"
American Scientist, Sept/Oct 1985. (Also published in CACM,
December 1985., and a Univ. of Victoria, Dept. of Computer
Science Report DCS-47-IR, July 1985).
Zracker, Charles A., "Strategic Defense: A Systems Perspective"
Daedalus, Spring 1985.
Zracket, Charles A., "Uncertainties in Building a Strategic
Defense", Science, 27 March 1987.
I am researching the history and progress of the Electronic Privacy Act. If you have an educated opinion on the law and wish to express it, please contact me via E-Mail. Thanks in advance, Eliot Lear
Please report problems with the web pages to the maintainer