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…
The following account is slightly edited from a story by Dennis Hevesi in the New York Times (Thursday, May 12, 1988, p. 12), with the headline CONNECTICUT SUSPENDS LOTTERY GAMES. I don't read the NYTimes every day, so I'm not sure what has happened since. On Sunday (May 8), the Connecticut State Lottery went on line with its new computer system. But yesterday, with the alarm sounded by two ticket sellers who knew they weren't entitled to $16,500, the entire system was shut down for 24 hours for repairs. The problems included the printing of tickets with the previous day's date, duplication of serial numbers, and malfunctions in the 1,853 computer terminals that have been installed so far. After 8 p.m. Monday, ticket sales are terminated. At 8:05, lottery officials announce on television the day's winning numbers. One pharmacy owner and one liquor store owner, friends who both sell lottery tickets played a Lotto number for Tuesday, May 10. But the sale was recorded as a Monday sale. They tried one of Monday's winning numbers, and it came out with a Monday, May 9 date. With a few plays, the total amount of their winnings was $16,500. They stopped. On Tuesday morning, they filled out the forms at the lottery office, and were given their checks for $6,750.30, after tax. They then said, "These tickets are a fraud." But officials kept saying the tickets were legitimate. Investigators were called. "I pointed out there's a big problem with the system. At first, they could not believe it. Then they treated us like criminals. Now they're apologizing like crazy. They did give us back the $6 we spent on the tickets." The big loser, it may turn out, could be General Instruments Corporation of Hunt Valley, Md., which was installing lottery terminals in the state under a five-year, $40-million contract. "We have a liquidated-damages clause in the contract, which basically says they replace our losses in case of system downtime," a lottery official said. "They're looking at big penalties. A week could be over $3 million."
> The risks I see here are philosophical ones to the academic community. There is a tremendous difference between putting protective "worms" in your own software, and putting in destructive worms or trojan horses. The developer is justified in protecting his software from unauthorized use. There is nothing unethical in using a security measure that only restricts use of the protected code or makes that software non-functional if misuse is detected. It is not reasonable to include code to inflict damage on an unauthorized user as retribution or revenge. The later is also poor business practice, as such code might destroy data belonging to a legitimate user. This will certainly hurt sales, and possibly subject the vendor to legal liability.
"boyle" posted an article in RISKS-6.81 indicating surprise that the Hinsdale
office did not have alternate trunking or redundancy.
The poster wanted comments from THE BELL SYSTEM.
As of Jan 1, 1984 the Bell System was abolished when the Justice Dept had AT&T
officially divest itself of the local operating companies. At that time, seven
NEW regional independent Bell holding companies began operating.
This was a RISK that was thrust upon the public. That risk being seven
independent local operating companies and many more long distance companies
working together to provide one cohesive telephone network with the same
objectives in mind as before divestiture - guaranteed phone service to the
public.
As to alternate trunking policy, AT&T generally contracts for more than one
access route into each LATA. I believe that BOTH of those were in the same Ill.
Bell cable vault that burned. Notice that AT&T (or any other long distance
company) has little control over what Ill Bell puts in its cable vaults.
I would hope that it is general policy that critical hubs in the local network
have alternate routes. But, with divestiture, this is now something that the
operating companies and the state utility commissions work out. The idea of
divestiture was to set rate structures such that one pays the TRUE cost of
providing each type of service. Could it be that alternate trunking is just
too expensive to provide the public? It is obvious that it was too expensive
for the subscribers in the western suburbs of Chicago!
To sum up, I think it is silly to ask a non-existent organization
("the Bell System") to comment on risks.
Mike Eastman ihnp4!ihuxz!mfe (312) 979-4111
AT&T Bell Laboratories Rm. 4C-321 Naperville, IL 60566
[Perhaps "boyle" was thinking of the "Virtual Bell System"? PGN]
Daniel Faigin writes: > ...in certain industries, such as nuclear ... all alarms are > treated as real emergencies until proved otherwise. My experience has been that, at any given time, there may be 20-100 alarms indicating in a nuclear power plant control room. New ones come in (on a good day) every few minutes. Realistically, they can't all be immediately treated as valid. 99% will eventually prove to be spurious or trivial. Alarms serve to focus attention on a *potential* problem. The reactor operator must judge the validity of each alarm and decide what response is appropriate. If no judgement was needed, the alarm input could as well be hardwired to produce the desired response. I suspect that similar conditions prevail in Bell's remote monitoring location. Fire alarms are notorious for spurious indication. Hot days, impaired ventilation, dust, etc. can erroneously activate various types of fire alarms. The maligned technician probably received several - maybe dozens - of false alarms per month from different monitored sites. He probably spent the infamous 10 minutes trying to confirm or deny the existence of a real problem (which would have been simpler had there been a human at the switching office). <Brad Dolan> sun!portal!cup.portal.com!bdolan@Sun.COM (Opinions expressed herein are my own... and I only understand about half of what I know!)
Another risk of automatic alarms is created by the inappropriate choice of technology. The VAX and Sun computers for my group at LLNL are located in two machine rooms. Each machine room is equipped with smoke detectors which are checked on a regular basis. The machine rooms are often unmanned. Two years ago someone in an office near one of the machine rooms reported smelling smoke. When several of us entered the machine room the smoke was so thick that we could not see the other side of the room; however, none of the smoke detectors had sounded an alarm. The smoke detectors "passed" subsequent tests, including cigarette smoke. We finally determined that the smoke came from an insulation fire in one of the air conditioners. The insulation smoke didn't ionize, rendering the detectors ineffective. (We replaced them with optically-based detectors.) I don't know who originally installed the smoke detectors, but after the initial incorrect decision was made we had no clue that part of our fire alarm system was useless. The testing procedure did not detect the unsuitability of this type of detector for our particular application. John Bruner (Supercomputer R&D, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!lll-crg!mordor!jdb (415) 422-0759
>From: Anita Gould <FONER.NITA%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU> >Subject: Halon environmental impact citation > >There are currently no good substitutes for halon, but according to SN, they >"are released far more frequently during tests than during fires." Of >course, failure to conduct tests has risks of its own! I'm sure they can be >minimized by designing equipment to be tested under dry run conditions. >Does anyone know if this is actually being done? Our latest system, installed in 1986, was initially tested using small tanks charged with Freon that were valve-compatible with the Halon tanks (although much smaller in volume). As best I can recall the system has *never* been tested with actual Halon, but this test does verify the operation of the actual valve assemblies. [Electronics and solenoids are Pyrotronics, release valves are Pyr-A-Lon]. The Freon tests are not much better on the ozone layer, but better than dumping the whole system (and much less expensive). The added security of the test is that equipment is left in the room during the dump to measure the Freon concentration, as a double check of your "dosage" and degree of airseal. I do not know of tests done with any inert or otherwise harmless gas. The reliability of the test could very well be affected (CO2 would generate a small snowstorm, temperature/pressure variance in the valves with other gases). Jeffrey R Kell, Dir Tech Services, Admin Computing, 117 Hunter Hall Univ of Tennessee at Chattanooga, Chattanooga, TN 37403 (615)-755-4551
There are reasons besides philosophic satisfaction and independence of
electricity (as mentioned by Mr. Brunow in RISKS Vol 6, Issue 88) to maintain
proficiency in celestial navigation. US Naval vessels have many redundant
sources of electricity, and are probably not immediately concerned with
navigation if all are gone. All the electronic methods of navigation require
external devices in predictable and accessible locations; defending these
usually delicate installations would be extremely difficult at best. (Inertial
systems require external input to prevent drifting off the correct dead
reckoning position) The stars, sun, moon, and planets are available under
nearly all conditions and can give accurate results easily and quickly with
moderate practice.
mike
Michael Fischbein msf@ames-nas.arpa ...!seismo!decuac!csmunix!icase!msf
These are my opinions and not necessarily official views of any organization.
Please report problems with the web pages to the maintainer