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…
Just a few comments. I'm on the Mars Observer project, and some of the information published in public sources has been somewhat misleading or incorrect. First, the spacecraft did not cost $1B, is was about $300M, the Titan booster was about $500M and ground systems and ops about $200M. In NASA's new way of doing business all costs are lumped together, so to make a fair comparison to other projects, you must understand that the costs quoted in the past did not cover the launch and sometimes not the ground system. Second, the communications with the spacecraft were not "disrupted" [actually David Perlman in the Chron said Pike noted that Mission Control engineers at JPL had ``lost contact with the Mars Observer'' --- PGN] as John Pike has said, nor "interrupted", they were intentionally turned-off. The transmitter beam voltage was shut down to protect the filament when the fuel and oxidizer pyro valves were blown to pressurize the tanks. The beam voltage was supposed to be turned back on after the tank pressurization event by the command sequence stored in the SCP, the spacecraft control processor. We do not konw what happened after the beam-off was executed because the downlink was not seen again, and that is all we know for sure. We have been commanding a series of events, presuming that certain scenarios have occurred. None has been successful as far as we know. We continue to send commands because the Command Detector Unit is connected to the Low Gain Antennas and do not require precise pointing by the spacecraft to achieve command reception. We do not know that whatever happened, happened when the pyro valves were fired because that did not occur until sometime after the beam voltage was turned off. There was a time interval to allow sufficient cooling of the filament. We are at this moment waiting for the expiration of the the secondary command loss timer, which will reconfigure the spacecraft telecom to 10bps and the Low Gain Antennas for downlink. That will occur (assuming that no commands have be accepted since last Friday) at 93/238-21:56:35 UTC, that is today, the 27th at 14:56:35 PDT. Lee F. Mellinger, Caltech/Jet Propulsion Laboratory - NASA, 4800 Oak Grove Dr. Pasadena, CA 91109 818/354-1163 leem@jpl-devvax.JPL.NASA.GOV
Unfortunately I can not provide the names of my sources for this material, as it would not be fair to them. Treat anonymous sources with appropriate skepticism; I think you'll find this an interesting tidbit nonetheless. Apparently the tank pressurization system on the Observer was tested exactly once, and it "blew up." Whether this phrase is meant to imply an explosion or merely a bad leak is an exercise left to the reader. NASA had one spare tank. Result: the Observer was launched with the second tank, with no further testing or development. /stern
The issue raised by David P. Reed is indeed sticky, and I agree with the moderator that the first step upon identifying a risk is to bring it to the attention of someone who can do something about it. In some cases that someone chooses, for whatever reason, to do nothing. In other cases, there *is* no someone. Smart answering machines are as good an example as I can think of. Publishing a "generic" warning doesn't give one (er, at least not *this* one) enough information to realize that DTMF tones can be recorded on the answering machine, then played back into the phone network. Somewhat reluctantly I find I have to disagree with Reed. Publishing specific details of RISKS does create the risk that someone will exploit those details. *However*, trying to express risks generically doesn't do much to keep bad guys from exploring and exploiting the RISKS. The bad guys will take time to think about the generic risks, searching for areas to exploit. The good guys (that's us) will probably *not* take time to ponder the generic risks, but we probably will respond to a report of a specific threat.
... discussed... Not only in RISKS! Consider the following essay, quoted
from Charles Tomlinson's Rudimentary Treatise on the Construction of Locks,
published about 150 years ago. (This quote has been bouncing around the net
for a while, but it bears repeating.) These issues have been hashed over for
a long time!
Doug Jones jones@cs.uiowa.edu
A commercial, and in some respects a social, doubt has been started
within the last year or two, whether or not it is right to discuss so
openly the security or insecurity of locks. Many well-meaning persons
suppose that the discussion respecting the means for baffling the
supposed safety of locks offers a premium for dishonesty, by showing
others how to be dishonest. This is a fallacy. Rogues are very keen
in their profession, and already know much more than we can teach them
respecting their several kinds of roguery. Rogues knew a good deal
about lockpicking long before locksmiths discussed it among themselves,
as they have lately done. If a lock — let it have been made in
whatever country, or by whatever maker — is not so inviolable as it
has hitherto been deemed to be, surely it is in the interest of
*honest* persons to know this fact, because the *dishonest* are
tolerably certain to be the first to apply the knowledge practically;
and the spread of knowledge is necessary to give fair play to those
who might suffer by ignorance. It cannot be too earnestly urged, that
an acquaintance with real facts will, in the end, be better for all
parties.
Some time ago, when the reading public was alarmed at being told how
London milk is adulterated, timid persons deprecated the exposure, on
the plea that it would give instructions in the art of adulterating milk;
a vain fear — milkmen knew all about it before, whether they practised
it or not; and the exposure only taught purchasers the necessity of a
little scrutiny and caution, leaving them to obey this necessity or not,
as they pleased.
... The unscrupulous have the command of much of this kind of knowledge
without our aid; and there is moral and commercial justice in placing
on their guard those who might possibly suffer therefrom. We employ
these stray expressions concerning adulteration, debasement, roguery,
and so forth, simply as a mode of illustrating a principle — the
advantage of publicity. In respect to lock-making, there can scarcely
be such a thing as dishonesty of intention: the inventor produces a lock
which he honestly thinks will possess such and such qualities; and he
declares his belief to the world. If others differ from him in opinion
concerning those qualities, it is open to them to say so; and the
discussion, truthfully conducted, must lead to public advantage: the
discussion stimulates curiosity, and curiosity stimulates invention.
Nothing but a partial and limited view of the question could lead to the
opinion that harm can result: if there be harm, it will be much more
than counterbalanced by good.
I'd like to comment on my experience with Citibank on this.
About a year ago, I called to confirm receipt of a new card. For
verification, the representative on the other end asked for my zip code
(which, if someone had intercepted this card in the mail, or found it in my
wallet, would be easily known), then for my mother's maiden name.
Trained by RISKS reading to look for security holes when giving out
personal information, I asked, "Do _you_ know my mother's maiden name?"
"No." (Imagine the implications if she'd said "Yes"!)
"So I could tell you anything, couldn't I?"
"Yes, but we'll use that next time you call as verification."
"But, if I weren't the person who was supposed to have this card, I
could tell you anything, and have the use of this card."
"Um, yes. Hmmm..."
To her credit, the rep seemed to understand the problem once it was
pointed out, and promised to bring it up "at the next meeting".
A few months ago, when I had to repeat the procedure, the rep asked
for my SSN (he was willing to accept a subset of the digits when I
expressed reluctance), then for the maiden name, which will be used for
future verification. (I suppose I should have asked if he already knew my
SSN or not...)
Of course, this means that my mother's father's last name has now
become information I have to regard as "confidential".
Citibank gives out an ATM PIN with it's cards. Why in the world they
don't use that as telephone authentication (after some intial check like
the SSN to confirm the right person got the card and the PIN), I have no
idea. Wouldn't it be easier to use information I already keep secure,
rather than ask me to keep other information - which, prior to this, I
might have given out with a thought - secure?
On a side note: preparing this post made me realize that, although I
haven't thought about it in years, keeping my Social Security card in my
wallet probably isn't the best of ideas.
Tom Swiss/tms@cs.umd.edu
>What does this mean in practice? You'll have to hire a management consultant
>to help you figure that out.
In the computer world we have been seeing this for some time: buy software
(really the documentation) once, and everything thereafter is electronic. One
of the first was "Using MS-DOS Kermit" from Digital Press. The software is
"free", however since the on-line documentation is now minimal (last full copy
I have is dated 1989), the book is a near necessity, only the updates come
with the software when you FTP it (ver 3.13 now). Of course we are now getting
to the point where you need to buy the second edition also to stay current
8*(.
Another example is the use by some manufacturers of "Flash ROMs", while this
is supposed to be an aid to updating, it looks more like an excuse for
slip-shod engineering (we had several from a well-known manufacturer who
shall remain nameless but is famous for selling high priced monitors as "15
inch" that have 13.8 inch (diagonal) viewing surfaces that would not
recognize a "three finger salute" until the ROM was updated...).
In the same token, Compuserve seems to be becoming the center for software
updates & "slipstreams" for problems that should never have occurred. (For
me, US Sprint & a Supra 14.4 modem (plugs) make direct connections to the
mfr - those that do not have FTP sites that is - cheaper than the Compuserve
hourly charges for anything interesting).
Once upon a time, software was difficult to update so manufacturers, those
that expected to stay in business, took pains to test software before
releasing it. DOS 3.3 lasted from 1987 to 1991 (admittedly partly because
DOS 4.x didn't work). Today the world seems to be one long beta test.
What we might expect in the future is "upgradable" hardware. Want to toast
bagels in your four-slice pop-up ? Dial 1-900-4NOBURN and connect to the
serial port. Your washing machine doesn't do the newest fabrics properly ?
1-900-NEWDUDS. Automotive recalls do not require stopping at the dealer,
just an ISDN connection. Latest & greatest or just an invitation to do
away with quality control ? You decide.
Padgett
Jeff writes; "At MIT I supervise the campus computer network, the MIT portion of the Internet. We have an internal policy that we do *not* monitor messages between individuals. We, however, state that our staff *may* inadvertently encounter personal mail due to our maintenance activities (more then likely because the mail system barfs and the message is delivered to the dead letter bin for manual routing)." In my own gateway implementation, I purposely suppress the body of messages that get reported to the administrator. Systems designers need not only refrain from invading privacy but proactively avoid inadvertent disclosures. Perhaps one should go so far as to simple scrambling of email messages stored on disk simply to avoid inadvertent display when looking at system logs or dumps. First Class mail tends to be sent in envelopes. Those who send post cards are accepting the risks of disclosure.
I've forwarded this by request of David Kovanen [kovanen@first.com]. Richard Jensen, Persistence Software, Inc., rjensen@persistence.com ----- Begin Included Message ----- Date: Wed, 25 Aug 1993 20:07:25 PDT From: uunet!First.Com!Kovanen (David Kovanen) To: wizard@moz.hookup.net Subject: 911 & Call Privacy *67 I recently ran into an embarrassing problem that was created by my local telephone company (US West.) The problem involved the new "Caller ID" feature and my local police @ 911. In anticipation of the introduction of Caller ID here in Washington state I began to insert *67 before all telephone numbers in my computer dialing directory. After all, I didn't want people calling me back on my data line. Everything worked fine up until February 1993. At that time US West began to install a new and "improved" version of the call blocking software. This "improved" version resulted in several calls from my computer to 911: Previously, a computer could dial *67 and immediately dial the desired telephone number without waiting for a second dialtone. (As can still be done with *70 to block Call Waiting.) The "improved" Central Office software now *REQUIRES* that the dialing device wait for a second dialtone and the C.O. ignores all dialed digits for approximately 1/2 second after the code has been dialed. There is no technical reason for this to be done, other than the fact that US West dislikes being forced by the Utilities Commission to offer Caller ID blocking. Here is the problem: I was calling a local telephone number, 572-5911 as follows: "ATDT*675725911". The four digits after the *67 (572-5) were suddenly ignored and the call promptly went to 911! It took several tries until I realized what happened. It is important to note that the operation of most of the central Office codes still do not insert this mandatory pause, including *67 prior to February 1993. There is one other problem with Call Vlocking that people with laptops should be aware of: *67 CAN NOT be dialed from a line that has blocking enabled for all calls. Thus, if you use your laptop on some lines with blocking and some without, you must keep two entries in your directory. This is a pain! It should be possible to dial *67 on a Blocked line to confirm that the call will be blocked. Incidentally, the problem with calls to 911 is equally true with any phone that has a redial feature: The redial feature will generally not store a pause after *67 and so the redial is effectively disabled (inoperable) for calls that you wish to block Caller ID on. This entire situation was brought to the attention of US West in March of 1993 and they responded that Caller ID would not be available until August 1993 so why was I complaining. It is now August and their response is: So don't use Call Blocking on your computer. As for my redial button: They say don't use it--buy their $3/Month "Continuous Redial". (Which incidentally is not like the PBX Automatic Callback feature--it only "looks" at a busy number about once every 45 seconds!) David J. Kovanen Kovanen@First.Com ... (206) 925-1000 10 Caledonia Summit NE, Browns Point, Washington, U.S.A. 98422-1620
Flight International, 24-31 August 1993, p5, `Report Challenges Gripen
Controls' by David Learmount.
Saab says that it was aware of the fly-by-wire (FBW) system software
inadequacy which caused the crash of its [..] Gripen [...] on 8th August [...].
The "software limitation" had been reported by one of the company's programme
test pilots, but was believed to be at a corner of the flight envelope
unlikely to be used. Saab says that the corrections [....were....] set for
October, but may be delayed.
The Swedish Accident Investigation Board's preliminary report says:
"The accident was caused by the flight-control system's high amplification of
stick commands in combination with large, rapid stick movements by the pilot.
This led to the stability margins being exceeded and the aircraft entering a
stall."
A contributory factor, says the report, was the "late display" of the
angle-of-attack warning, "...which gave the pilot too little time to react".
The report, based on flight-data-recorder information, says that
Saab test pilot Lars Radestrom had flown a left-hand turn at 154kt [..]
with 65 [degree] bank, at 2g, with a high 21 [degree] angle of attack.
Radestrom attempted to roll sharply out of the turn by applying
full-right aileron and, simultaneously, a sharp pitch down. Instead of
stopping at wings level, as intended, the aircraft continued to roll to 20
[degrees] right bank. The pilot reacted to the bank by a full control column
movement to the left, still with pitch down.
At this point, the software started to produce control over-reaction,
and the pilot started compensating with three of four more full-deflection
control-column cycles. Radestrom felt that he had lost control and ejected.
As the aircraft then entered a steep descent, it appeared to have
recovered to stable flight. "The aircraft's control system includes a recovery
mode. We have observed that this mode has operated in the intended manner,"
says Saab, while admitting that there was not enough height for recovery.
[End quote]
The last paragraph paragraph is particularly .... interesting. Maybe someone
should be collecting examples of airplane-industry double-speak. It seems to
surface when fly-by-wire systems are involved, or is it just my impression? I
don't recall anyone from Boeing saying "the safety bolts on ..... functioned
to specification" when El Al crashed into the apartment building in Amsterdam
last year, or someone from MD saying `the slat controls worked as intended'
when China Airlines killed 2 people and injured the rest with an inadvertent
slat deployment on an MD11 at cruise over the Aleutians earlier this year.
Peter Ladkin
Please report problems with the web pages to the maintainer