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…
From The Boston Globe, Saturday, November 4:
FAA suspects birds jammed radar
Kansas City, MO - A several-hour shutdown of radar systems in three midwestern cities may have been caused by unseasonably large flocks of migrating birds, aviation officials said yesterday. No disruptions or delays to air traffic were caused by the failures Thursday in Omaha, Des Moines and Kansas City, MO, which shifted to back-up radar coverage, said an FAA spokeswoman, Sandra Campbell. The Federal Aviation Administration is investigating the shutdown but officials say they suspect migrating birds were responsible. "There's been an extremely rare and large hatch of migratory birds this year, especially waterfowl," Campbell said. "That is suspected as the problem but we don't know for sure." Radar systems identify and track airborne targets but some are susceptible to shutting down if they track a maximum of 700 targets at a given time, Campbell said. Immediately before the system in Omaha shut down, it had identified more than 29,000 targets, she said. "Not all of those were migratory birds, but we also didn't have 29,000 airplanes in the sky at that time," Campbell said.
[What may have confused the radar was that too many of the birds had the
same squawk. - ACG]
[Also reported by Philip R. Moyer <prm@rome.isl.sri.com>. PGN][At the Software Engineering Institute's Software Risks conference in Monterey earlier this week (I was the keynote speaker), someone asked me whether the "illustrative risks" summary list of one-liners that I maintain (and which will appear in the January 1996 Software Engineering Notes) and indeed those in the Risks Forum are really representative. Yes, I do tend to suppress some of the many similar cases such as the n+1st instance of "ATC system failed, cutover to backup succeeded." I also suppress some of the more repetitive and less interesting cases, but sometimes decide that we really do continually need to be reminded of the fact that similar cases just do manage to recur, continually — such as another case of air-traffic controller spoofings, as in the next message, and another case of RF interference, as in the message following that. Sorry if it seems repetitious, but there is a lesson therein. PGN]
I've just seen a report about a 'hacker' who is sending false radio messages to plane. It was reported on the local teletext news. "Pilots have been ordered to double check air traffic control messages to beat bogus transmissions. Transport Secretary George Young said the hacker is thought to be using a hand-held, battery-operated transmitter on sale for #600 ($900). The hacker has given out false information to aircraft about to land at Manchester airport." The risks are obvious, but some I would think some form of scrambling by using digital signals would help prevent this type of thing. Apparently the police in Manchester are supposed to be switching to a digital system to stop criminals with scanners from listening in on them.
Neil Harding[We have had a bunch of similar incidents in past RISKS issues, but not recently. PGN]
This occurred a few weeks back, so my memory is a little fuzzy on the _exact_ details. Uncertainty is noted below.
Melbourne Air Traffic control received complaints from pilots coming in to land that one [or more] of their comms channels was picking up interference to the point that it/they were unusable (I'm now not sure whether this was voice comms or guidance signals).
The interference was sporadic.
Investigators ran around the place with trackers, but their task was hindered by the intermittent nature of the jamming. It appeared to be originating (roughly) under a flight path. An initial conclusion was that someone had a rogue transmitter and was deliberately jamming the band(s) for a short while, and then going quiet to avoid anyone pinpointing their location. A flurry of news items on various media highlighting that the prankster's deeds were a serious threat to life had no effect on the jamming.
It literally took weeks for tracker vans to finally home in on a suburban house one evening. The startled man was duly impressed with all the technical equipment parked outside his door.
He claimed innocence.
The investigators did their search of the premises and eventually found the transmitter.
It was a Video Cassette Recorder (VCR).
I kid you not.
Under certain conditions (pressing certain buttons in a particular sequence), the unit transmitted an RF signal which was sufficient to interfere with Air Traffic Comms. The house was under an approach to Melbourne Airport. The Airport authorities offered to replace the unit. They reported that the man was most co-operative and indeed, amused by the whole incident.
The authorities didn't release the VCR's brand name or model. Hopefully, they've effected a silent recall of all such units.
[My Comments follow — pnm]
Three things spring to mind:
NEWS DIGEST, 1 November 1995. Reuter.
REUTER - Japanese and Taiwanese relatives of almost half the 264 people killed in the 1994 crash of a Taiwanese Airbus filed a suit with a court in Japan on Wednesday seeking 25.7 billion yen in damages. It was the biggest single damages suit in
connection with an air crash in Japan. Relatives of 121 victims — 92 Japanese and 29 Taiwanese — of the crash at Nagoya
airport in central Japan filed the suit at the Nagoya District Court, a court spokesman said. They demand that China Airlines and Airbus Industrie pay 100 million yen in damages for each victim, plus compensation for their lost earnings.
The following is an excerpt from a news posting to demon.service . It was followed by an invitation to change your password if you are worried, and lots of good advice about how to choose a new one.
Demon Internet is a leading ISP in the UK. All credit to them for owning up to this possible security risk.
In this particular case, I think most of the trust has to be in the password encryption, rather than the Radius database. I understand that Demon only store one-way encrypted passwords.
In article <9511011146.AA19161@jes.demon.co.uk>, Jim Segrave <jes@jes.demon.co.uk> writes
>
>On Tuesday evening, 31 October, one of the three Radius servers
>appears to have corrupted its pointer to the message of the day
>text. The result of this was that users logging in saw a dump of a
>section of the Radius database rather than the message of the day. The
>Radius database includes encrypted copies of user passwords. It is not
>possible to determine which portions of the database may have been
>made visible by this fault. I am currently looking at the Radius
>server code to try to determine the cause of this problem and to add
>safeguards so that it does not recur.
The German federal labour court has ruled that employers may monitor their employees telephone conversations, but only if the internal telephone system of the company has built-in eavesdropping capabilities
I had to read that report twice.
Apparently, the court's point was that if the telephone system had built-in eavesdropping, the eavesdropping itself does not constitute a violation of the German criminal law, because the laws requires the use of an "eavesdropping device" for the eavesdropping to be a criminal offence. (Obviously, this restriction is there because you wouldn't punish people who listen to others peoples conversations, say, at the bus stop).
(cynical remark) This may be a good point for the makers of telephone systems: if you want to sell your system in Germany, please build in eavesdropping capabilities and remind your customers of this court ruling.
There are two risks here. 1: outdated laws that do not always match the problems arising with today's technology. 2: the "self-fulfilling-prophecy" characteristics of built-in features of technology. In other words: you never asked anybody to include eavesdropping in your telephone system. But once it's there, you will use it at some point. And if you're in Germany, you're even allowed to.
(I know that this is no news to US residents, as employers there may eavesdrop you as they choose. Still, this is not the case everywhere in the rest of the world.)
References:
Par. 201 Abs.1 Punkt 1 Strafgesetzbuch (German Criminal Law)
S|ddeutsche Zeitung, 4. Nov 95
Bundesarbeitsgericht, AZ 1 ABR 4/95 (Reference code of the court ruling)
The Dallas Morning News carried the following on November 1, according to the in-house network news at AT&T:
o The federal government and the phone industry — anticipating big problems with new area codes — are launching a nationwide advertising campaign [today] to educate businesses and consumers about the changes. The No. 1 warning? If you work at a business with a private switchboard, known as a PBX, you may not be able to place a call to any of the new area codes unless you go through an outside operator. That's because the new codes, unlike the existing ones, don't have a zero or a one in the middle. Private switchboards don't recognize these new codes. [Dallas Morning News]
This sounds dismayingly like the year-2000 calendar bite we have been reading and writing about for a long time.
Years ago, when the convention of dialing a '1' before the area code was first introduced, it was clearly stated that one reason for this was to make the area code recognizable without relying on the middle digit. Or is my memory faulty? How could the pbx suppliers have failed in all these years to prepare for the "new area codes"?
The Federal Bureau of Investigation wants Congressional approval for a plan that would increase its wiretapping about 2,000% from current capabilities, giving it the ability to monitor as many as 1 in every 100 phone lines in certain high-crime areas. In contrast, fewer than 1 in 174,000 phone lines received court-authorized taps in recent years. The FBI says the plan is "absolutely essential for law enforcement and public safety." (*The New York Times* 2 Nov 1995, p. A1) [A subsequent correction in the Times noted that it was really ONLY 1 in 1000. PGN]
In RISKS-17.43 Klaus Brunnstein takes on Bill Gates over the realities of commercial software development. Engineering is about knowing the risks accurately, as Bill Gates clearly does.
Microsoft engineers products to optimize very considerable development costs for the uses to which the product will actually be put. You can't fly a 747 through a hurricane, and Microsoft Word will not do everything for everybody. Microsoft is constantly improving their designs and engineering, often in response to user feedback. But Microsoft does not ship a product out the door until they know it is viable.
The 777 is not a bug-fix release of the 747. The 747 does its job well enough and many of its petty annoyances will never be fixed. The same is true of Microsoft Word. On the rare occasion when a serious design flaw is discovered, it is fixed. It is true that software becomes obsolete much more quickly then a jet, but fortunately it is priced so that people can keep up to date. Sometimes that means buying a bigger hangar and adding a runway. If you don't need to lower your costs or up your carrying capacity, by all means stay with the older technology.
The risk is in thinking that an evolving computer system of any size will ever be free of risk. Engineering is about understanding the limitations of a system and how that understanding is itself limited. This is where Klaus may pose a risk to himself. Perhaps he should take up Mr. Gates on his offer to listen in on support calls.
Alonzo Gariepy alonzo@aa.netIn RISKS-17.43, Klaus Brunnstein relayed a Bill Gates interview at German weekly magazine FOCUS where, when asked "There are always bugs in programs", Gates was quoted as saying: "No. There are no essential bugs ("keine bedeutenden Fehler") in our software which a significant number fo users might wish to be removed."
This reminds me of the book, Writing Solid Code (MS Press), which is hailed as the classic on the MS way of programming. In its lecture number 2 (or was it 3), the author gave an example to copy memory. The essence is as follows (I put it in an easier to read language):
if (allocate_memory(some_length) != NULL)
then copy_memory to new place
The author then says that, although this code captures the bug when memory allocation fails (when it returns a NULL pointer), the code to check the pointer not being NULL doubles the code size and slows things down. His advice? Define the "extra" checking only when you are debugging, and then remove iy from the "slick" code you ship.
Li GONG <gong@csl.sri.com> 1-415-859-3232 http://www.csl.sri.com/~gong/Following my report on Mr. Gates` interview in FOCUS (RISKS-17.42), some colleagues assumed that my translation might have adversely change Mr. Gates` original words, or the German interviewer may have misunderstood some phrases. The interviewer, Dr. Juergen Scriba <scriba@focus.burda.com> was born in USA and grew up there, so his English qualification should be good. The interview was in English, translated and "redactionally adapted" in German (e.g. to remove redundancies and polish sentences, as is usually done in such interviews). Finally, the German version was authorised by a German employee of Microsoft.
Dr. Scriba was so kind to read my "translation back to English". Though some of my phrases differed from Mr. Gates original speak (due to "polishing"), he regarded my text as semantically essentially correct, with one exception: I mistranslated "Maschinenstuermer" as "machine addict" but the correct translation is "Luddite". Apologies for this serious fault :-)
Dr. Scriba sent me "original Mr. Gates", so I append this "raw text". In comparing the published interview with the spoken one, I regard the journalist having been really friendly with Bill :-)
Enjoy Mr. Gates` original speak. Klaus Brunnstein (November 4,1995)
----- Original interview text of Mr. Bill Gates before translation and adaptation; German (not this English) version was authorized -------
FOCUS: Every new release of a software which has less bugs than the older one is also more complex and has more features...
Gates: No, only if that is what'll sell!
FOCUS: But...
Gates: Only if that is what'll sell! We've never done a piece of software unless we thought it would sell. That's why everything we do in software ... it's really amazing: We do it because we think that's what customers want. That's why we do what we
do.
FOCUS: But on the other hand - you would say: Okay, folks, if you don't like these new features, stay with the old version, and keep the bugs?
Gates: No! We have lots and lots of competitors. The new version - it's not there to fix bugs. That's not the reason we come up with a new version.
FOCUS: But there are bugs an any version which people would really like to have fixed.
Gates: No! There are no significant bugs in our released software that any significant number of users want fixed.
FOCUS: Oh, my God. I always get mad at my computer if MS Word swallows the page numbers of a document which I printed a couple of times with page numbers. If I complain to anybody they say "Well, upgrade from version 5.11 to 6.0".
Gates: No! If you really think there's a bug you should report a bug. Maybe that you're not using it properly. Have you ever considered that?
FOCUS: Yeah, I did...
Gates: It turns out Luddites don't know how to use software properly, so you should look into that. - The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard. When we do
a new version we put in lots of new things that people are asking for. And so, in no sense, is stability a reason to move to a new version. It's never a reason.
FOCUS: How come I keep being told by computer vendors "Well, we know about this bug, wait till the next version is there, it'll be fixed"? I hear this all the time. How come? If you're telling me there are no significant bugs in software and there is
no reason to do a new version?
Gates: No. I'm saying: We don't do a new version to fix bugs. We don't. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say "Would you buy a new version because of bugs?" You won't get a single person
to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis.
FOCUS: Probably you have other contacts to your software developers. But if Mister Anybody, like me, calls up a store or a support line and says, "Hey listen, there's a bug" ... 90 percent of the time I get the answer "Oh, well, yeah, that's not too bad, wait to the next version and it'll be fixed". That's how the system works.
Gates: Guess how much we spend on phone calls every year.
FOCUS: Hm, a couple of million dollars?
Gates: 500 million dollars a year. We take every one of these phone calls and classify them. That's the input we use to do the next version. So it's like the worlds biggest feedback loop. People call in - we decide what to do on it. Do you want to know what percentage of those phonecalls relates to bugs in the software? Less than one percent.
FOCUS: So people call in to say "Hey listen, I would love to have this and that feature"?
Gates: Actually, that's about five percent. Most of them call to get advice on how to do a certain thing with the software. That's the primary thing. We could have you sit and listen to these phone calls. There are millions and millions of them. It really
isn't statistically significant. Sit in and listen to Win 95 calls, sit in and listen to Word calls, and wait, just wait for weeks and weeks for someone to call in and say "Oh, I found a bug in this thing". ...
FOCUS: So where does this comon feeling of frustration come from that unites all the PC users? Everybody experiences it every day that these things simply don't work like they should.
Gates: Because it's cool. It's like, "Yeah, been there done that - oh, yeah, I know that bug." - I can understand that phenomenon sociologically, not technically.
Original text with kind permission of Interviewer: Dr. Juergen Scriba (FOCUS)
------------------------ end of raw interview ---------------------------
But even if the system can be made to work perfectly, there are risks from outside of the system. For example, what if the last two cars going through the yellow lights collide right in front of the bus? The bus drive could be staring at a green light for a minute and still not be able to clear the tracks.
I'm surprised there hasn't been more commentary in the media about a fail-safe mechanism — never have traffic stopped on rail tracks, regardless of how the lights and switches are connected. In fact, I thought most states had laws requiring buses to come to a complete stop before at-grade rail crossings, look both ways, and only proceed if they can completely clear the tracks before having to stop for something else.
-Michael J. ZehrIn the interests of accuracy;
The reactors on a submarine cannot undergo a nuclear explosion. (Nuclear explosion, (yield), assumes that the bulk of the energy comes from fission reactions.)
A melt down with an associated steam explosion is possible. A steam explosion or leak leading to a meltdown is possible. But not a nuclear detonation. (The exact progression of the accident is difficult to predict without much more knowledge of the configuration of the system.)
This is not to say that a steam explosion and/or meltdown and the associated side effects are not dangerous in and of themselves.
>or (with Columbia University's "CU See Me") to videoconference over a 14kb
The Risk? Name your software product poorly, and someone will misattribute it. Since 17.43 has come out without this being pointed out, I think that Craig will find, if he checks the credits on CU-SeeMe, that Cornell, not Columbia, is the "C" in CU-SeeMe.
Below is an extract from the abstract at the info-mac hyperarchive at MIT:
Subject: CU-SeeMe070b1.sit.hqx - Video Conferencing Software CU-SeeMe - Video Teleconferencing for the Mac, from Cornell University!
-Lawrence H Smith, Academic Computing Specialist for the SciencesThere is an existing technical solution to this problem. Autoresponders are supposed to
Of course, this solution only works if autoresponders adopt this convention.
Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh[Noted by MANY OTHERS. PGN]
According to recent mail on the gnu-win32 mailing list, the latest release of the GNU BFD (Binary File Descriptor) package for Windows NT was missing the file `core.c'.
I shudder to think how this happened, but since this Windows NT release was cross-compiled from a machine running Linux, I suspect it may have something to do with the fact that recent versions of Linux put some additional information in the core files names, so that core files are now named `core.*'.
Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh[Lots of other comments on this topic too. TNX. PGN]
Please report problems with the web pages to the maintainer