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…
In the Dutch newspaper "De Volkskrant" of Tuesday january 12 and
Wednesday january 13 1988, two articles appeared on a computer fraud
that was discovered by ... an error of that same computer.
An employee of a bank in Amsterdam (name of the bank not mentioned)
transferred $15.1 million to a Swiss account, using the computer. To
make an international money transfer, two persons must give
permission. Each of them has a secret password. The employee knew
the password of one of his collegue's, and had a password himself,
and thus could make the money transfer on his own.
On december 24, the employee tranferred $8.4 million and
$6.7 million to a bank in Zurich. Due to a technical malfunctioning,
the transfer of $6.7 million failed. After Christmas, other
employees saw on their terminalscreen that the transfer had failed,
got suspicious, and reported to their superiors.
According to the Volkskrant, many banks use the same system, and
this method of fraud "occurs presumably more often, although the
banks are very quiet about this". The employee is arrested.
This makes me wonder about fail-safe computers: a fail-safe computer would
have failed to save the bank from THIS fraud :-)
Frans Heeman, frans@cs.vu.nl
In Risks 6.8, Steve Cisler wrote
> This means that no one ... can get a profile of your reading habits
> from checking old records. There are just not any--except overdue items ...
This comes up from time to time, but it's worth pointing out again. Don't
forget to think about (and talk about) the backup system. This system,
designed explicitly for the re-creation of old data in certain, failure
situations, can be (mis)used to recreate the data in other situations unless
the backup system is designed with data protection and selective erasure in
mind.
Michael
[The old Contragate so-you-thought-you'd-deleted-it problem... PGN]
I've encountered a marvelous Heisenbug (a bug whose behavior changes when
you look for it) involving TOPS Spool and MultiFinder. Yesterday, I
installed MultiFinder on one of the Mac SE systems here at work. After
rebooting, I found that TOPS Spool worked fine when the system was booted in
Finder mode, but behaved erratically when the system was booted in
MultiFinder mode. The primary symptom I saw was that TOPS Spool would spool
the file to disk, but would not print it. The status display would
indicated "Waiting; source: AppleTalk", and the printer's yellow status
light would double-blink (indicating that the printer was waiting for data
to be sent over AppleTalk). This wouldn't always occur, and didn't always
occur at the same point in a file. I tried spooling one file several times,
and the copies seemed to exhibit different behavior.
Finally, I noticed one critical clue: if I had turned "Print while I work"
off, and then opened the TOPS Spool d/a and turned it back on, the spooler
would not begin transmitting the file until I closed the desk accessory.
Printing would then begin, and would continue to work properly until I opened
the desk accessory again... at which point the current print job would hang!
So... hmmm... using the TOPS Spool desk accessory under MultiFinder causes the
background printing task to stop working, but using exactly the same desk
accessory, System, drivers, etc. works just fine if the system is booted under
the Finder. What's the difference? Well, under MultiFinder, desk accessories
are normally opened by a mini-application called DA Handler, so that they won't
go away if you "Quit" from your current application. I tried opening TOPS
Spool while holding down the Option key, which forces the desk accessory to run
in the current application's context... and, lo and behold, background printing
kept working! Apparently, the TOPS Spool desk accessory interferes with the
background-printing task if it's run under DA Handler, but not if it's run
under the current application (Finder, in my case).
So... this is really a reverse Heisenbug, of sorts... the software works unless
you look to see whether it's working, at which point it stops working!
Dave Platt
UUCP: ...!{ames,sun,uunet}!coherent!dplatt
Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net
[For those of you who weren't in on the original flurry of Heisenbugs,
see RISKS-4.30 through 36, and a few subsequent issues. PGN]
I got many responses to my question. Here are some relevant excerpts:
From: olling@tcgould.tn.cornell.edu (Cliff Olling)
I caught 2 or 3 episodes of it quite by accident about 6 months to
1 yr ago. It was showing on one of the PBS stations on our cable
here in Ithaca. I think the PBS stations are in Scranton, PA, and
Binghamton & Syracuse, NY.
As for the content, I found it interesting from the theatrical as
well as the technical sense. The consultant didn't seem to be blatantly
"bat", and I don't remember actually took any money. He seemed more
like an adult version of the typical teenage hacker stereotype. The
technical parts (actually typing on terminals, using modems, etc.),
actually seemed fairly realistic. There were no whirling tape drives
or modems going Beep-Boop-Beep-Boop a'la War Games. All in all, very
little suspension of disbelief was required.
From: davy@intrepid.ecn.purdue.edu (Dave Curry)
"The Consultant" BBC television series was aired on the Arts &
Entertainment Network (a cable channel) on Monday evenings about two
years ago. If I remember right, they broke it into five or six episodes
instead of four, each was an hour long.
The series wasn't too bad... they actually used "computer words", and
didn't do anything silly like make the terminal beep for each character
it printed, etc. Some stuff was simplified for the general public, but
overall I found it an enjoyable series.
The A&E Network tends to re-air most of their more popular shows every
year or two.
From: watrous@aramis.rutgers.edu (Don Watrous)
I've seen it play on A&E (cable) a couple of times within the last
year or two. ... I remember the characters and the premise, but
don't recall being very impressed.
From: Lee Barford <barford%hplabsb@hplabs.HP.COM>
The Arts & Entertainment Network played it twice, about 18 months
ago and again about a year ago.
[Some of this covered by comments from Brian Kantor, Scott C Crumpton,
Dave Curry, Dwight D McKay, Alan Wexelblat, ... PGN]
Not having anything better to do last New Year's evening, it seemed like
a good opportunity to synchronize our computer clocks with reality. So,
as the leap second approached, my finger was poised on the RETURN key.
Poof, the New Year arrived and the clock was back in sync. Ten minutes
later, the computer was half an hour into '88. Hmmm, didn't look right.
For the next couple of hours, I was chasing the system clock the way a
cat stalks its evasive prey.
A day or so later, the first reports appeared of other people having the
same problem (by this time I was used to frequent timewarps on the system).
The problem turned out to be caused by a classical programming error:
Macro arguments with side effects are Bad Style.
The problem was in the clock maintenance software in the kernel, where
a C macro defined as:
#define MONTHSEC(mon, yr) \
(((((yr) % 4) == 0) && ((mon) == 2))? 29*SECDAY : monthsec[(mon) - 1])
was called using:
... MONTHSEC(--mon, year);
instead of:
--mon;
... MONTHSEC(mon, year);
The code was written after the previous leap year, and the double-evaluation
of the first argument would not occur until another leap year. Some knee-jerk
analysis of the problem wrongly blamed the leap second (what with all the
publicity). Since most clocks and software don't know about leap seconds,
this was not plausible.
Considering the 40000-odd (my estimate) computers that were affected by
this problem, many many people were thinking of the careless programmer
with warm, sizzling, thoughts. It didn't reflect well on the employer/vendor
either, both in letting this problem slip by them, and in letting an apparent
novice write such a critical section of code. I realize my criticism may
be harsh, but it is coloured by the severity of the problem, having
experienced it, and knowing the cause.
On a vaguely related matter, the latest issue of The Economist (9-15 Jan 88)
has an article titled "Something Rotten in the State of Software". It is
a 3-page overview of computer bugs, what causes them, and what to do about it.
Several Risks issues, and people (Neuman, Parnas, Leveson), are mentioned.
Never trust computers.
rayan
Please report problems with the web pages to the maintainer