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…
According to the AP, a ``Traffic Alert and Collision Avoidance System'',
designed to prevent mid-air collisions, apparently malfunctioned and nearly
caused one. Two planes, a 767 and a DC-9, were separated by 1,000 feet of
altitude, in accordance with FAA regulations. But the TACAS system told the
pilot of the 767 to descend to the DC-9's altitude. The horizontal separation
of the planes was only .5 miles, rather than the 5 miles required.
--Steve Bellovin
TOPEX/POSEIDON STATUS REPORT
August 28, 1992
The TOPEX spacecraft went into safemode at 18:13Z on August 27. The
project reports that during a planned maneuver that they received a "roll
momentum wheel saturated" alarm causing the spacecraft to go into safemode and
causing the project to abort the maneuver after 98% completion. The project
has elected to remain with TDRS support for the time being. The project has
not declared a spacecraft emergency. The cause of the safemode is currently
under investigation.
Forwarded from: PUBLIC INFORMATION OFFICE, JET PROPULSION LABORATORY,
CALIFORNIA INSTITUTE OF TECHNOLOGY, NATIONAL AERONAUTICS AND SPACE
ADMINISTRATION, PASADENA, CALIF. 91109. (818) 354-5011
TOPEX/POSEIDON STATUS REPORT
August 28, 1992
The TOPEX/Poseidon satellite entered into safe hold
mode on Aug. 27, 1992 at approximately 11:13 a.m. PDT. This
incident occurred during the inclination maneuver about 6 seconds
from the end of the propulsion burn.
The inclination maneuver was successful and placed the
satellite in the proper 66 degree inclination toward the Earth.
Project managers have determined that the safe hold
mode was the result of a "bug" in the software code which set the
failure detection correction limit for a roll angle of 3 degrees,
not 7 degrees as intended. This was a result of residual LANDSAT
code which did not correlate to the program design language.
All satellite hardware is functioning properly based on
detailed review of the maneuver playback data. Reconfiguration
of the satellite back to the standard configuration prior to safe
hold mode is in process at this time and is expected to be
completed tonight.
The solar array was offset to -55 degrees at 12:45 p.m.
PDT today prior to the start of occultation. This was done so as
to not overcharge the batteries when the Sun hits the solar array
after coming from eclipse.
Since the inclination maneuver goals were achieved, the
flight team is proceeding with the nominal maneuver campaign.
There are four more maneuvers to go. In-Plane Maneuver One is
planned for Wednesday, Sept. 2, 1992.
The NASA radar altimeter was turned off when the
satellite entered the safe hold mode. It will be turned back on
about 6:30 p.m. PDT tonight. Initial data from the NASA
altimeter prior to the incident looked very good.
HUBBLE STATUS REPORT
August 31, 1992
HUBBLE SPACE TELESCOPE (HST): HST operations have returned to normal following
the recent safehold entry and recovery. Starting on July 30, a chain of events
caused HST first to enter an inertial hold safemode followed by a hardware
sunpoint safemode. The first was caused by an incorrect ephemeris table that
was loaded into the spacecraft computer, and the latter by a problem with an
onboard computer software macro. Science observations that were scheduled for
execution during the safemode events are being rescheduled. HST launched April
24, 1990 aboard the Space Shuttle Discovery.
Ron Baalke, Jet Propulsion Lab, M/S 525-3684 Telos, Pasadena, CA 91109
baalke@kelvin.jpl.nasa.gov
From the Asbury Park Press, August 30, 1992:
A malfunction in the computer that opens and closes the Route 37 bridge
rendered the span impassable for an hour yesterday afternoon, backing up
traffic for miles in each direction.
Dover police Sgt. Vincent Pedalino said officers were forced to reroute
traffic north to the Mantoloking Bridge on Route 528 while state Department
of Transportation workers found a way to repair the computer.
The bridge was closed between 2:30 and 3:30 p.m., stranding many motorists on
the bridge in the hot afternoon sun.
Pedalino said the drawbridge structure itself — which opens upward to allow
water traffic through in Barnegat Bay — was unimpaired, but the automobile
barriers wouldn't reopen. Normally there are manual controls that override
the computer system, but they also were not working, he said.
The bridge is a long span from the Toms River area to the barrier resort
of Seaside Heights and the popular Island Beach. The Mantoloking Bridge
is the nearest other exit from the barrier peninsula, about 10 kilometers
north.
The story does not tell what was wrong with the computer or the manual
controls. I wonder whether those "manual" controls would work during a power
failure!
Col. G. L. Sicherman, gls@windmill.ATT.COM
An article by O. Casey Corr, The Seattle Times Knight-Ridder/Tribune Business News, 20 Aug 1992, describes the case of Mel Creamer, coordinator of a software system for mainframe computers used in Olympia, Washington, by the Department of Social and Health Services. He was doing a routine check of the system's performance when the following message showed up: "THAT DEVICE DOES NOT EXIST ON STATION DEFINED." A keystroke-capture watch was set up. It then was determined that this message had been triggered by a temporary clerk-typist trying to print something locally using the access code of another user normally in a different area, and the system could not interpret the command. He was trying to print the file of personal sign-on codes, and had created new accounts and access codes, and had erased audit trails to remove evidence of the activities. He clearly had all the necessary access codes. The computers contained software for issuing checks and ordering state services, personnel records for the department's 16,000 employees, arrest warrants for parking tickets kept for the Department of Licensing, and private information on individuals and countless companies that did business with the state. A computer linked to the one breached by the intruder maintains the state's budget records. Malicious misuse of those systems could be quite damaging. Timothy M. Lewis was charged by King County for computer trespass in the first degree, a felony, along with three other people, for misuse dating back to 1987. The victims, in addition to the state, included Aldus of Seattle, Asymetrix of Bellevue, and Phonelink Inc. of Bellevue (now Fox Communications). (This is reportedly something like the 14th such case involving adults since 1988.) Eugene Raddatz, a data security analyst with DSHS, recalled two previous cases in the 1980s when state employees got into the computer system and stole money by having checks written to themselves. Both people received prison terms, he said.
For more than a decade I've been a customer of a money-market fund that shall remain nameless here. For all that time, they've sent me a statement monthly. Early on, they returned canceled checks with each statement; some years back they started batching the checks, returning them only twice a year, to save on postage. In recent months, they've started sending me a statement every time there's activity in my account: every time a check clears, or I make a deposit. In my case, that means a minimum of three statements per month, at 27 cents postage each. So I called up, endured their voicemail system and a five-minute hold, and asked the customer-service person what's going on. It seems they've just "enhanced" (her term) their computer system, and one of its "features" now is that it kicks out a statement every time there's activity, whether you want one or not. I pointed out that this is costing ten times what they're saving by batching canceled checks, but there's nothing to be done: that's how the computer works, and it can't be changed ...
An AP story in today's paper (21 Aug 1992) date-lined San Francisco states that
Federal prosecutors sought court orders yesterday to force three local
businesses to turn over their customer lists, sales receipts and shipping
records for indoor "Growing lights" since the start of 1990. They also want
copies of any correspondence mentioning marijuana.
The three companies--Diamond Lights, General Hydroponics, and Berkeley Indoor
Garden Center--refused to turn over the documents without a court order and are
now fighting the court order on the grounds that the request was too broad and
would violate customer privacy.
>From their names I'd guess these businesses sell lots of "grow-lamps"; the
RISK is that with the increasing use of sales-registers that record customer
identification along with each sale how long until the government starts
investigating people who innocently buy a few of these lamps from the local
K-mart, or any other item that might just possibly be used in some sort of
illegal activity?
-Dan Veditz
There's a known problem with the BSR X-10 home automation system whereby the
"appliance modules" can spontaneously turn themselves on. This happens with
certain types of loads, particularly electronic loads such as computers and
compact fluorescent lights, and it is due to a misfeature called "local on".
(The X-10 is a carrier current appliance control system widely marketed under
other names, including Radio Shack, Heath and Stanley. The "appliance modules"
are relay boxes that plug into the wall between the AC line and a load to be
controlled.)
The "local-on" feature is intended to allow a user to turn on an appliance
locally, without having to go to the control box. If the appliance is a lamp,
you just flick its regular switch on and off several times, and the appliance
module turns on.
This feature apparently works by trickling a small amount of current through
the load whenever the appliance module relay is 'off' and watching for sudden
voltage swings across the load that would indicate that the user is cycling the
power switch. It works great for simple resistive loads like incandescent
lamps, but nonlinear electronic loads (especially those that directly rectify
and filter the AC power line) will often draw almost no current until some
voltage is reached across the load's internal filter capacitor. Then the load
conducts, discharging the capacitor and causing the input voltage to drop
suddenly. A few cycles of this "relaxation oscillator" simulates a user
flicking a switch well enough to trigger the appliance module's "local on"
feature.
The problem usually occurs right after you switch the load off — several
seconds later, it comes back on again. But it's possible that the spurious
turn-on could occur much later. This problem drove me crazy until I realized
from the description of "local on" in the manual what was going on. There was
no specific warning about this possibility. Indeed, the manuals take great
pains to point out that "lamp modules" (which contain dimmers) are not to be
used with flourescent lamps and electronic loads; appliance modules should be
used instead. The instructions do warn about controlling appliances that could
cause damage if they were turned on inadvertently (e.g., an empty coffee pot)
but this doesn't really address the issue.
It turns out that cutting an undocumented jumper inside the appliance module
defeats the "local on" misfeature. It's obvious that someone anticipated this
problem since the jumper wasn't essential in the PC board layout, so it's
doubly annoying that there is no mention of this problem or its solution in the
manual.
Phil
Please report problems with the web pages to the maintainer