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…
An article in The New York Times, 14 Aug 1995, by Lawrence M. Fisher (Software Bug in Motorola Cell Phone Prompts Worldwide Recall) describes a software bug in one model of Motorola's cellular phone. Apparently Israelis tend to keep their cell phones on all the time, because service is only 3 cents a minute. This resulted in a bug manifesting itself that had not previously been a problem. Motorola's Alpha digital phone was introduced in December, and sporadic problems were reported in Hong Kong in February. By April, 65,000 Alphas had been distributed in Israel by Cellcom. Alphas were being blamed for sound quality that made voices inaudible, a lack of reception in areas where reception was promised, cutting off calls, and long periods when the phones simply did not work. The biggest problem seems to have been that the digital TDMA (time division multiple access) phones would lock onto one frequency during the periodic registration, rather than switching; this resulted in blocking all other users in the local cell. Motorola wound up recalling 150,000 Alphas in six countries, to change the software (a job estimated by Motorola as costing between $10 million and $20 million.
I just heard on the radio this morning that the Royal Australian Navy has prohibited the use of Windows 95, citing security concerns to do with its uploading of possible sensitive information.
Dave Horsfall (VK2KFU) | dave@esi.com.au | VK2KFU @ VK2DAA.NSW.AUS.OCOn Saturday, 12 Aug 1995, lighting knocked out both the main power and the backup for almost 1.5 hours at the Miami-area ATC radar center that tracks 400,000 square miles of air space over Florida, the Atlantic, and the Gulf of Mexico (ok, RISKS readers, that is a radius of about 357 square miles, assuming a circular area). ``Travelers were never in danger, said an FAA spokesman.'' [Source: San Francisco Chronicle, 14 Aug 1995, p. A3.]
> Why did the planners building the air-traffic control
> center not think a constant supply of power would be important?
They did. According to the brief CNN story I saw, there were two backup power supplies. However, one was down for repairs, and the other didn't come online automatically like it should have. When this was realized, engineers had to start it manually, and this took time.
Barry Margolin BBN PlaNET Corporation, Cambridge, MA barmar@bbnplanet.comMy guess is that the airspace controlled by Oakland Center was correctly reported to be 18 million square miles. The Center is responsible for controlling traffic over most of the Pacific. Its airspace includes Guam, goes almost as far south as Fiji, and further north, more than 2/3 of the way west from California to Japan. Dres
A recent post from Ross Anderson via Lance Hoffman and David Farber contained the following:
>... says that the OECD countries will hold a meeting on National
>Cryptography Policies later this year. While at the conference, I found
>out that a classified meeting took place this March in Germany between
>the signals intelligence agencies of the developed countries, plus
>Australia and South Africa, at which the assembled spooks agreed to
>press their governments to bring in escrow and/or weak crypto.
I think that it should be noted that these policies are not "national" in any real sense of that word. They are not the result of national dialogue. They are not positions taken by the elected government. Rather they are the unchallenged policies of the bureaucracy. These so-called policies are the positions of the princes, not to say spooks. They ignore the interests of the merchants and the bankers, let alone the citizen. It may already be too late for elected officials to reassert their authority over the bureaucracy but we do not yet have to consent to having the language distorted against us.
While I am defending the language, the use of the term "escrow" in this context is intended to sugar coat something that is nothing like escrow. Historically, escrow has been used to talk about a fiduciary with equal responsibilities to both parties. That is very different from these proposals where the duty of the agent is to act in the interest of one party without so much as notice to the other.
William Hugh Murray New Canaan, ConnecticutHere's a little test for your readership, sort of like a word search. It's a risk search. How many risks can they find in the letter below? This letter was sent to Northwest Airlines on August 11.
Should I have done anything differently? Should Northwest?
Dan Frankowski dfrankow@winternet.com http://www.winternet.com/~dfrankow- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dan Frankowski
ADDRESS DELETED
WorldPerks numbers XXX-XXX-XXX and YYY-YYY-YYY
John Dasburg
Northwest Airlines
5101 Northwest Drive
Saint Paul, MN 55111
Dear Mr. Dasburg:
The purpose of this letter is to request
Since 1987, I had a WorldPerks account (#XXX-XXX-XXX). Because I used the account infrequently (once or twice a year), I did not keep written correspondence from Northwest. Thinking back, I had not received an account statement for at least 18 months.
On July 16, 1995, I flew to Chicago on Northwest. I presented my WorldPerks card (#XXX-XXX-XXX), and was asked to confirm an address in Milwaukee, Wisconsin. I have never been to Milwaukee; I could not confirm the address. The Northwest employee told me to call customer service when I had time.
I called customer service within a week. They told me that without written correspondence from Northwest, I had no option but to open a new account with zero miles on it. I was repeatedly told that XXX-XXX-XXX was not my account, since it had weekly flights from Milwaukee since 1988. I agreed that the flights listed were not mine, but maintained that the account was. The only proof I have is my dark blue WorldPerks card with red lettering (photocopy enclosed). The customer service representative said that the color is important, as it indicates when the card was issued.
I felt accused and shabbily treated by customer service. It would have been simple to call me back after someone knowledgeable in customer records had investigated my case. Instead, I was treated as the wrongdoer, repeatedly told the account was not mine, and given the "only option" of opening a new account. I opened a new account #YYY-YYY-YYY.
Accompanying the overwhelmingly rapid expansion in the use of information services, companies must develop responsible problem-resolution capabilities. It's good business. Demonstrate your good business capabilities by satisfying my requests in the first paragraph of this letter.
Your customer,
Dan Frankowski
P.S. I am also sending this to the Usenet newsgroup comp.risks, which has international readership, as an example of the risks of computing. I will keep them updated with your replies.
In RISKS-17.24, Paul Green suggests that more customers should, when confronted with a failure by a company they patronize, insist not only on a fix to the failure, but also on an explanation of the root cause of the failure and of how it will be prevented in the future. Perhaps he has had better experience than I with this approach, but every time I've tried it, I've been blown off. I'll give a recent example, which I confess is not directly related to computer risks, but which I believe illustrates my point in a useful way. I am not "changing names to protect the innocent," because Dell is *not* innocent and has, in my opinion, earned through its actions a public condemnation of its cluelessness.
In November of last year, I purchased a Pentium PC (model XPS P90) from Dell. I began to follow discussions in alt.sys.pc-clone.dell, and shortly after my PC arrived, I saw a posting from someone asking what the story was with the BIOS upgrade for XPS P90 systems. A Dell representative posted a response saying that the current BIOS version was A05 and that update disks had been mailed, via U.S. Mail, to all registered XPS P90 owners.
I checked, and lo and behold, my system was running BIOS version A04, despite the fact that Dell had shipped it to me *after* they released A05. I never received an update disk from Dell.
I engaged in a lengthy E-mail conversation with Dell's on-line technical support department, in which I pointed out that (a) I should not have been shipped a system with an obsolete BIOS on it, and (b) I should have received an update disk if my system had an obsolete BIOS, I was a registered owner, and disks really were mailed to all registered owners. I asked for specific explanations of why both of these failures occurred, and what was being done to fix them, so that at the very least I would not miss out on any future mailings from Dell that I was supposed to receive.
Despite repeated requests, the people with whom I corresponded never even tried to address point (a) above. As for point (b), they continued to insist for quite a while that everyone had been mailed update disks, and when pushed on the issue, they claimed that either my address must have been wrong in one of their databases, or the U.S. Postal Service must have lost some of the disks that were sent out.
I pointed out to them that in either of those cases, there was something wrong that they needed to investigate. If my address was wrong, then they needed to find out how it got to be wrong and fix it, because I gave them the correct address when I ordered the system and it hadn't changed since then (and I'd received other mailings from Dell with no problem). If the Postal Service lost some of their mail, then they had a serious bone to pick with the Postal Service, and they should demand an investigation and compensation from the Postal Service.
Using Occam's Razor, it seems far more likely that rather than any of their excuses being correct, what really occurred is simply that the switch from A04 to A05 in manufacturing and the mailing out of update disks to registered owners were not properly synchronized, so some people received new systems with the obsolete BIOS after the mailing out of disks to registered owners had already occurred, or even that they made an error when mailing out the disks and some registered owners were not included in the mailing.
At no time during this stream of correspondence did the people at Dell show any comprehension of why I considered it important to find the cause of the problem, rather than just to solve its symptoms. Several times, they told me that I could download the BIOS update program from their BBS, FTP server or WWW server, even though I told them several times that I'd already *done* that, and that I was trying to get *past* that to find and fix the root cause of their failure to ship me a current BIOS.
In the end, I sent a paper letter to the manager of Dell's support department, relating in it this entire story and suggesting that perhaps he might want to consider training his employees in simple TQM concepts such as the one I was trying to get across to them. I got a response a few weeks later, informing me that my letter had been received and was being acted on, and that I would subsequently received a more substantive response to my complaints. I never received such a response, and that's where things stand to this day.
The treatment I received from Dell is not, in my experience, an isolated experience. Almost invariably, when I suggest to someone that I have a right to know the root cause of a failure, and that finding and providing me with that root cause will *help* them serve customers better in the future, I am met with stone-faced resistance of the "Stop telling me how to do my job" variety. I do not blame only the employees with whom I have dealt with for this. When a company encourages its employees to handle customer complaints *quickly* (as in, "This call may be monitored to ensure that our employee gets you off the telephone in the shortest amount of time possible, so that they can handle more calls per day, so that we don't have to hire more support people."), as opposed to encouraging them to handle complaints *well*, taking initiative to ensure that similar problems do not occur in the future, employees have little choice but to buckle under. When speed is rewarded at the expense of everything else, quality suffers.
TQM isn't the grail of quality customer support. It has a lot of aspects that I find silly; I'm certainly not a TQM junkie like some managers (and companies) I've seen. Nevertheless, it has some good ideas, and one of the best is encouraging all employees to treat the root causes of problems rather than the symptoms. Alas, I don't know how we can get that message out effectively.
Jonathan Kamens (whose XPS P90 is now en route from the United States to Israel and over three weeks overdue, thus forcing him to use his wife's PowerBook instead, due to another customer service horror story that's too long to include here)BKTRBCMP.RVW 950605
%A Thomas K. Landauer
%C 55 Hayward Street, Cambridge, MA 02142-1399
%D 1995
%G 0-262-12186-7
%I The MIT Press
%O U$27.50 curtin@mit.edu
%P 425
%T "The Trouble with Computers"
"The Trouble with Computers", Thomas K. Landauer, 1995, 0-262-12186-7, U$27.50
Oh yes, we got Trouble! Right here in Silicon Valley! With a capital "T" and that rhymes with "P" And that stands for Design! (Poor Design!)
Landauer has compiled an impressive collection of studies and statistics to show that computers are not contributing to productivity as they ought. Liberally sprinkled with computer horror stories occurring to his friends, family, and self, both anecdotes and academics point out what readers of the RISKS-FORUM Digest know already--we are using computers the wrong way.
Over and over again, we see instances of bad design. Devices and interfaces that are unusable. Mission-critical tasks entrusted to insufficiently reliable machines. Whole systems viewed only from the output end. About halfway through the book, the statement is made that computers are marvelous toys: this is quite true. The trouble is that the majority of computer owners are demanding more frills on their toys, drowning out the faint cries of those who need more design in their tools.
Landauer's solution is UCD, an acronym that stands for three variations on "user-centred design". This sounds a lot like human factors engineering or, as we highly technical types refer to it, doing a good job.
Anyone involved in the implementation or support of technology knows that bad designs abound, and that more care should be taken to improve usability. This work does not offer significant help in that direction.
copyright ©Robert M. Slade, 1995 BKTRBCMP.RVW 950605
Vancouver Institute for Research into User Security Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca Rob.Slade@f733.n153.z1.fidonet.orgWith regard to the article by Maxion and Goldberg in RISKS-17.22 about about the problems with humans interfacing with computers, I have a comment that is highly unorthodox but which might provide a pathway into the problem.
Traditional methods (adapted and extended by object-oriented methodologies) are based on breaking the system into a series of objects, and then modelling the messages between objects. Conventional languages such as C (etc.) are used to implement the system as modelled.
My belief is that the inheritance of procedural languages based on FORTRAN or ALGOL is that in choosing to define programming as a series of formulas, they have also chosen to implement a simplified algebra where the operations are limited to nouns and verbs, without much support for adjectives and adverbs. The result is that simple but powerful parts of thought have to be broken down before they can be expressed in a program. A simple example is a program to select all the "leaf" nodes of a tree: to implement this simple, powerful, parallel operation typically involves breaking "leaf" into the test "is_leaf" and then checking each node in a loop.
Adjectives and adverbs are common in systems, but not at the level of languages like C: they are found in the command line switches to programs which modify the behaviour of the program or the set of objects processed by the program.
I believe that the freedom to express adjectives in a graphical fashion is one of the reasons why windowing systems have become more popular than command-line systems. Modifiers such as shift-clicking also provide a convenient way of expressing adverbs.
My personal goal (which is still a long way off, sigh) is to design and implement a language where adjectives and adverbs join nouns and verbs as primitives when presenting an interface to clients. The process of constructing a solution to a problem then becomes a process of building a language in which the solution can be expressed. Each module that contributes to the environment also provides an implementation of the facilities it offers.
The major reason for having this sophistication in the interface is that it allows the separation between modules to be much greater than is afforded now. This results in improved reuse of the code, which leads to fewer bugs. The approach also allows more sophisticated concepts used by the programmer to be captured in the implementation, which results in a clearer and more maintainable program.
Another corollary of this idea is scaling: one of the major hurdles to code reuse is that interfaces appropriate to an 8-bit embedded microprocessor are not suited to a supercomputer, yet many of the problems being solved are alike. Adjectives and adverbs allow efficient requests to be generated, with the effort required hidden from the interface. One could easily imagine a family of implementations for a tree that covered a wide range of hardware; any user could use the interface equally without caring about the scale of the machinery underneath. This is not feasible where the client has to get involved in the step-by-step processing.
And finally, the scope offered to implementors of the interface is much greater where the request is able to be more expressive. For example, an interface might offer "node" and "leaf", and have standard routines for handling requests that include these elements. However, if "leaf nodes" was very commonly used, then this pair could be identified in the implementation and an optimised fragment of code selected. This optimisation can be kept entirely hidden from the user.
As I said before, this is a (slightly) unorthodox point of view; I hope it is helpful in the research.
Brenton HoffI was very pleased to see that the Risks Forum is now 10 years old, and I thought a comment would be appropriate on the contents of the tenth anniversary issue.
I thought the different viewpoints were interesting and worthwhile, but I didn't see anything explicit on the two areas that I consider to be the most important issues we face in the computing community today:
Integrity and Availability
I saw several fine articles, including [list deleted by PGN...]
All of these issues are vital and interesting and the authors gave us well thought out discussions and/or pointers to useful material. I commend them on their efforts, but at the same time, I am deeply concerned that we, as a community, are scoring magnificent hits on the wrong targets.
I don't want to take a great deal of time and space in this illustrious and now scholarly forum to go into a great deal of detail. I only want to express that the issues of privacy, perceptions, reliability, and how people interact with computers will never be fully addressed unless and until we address the issues of integrity and availability, for meeting each of these challenges depends on the integrity and availability of information systems and the information they manage.
I thank the risks forum for ten years of meaningful discussion, active participation, and thoughtful exchanges of information. I hope that the moderator continues to operate with the same degree of integrity that has brought this forum so far and that the forum remains available for all of its readers for many years to come.
Fred Cohen[Thanks. Hopefully we can operate with Integrity AND Availability. PGN]
In RISKS-17.22, Andrew Marc Greene writes:
> the software equivalent of the "Sneakers" chip
The ``Sneakers'' chip could magically invade any computer system. ``The Net'' created a more plausible scenario. (Warning! Spoiler follows.) serih eH .rood kcab a htiw erawtfos ytiruces secudorp yug dab ehT dna IBF eht yltneuqesnoC .smetsys retupmoc fo stol otni kaerb ot srekcah ,erawtfos :laroM .erawtfos ytiruces wen sih llatsni no os dna QADSAN )-: .toor sa nur ot dewolla eb ton dluohs ,erawtfos ytiruces neve
> (and the IP equivalent of a 555-xxxx number is
> xx.xxx.345.xxx).
Yeah. Unfortunately, typical IP software will silently convert 345 into 89, which is a valid number. A better solution would be to allocate a set of IP addresses for use in movies. How about 43.43.xxx.xxx?
---DanPlease report problems with the web pages to the maintainer