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 email@example.com
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