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…
Excerpts from "The Sacramento Bee", Friday, October 4, 1991. The RISKS are
more than obvious. (Didn't something similar already happen in Great Britain?)
It is not explained how they found out about the alterations. Probably
followed a paper trail, or discrepencies in backup logs. If that is so, what
about all these pen-point computers about to hit the cop market? Will this
increase the risk of losing this kind of "evidence"?
Ex-DMV worker admits altering driving records for money
A former technician for the [California] Department of Motor Vehicles admitted
in court Thursday that she deleted bad driving records of a number of
individuals who had paid for the service. Genevieve Pamela Lopez, pleaded
guilty to 10 counts of illegally using the DMV computer for the purpose of
altering, damaging or destroying data. Nineteen additional counts were
dismissed. Proceedings against her co-defendant, Donald H. Stables, were
continued to Oct. 24. He is charged with 48 counts involving computer fraud,
bribery, falsification of government documents and conspiracy.
According to court records, Stables, an insurance agent in Yreka, allegedly had
been receiving fees of up to $2500 to arrange the obliteration of accident
reports, drunken-driving arrests, suspensions and other violations on his
clients' DMV records. Lopez was his contact at the department, according to
documents, and she received between $400 and $500 for each transaction. ...
[The plea bargain terms Lopez has arranged are six years of formal probation,
60 days in the county jail, a fine of $10,000, and to testify against Stables
if need be.]
The managers at NASA/JSC (Johnson Space Center, Houston, TX) seem to be underestimating the RISKS associated with migrating a mature software product to a completely new environment. There is a move afoot to migrate the SMS (Shuttle Mission Simulator) from the Unisys 1100/90 - Perkin Elmer 8/16 equipment it's currently running on to another platform (not completely defined yet). The reasons for doing the migration sound something like "we need to get off that old mainframe equipment and into the modern age of Unix, multiple workstations, etc. Or maybe an modern (IBM) mainframe." The justification for going through the effort (and believe me, it's going to be monumental) is improved uptime due to improved hardware and software reliability, ease in implementing changes, and performance (the 1100 it's on doesn't have a high MIP rating, and we all know how truly useful MIPs are to compare dissimilar hardware/software). Upgrading the current equipment and/or software environment is not currently being considered seriously (Unisys isn't POPULAR with the big wigs at JSC, IBM & Unix anything are). Problem one: the numbers being used to do the justification seem to be largely imaginary (I'm not close enough to the project to tell for sure). Sort of ... "Everyone knows that mainframes are unreliable and workstations are good. Rate the mainframe 10 failures per ?? (based on real data) and rate the workstation system 3 per ?? (based on who knows?). This will save us big $$$." Even if the numbers are based in something resembling a scientific study, they are likely to be based on MATURE systems. Anyone who has been through a major conversion effort can tell you just how long it takes to get millions of lines of real-time simulation software to the same maturity on another box, especially a very different kind of box (the Shuttle may be retired by then). At the time SMS was developed (more than 12 years ago), Univac (later Sperry, later Unisys) was the only vendor that had developed real time software processing to a sufficient maturity on a large enough box to get the job done (I believe they were the only ones to complete the pilot project successfully, but I wasn't around then). Since then, the software has undergone extensive growth. This system is complicated to the point that moving it to another platform will be practically as difficult as redeveloping it from scratch. Problem two: none of the destination systems being discussed have demonstrated that kind of real-time software processing capability. Problem three: none (or almost none) of the programmers currently working on SMS has any experience with any of the new systems. There is a gigantic risk in going from the known into the unknown. This risk is unjustifiable when significant improvements can be made in the current environment. Unisys 1100-series equipment, from the smallest (2200/100, desk sized small business system) to the largest (2200/600, big mainframe), runs the same software across the entire line with NO modifications required. Such a large range of compatible processing power is unavailable from any other vendor (the Unisys A-series has a somewhat wider range). Since the initial development of SMS, the capabilities of both the hardware and system software of the 1100-series has expanded tremendously. Upgrading SMS to take advantage of these improvements would be much less risky than moving to another platform, but the lack of popularity of Unisys at JSC prevents it. (Another of those political correctness things. Also a result of the government contractor environment. "We hired you to do what we tell you to do and nothing else.") And all this at public expense without much accountability. NOTE: I have been doing System Software support on 1100-series computers for about 10 years and can't claim to be entirely unbiased. I have done programming on both personal computers (Apple, Commodore, IBM, etc.) and mainframes (Honeywell, Unisys 1100/2200, some IBM), so I have an idea what it takes to move conventional systems from one box/environment to another. I don't think the management at NASA does.
[The risks entailed in the attached article, quoted in full from the front page of today's Independent, are perhaps not so much computer-related as commission-related, but I thought I would "share them" (to use an American phrase which always grates somewhat on British ears :-) with RISKS readers. Brian Randell, Computing Laboratory, The University, Newcastle upon Tyne, NE1 7RU, UK PHONE = +44 91 222 7923 FAX = +44 91 222 8232] European Ideal Embraces Harmonised Pornography, by Andrew Marshall, West Europe Editor The European Community has a new crusade: high technology pornography. EC commissioner Filipo Maria Pandolfi told the European Parliament in a letter yesterday that the Commission is working on a code of conduct for the sex industry. Mr Pandolfi is the Telecommunications Commissioner, and does not usually get involved with below-the-waist activities in a professional capacity. But the modern pornographer is increasingly dependent on modems and multiplexes [sic] rather than plain brown envelopes and hand-wound peepshow machines. And when Brussels hears the word "hi-tech", it reaches for a directive. "Such a Code of conduct would state ... rules for the information industry ... and administer the provision of information services of a pornographic nature," says Mr Pandolfi's letter. The pornography industry, as well as simple telephone chat lines and recorded messages, has now developed much more complicated ways of sending pornographic images along the line. Regulating these is something of a problem for old-fashioned vice cops. But when different individual member states develop different approaches, this can interfere with more legitimate business activities. So part of Mr Pandolfi's mission is to ensure that Nation shall speak dirty unto Nation, because, as the Commission puts it, "discrepancies between existing national regulations constitute a problem in establishing a common market for information services". Let nobody keep apart heavy breathers in Croydon and Cologne, lest they disrupt the single internal market. Perhaps the commission is not aware of the risks in opening Pandolfi's box. Will pornography have to be standardised, with French maid's uniforms compulsory? Will there be heavily-subsidised industrial national champions in pornography, allowing the Dirty Old Man to represent Euro-frotteurs? Must Naughty Fifi Tell All in eight languages?
This notice appeared in the University of Washington staff newspaper University Week: PHONE FRAUD It recently was discovered that inmates from the Clallam Correctional Center in Clallam Bay, WA have been using an automated phone system to try to scam unsuspecting employees at the UW. Fone America, the long-distance provider for the correctional center, supplies anautomated service for collect calls. Inmates are supposed to make recordings of their names to identify themselves to the called parties. A recording should say, "If you will accept a collect call from...(name of caller)...please press the number 3 on your telephone twice" Fone America also supplies the same automates message in Spanish. In the scam, inmates chose the Spanish option and record, in place of their names "If you want to hear this message in English, press 33." They then call a number at the UW an try to reach employees who will press 33 which automatically accepts the collect calls. If the inmates get through, they ask to be transferred to the outside operator or to the switchboard operator. They will then attempt tp place long distance calls and have them billed to campus phones. Since late July, this scam has occourred a number of times. It is important for University employees to recognize this or similar phone scams. [The notice goes on to suggest ways to minimize the impact of phone fraud] Jim Flanagan, Systems Programmer, UofW Statistics flanagan@stat.washington.edu
Yes, indeed, the described "peace patent" is similar in some respects to the
basic concept behind the semi-classic film "Colossus: The Forbin Project"
(1970). In the film, both the US and USSR put into place master control
computers to manage their nuclear arsenals. Gimmick: the systems cannot be
turned off or disconnected (similar to 'The Doomsday Machine' from "Dr.
Strangelove") without blowing everything up.
The US computer (Colossus) realizes that there must be a Soviet computer
(Guardian) and demands a hookup (TCP/IP? OSI?). Classic line: "There is
another system."
Both sides let their computers talk for awhile. There's an amusing sequence
where the two systems, starting with 0 and 1, build up a vocabulary and rapidly
increase the data rate. The humans watching have an increasingly difficult
time keeping track of what the machines are saying to each other as the rate
increases. Suddenly, the machines shift to a completely unknown protocol and
coding, and the humans have no idea what is going on between the machines.
They panic, and pull the plug on the connection. Colossus (we see all this
from the US side) tries for a while to get a circuit back to Guardian over
various cable and satellite systems. He can't. He then simply demands that
the circuit be restored, or else he'll fire a missile. In fact, as I recall he
does just that, as does Guardian. The warheads are only destroyed (how?) when
the humans restore the link.
There are a lot more goings on, including various other attempts to disconnect
the computers or disarm the warheads. All fail. The film ends with Colossus
and Guardian in total control of the world, and humans relegated to a position
of being, essentially, slaves to the machines.
--Lauren--
UC Santa Cruz is going to install a touch-tone registration system. Here's
your chance to prevent a RISK before it occurs.
Please send me any RISKS that you know of in such a system. Also, pointers
to relevant back-issues of RISKS will be appreciated.
Thanks, DL
[Responses to DL, PLEASE!!! PGN]
Kent Mitchell <KDM@rational.com> indicates that a bug in his company's products
has been corrected and that it is no longer a problem. He then goes on to say,
"Perhaps the real risk here is using old, out of date software." Others might
say, "Perhaps the real risk here is prematurely released software, software
that is released before adequate validation". How long can we go on acting as
if it is OK to release buggy software as long as we fix it (for an extra charge
of course) later.
David L. Parnas parnas@sscvax.cis.mcmaster.ca
>The U.S. finds itself in a dilemma: harm our economic growth and competitiveness in the expanding world internet products and services industries if we prohibit cryptographic applications, or permit such cryptographic export and potentially weaken military security by providing new encryption capabilities to our adversaries. I have heard this argument multiple times and I find it bogus. This argument assumes that we in the US are in a leadership position in the development of encryption products so that if we ship products, our adversaries will get something they can't get elsewhere. It's doubtful that this has ever been true, except possibly for the top of the line NSA black boxes — but that's not what we're talking about controlling, here. We're talking about the products of US private industries. Crypto AG in Switzerland isn't waiting for the US to permit exports. They have been producing high quality equipment for decades and will continue to do so. Other companies are starting up to produce and sell cryptographic equipment. Therefore, to me there is only one side to this argument: if we prohibit export, we limit the US competitiveness, while our adversaries get equipment and algorithms at least as good as they might buy indirectly from us, but from other countries. Meanwhile, the thwarting of US industrial development of cryptographic applications and equipment leads to an atrophy of ability in US industries so that even we will have to buy equipment from outside this country. The last time I looked at smart card cryptography, it was all produced in Europe, for example. Is this going to be another case of the USA losing out completely on a market -- ala VCRs? My guess is that it already is — thanks to at least a decade of restrictions. My remaining question is whether we have any chance to catch up, assuming we do a rapid and firm about-face in policy immediately.
> It turns out that a fiber optic in an environment "where the temperature
can suddenly increase" can result in the complete destruction of a fiber
optic in what is known as a fiber "fuse" effect. "For certain types of
optical fibers...damage can occur when the visible-light laser power
transmitted... is as low as 4 milliwatts..."
I'm surprised that a power of 4mW can destroy a fibre. Ten years ago, I was a
practising spectroscopist. Several times I saw a fibre melting away in an
upstream direction. The output end of the fibre had become dirty and absorbed
the laser light; the fibre's tip melted, ensuring that light continued to be
absorbed.
The big difference, though, was that we were pumping anything up to 10 WATTS
through a 150 micron fibre. Admittedly, this was 514.5nm Ar+ light, rather
than the red and near IR used in telecommunications, but as glass is more
opaque in the green than near IR, I'd expect greater problems with Ar+. I
*never* saw a fibre burning away when less than several watts were being
transmitted.
If we calculate the power densities involved, 10 watts through 150\mu is a
power density of 566MW m-2; 4mW through the same fibre is 226kW m-2. For
comparison purposes, a typical electric fire element (in this country at least)
radiates 1kW from an area of 0.01 m-2 (assuming a length of 30cm and a diameter
of 1cm) for a power density of 100kW m-2. It glows dull red-orange.
Hmm, I suppose that 200kW m-2 might melt a fibre if the laser light were
converted to heat with high efficiency.
Paul
> The USAF/NASA Advanced Fighter Technology Integration test aircraft is doing flight evaluations of a system to help pilots cope with disorientation: push a button on the stick and the computer automatically brings the aircraft back to level flight. But level flight based on what indications? Every IFR pilot is taught to "right" herself based on the array of gauges visible on the panel, and must do so with demonstrable proficiency before being signed off to "bore holes in the clouds". But we are also taught to cross-check... does the Artificial Horizon "make sense" compared to the changes in Altimeter and Heading? Does the Rate-of-turn indicator cross-check with that? I can't see how this device is better than your basically-trained IFR pilot, and it may be worse (mortal failures under strange instrument failure modes). Randal L. Schwartz, PP-ASEL-IA, 260+ hours and climbing...
`` It is an (at least) antisocial act to cause anything to run
on my machine without my knowledge, and with no action on my part
to indicate that I want it. I cannot think of ANY useful piece of
software of ANY sort [...] which does not have the potential for
screwing things up amazingly in SOME contexts.''
Although I see no reason to disagree in principle, it may be worth pointing out
that this statement, taken literally, is too strong to reflect the reality of
even the most common computer systems, which DO execute things without explicit
actions from their owners and users.
Most people reading this use a machine running Unix. Somewhere in its file
system (usually /usr/spool/cron or /var/spool/cron) there is a directory
`crontabs' containing files which describe actions to be executed regularly
without explicit user action. In particular, the file `root' describes actions
to be executed by the `root' id, that is to say, with all possible privileges.
Such mechanisms, if used well, are essential to the proper functioning of the
system. For example some typical `cron' actions remove unneeded or old files.
For one thing, news wouldn't work without cron, since the flow of incoming
messages would quickly fill out all available disk space. Neither would mail
work without the help of some programs, running automatically (the Unix name,
``daemon'', is suggestive enough), which do a few things on their own, such as
checking the incoming mail queue every now and then.
One may argue that there is implicit ``action on the owner's part'', using Mr.
Smee's words: by accepting to use the machine, you accept its standard cron
mechanisms and mail daemons; furthermore, you may login as `root' and disable
the daemons and cron actions that you don't like.
But most people probably just leave the software as it was when the machine was
installed, and as Unix reaches the masses there will be more and more users who
don't even know about the existence of cron and daemons. So in effect the
operating system IS performing, behind the user's back, actions which may
directly affect his property (files, electronic mail etc.).
It's a little like signing an agreement letting a supplier or employer make
direct drafts from your bank account: sure, you did perform one ``explicit
action'' when you authorized it, but it still opens more risks than if you have
to authorize each operation individually.
So while I agree with Mr. Smee and other posters about the oxymoronic nature of
``friendly virus'', I think the technical situation is a little more complex
than his statement would suggest.
It also seems that an automatic or semi-automatic bug correction service,
working somewhat in the style of mail and news (that is to say, updating remote
files in controlled conditions) wouldn't be such an absurdity as he suggests. I
can see why some user sites might want to subscribe (voluntarily, of course!)
to such a service if it is technically well-done and has the proper safeguards.
(Maybe something like that already exists.) After all, those of us who can read
this still use mail and news in spite of the Internet worm and of the potential
for further abuses of the same kind.
Bertrand Meyer bertrand@eiffel.com
Some people seem to want to blame human weaknesses for the AT&T failure, other
people seem to want to blame the technology. What I havan't seen anyone point
out is that, every time AT&T (or most other people) does something to "improve"
their system, they end up more and more centralized.
Fundamental rule of designing things:
"Sooner or later, EVERYTHING breaks."
If you don't what catastrophic failures, you need to arrange things so that the
inevitable failures aren't catastrophic. Why is so much vital traffic being
routed through a single installation? What are they planning to to when a
fire, plane crash, flood, or terrorist action takes out that entire building?
Why is the control network dependant solely on AT&T, when anyone with any sense
could predict that sooner or later, that service isn't going to be there?
P.Rose (LCO114@URIACC.URI.EDU)
Several persons commented that the cause of the accident was not that the
signs were not working, but rather that the truck driver was not paying
attention. The inattentiveness of the driver may have been the most
significant factor, but the failure of the signs is also significant. The
driver may have had an expectation that the warning signs were operating. Lack
of the warning contributes to lower attentiveness.
This phenomenon has a name — primary/backup inversion. The driver should
have been more attentive, but warning systems do tend to make people less
attentive. Designers must keep this in mind when developing warning and backup
systems.
This accident clearly falls in the category of a "system accident" --
multiple factors in a complex system (including surface traffic, river traffic,
drawbridges, warning systems, rules of operation, working hours) collectively
contributed to the outcome. Charles Perrow's _Normal Accidents_ discusses
system accidents in detail. It is well worth reading.
Steve Philipson
>The was no risk here because the signs weren't working. The risk was the truck
driver obviously driving recklessly. There's too much of a tendency to blame
something or someone else when things happen. Bottom line is, if the trucker
had been driving safely, the accident WOULD NOT HAVE HAPPENED, sign or no sign.
Unless you have additional information about the accident, I must disagree. If
I am on an unfamiliar highway, it is up to the maintainers of the highway to
"tell" me how to drive it safely. This includes speed limits, warnings about
hazards, and information about what is ahead.
There is a section of a Rt 9 in Mass. that has a stop light just over the top
of a hill. You can't see it as you come up the hill, but only as you come over
the top. The speed limit on this road is 45mph, far too fast to react to one
or more stopped cars at a red light. The town put up a permanent sign clearly
stating that there was a stop light over the hill and that cars may be stopped
at it. This warning has worked very well.
However, several miles down the road, in a different town, they use an electronic
sign that only turns on when the light is RED. The idea being that if the light is
green and there are no cars backed up, there is no danger, so no need to slow down.
Assuming that the sign goes on and off correctly, ( including time delays after
cycling to allow a backup to disperse ) this will work fine. But as soon as the
electronic board fails, THERE IS NO WARNING. A driver not knowing the road would
go 45mph, ( the posted "safe" speed ) having no reason to think that there is any
problems ahead, and smash into the cars backed up at the red light. A driver who
knows the road would assume that the sign would warn him if there was a backup,
so he too would be in danger. ( I'll grant you that this driver should be going
a little slower over the hill because he knows that there is a potential problem )
If all drivers drove as if they had to be able to stop on a dime at all times,
cars could not be a pratical form of transportation. Drivers rely upon the
maintainers of the highways to tell them what the risk level of the road they
driving is, so that they can then drive "safely".
The Wizard of AHs
P.S. Some places use a permanent painted sign that warns of the danger all the
time, and the electronic lighted sign obscures it when it is on. Therefore, in
the case of failure, the warning is up. Sort of like four way stop signs at an
intersection with lights.
My uncle, who was a law lecturer at Cambridge, England, was telling me about
liability risks. He said that sometimes if you put up a warning sign, then you
are admitting that there is a hazzard, and so you are liable. However, if you
say nothing, then you are not liable. Interesting cases.
Richard Thomsen
Certainly, there are risks associated with the expectation that any warning
devices will really function. But I have to lay blame for this accident on the
truck driver. Whether or not the signs were operating with appropriate
messages, the driver of any vehicle is responsible for operating it in a
"reasonably safe" manner. This includes being able to stop the vehicle if there
is an obstruction in the road.
In this case, either the truck driver was not paying attention or he was
driving too fast so that he couldn't stop when he did see the stopped traffic.
There are many possible causes for an obstruction in the road that have nothing
to do with the drawbridge. The warning signs would not have given notice of
these.
Robert Haar, Computer Science Dept., G.M. Research Laboratories
While it would not have helped any on the recent ATT outage, a serious problem
is trying to use people to backup machines--they get bored and nod off.
Perhaps we need to have on purpose, unpredictable "false alarms" for people to
respond to. I could eaisly design such a device to give a false warning at the
sensor leads once a month or so. You could make pay, or rewards, or something
dependent on taking corrective action, starting with reseting the signal. You
might want an short term inhibit signal so that test alarms wouldn't pop up
during a real emergency. Let's see, I have a year from this going out to file
for a patent. :) Keith Henson
[Well, this idea keeps coming up in RISKS, every time we
have a problem with backup and emergency systems... PGN]
Please report problems with the web pages to the maintainer