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…
Charles Schwab & Co spent more than $100,000 to conduct a nationwide poll on program(med) trading, with two widely advertised free 800 phone numbers set up to record the pro and con votes. Apparently someone at Wells Fargo (which has a high-profile program trading subsidiary) set up an autodialer to vote YES continuously, which was detected by their programmed monitoring. (` "First we have program trading. Now we have program dialing," quipped Senior Vice President Hugo Quackenbush. ') In 12 hours, there were 12,191 votes, 65.3% for, 34.7% against. [Source: San Francisco Chronicle, 11 Nov 1989, pp. B1-B2.] [By the way, I observe that one call every twenty seconds for 12 hours would account for the entire difference between the pros and cons. One call every six seconds would have accounted for ALL of the pro calls. We might suspect that an autodialer could easily have skewed the results — although perhaps others on both sides were also using the same strategy.]
The Bay Area Rapid Transit has for years been having troubles with its computer systems — both old and new. The old one is supposed to handle 64 trains at once, but is barely able to handle 39. The new system — almost ten years late when it went on-line three weeks ago — was supposed to be able to handle 108 trains, but becomes seriously overloaded at 10. Consequently, all of the long-planned extensions are on hold. (The system supplier is Logica. The old system is still being used, at least as a backup when the new one is being tested.) "An outside consultant that designed three control systems for the Paris Metro and was brought in by [BART General Manager Frank J.] Wilson has already determined that even if the new system were able to perform as promised, it is obsolete." [A summary of "BART's New Computer Called `Complete Failure'", By Harre W. Demoro, San Francisco Chronicle, 11 Nov 1989.] An earlier article indicated that the BART system has been sorely pressed in trying to accommodate the great increase in traffic due to the loss of the Bay Bridge in the earthquake, and many train cars are out of service.
The captain of a ship which ran aground on an environmentally
sensitive live coral reef off the US coast attributed the accident to
a confused officer and a bad user interface. Apparently, an officer
incorrectly changed course because the steering mechanism on the ship
operated in the opposite fashion from most such controls.
Whether or not the control was computerized, this demonstrates quite
dramatically the potential dangers of inconsistent user interfaces. I suppose
the company which built the control could be held liable for the poor design.
There may be parallels with GUI issues yet to come. What if a company has to
use an inconsistent interface because of patent restrictions? Could the
company still liable for the errors of a confused user?
Excerpts from the UPI article follow:
``I think he made an error. I think he was confused,'' Capt.
Zdravko Beran told Coast Guard investigators on the first day
of testimony before a board of inquiry. ``He told me that
(navigational) light was dead ahead and then he wanted to turn
a few degrees to the port (left).''
Instead, the officer, Zvonko Baric, turned the ship to the
right, or starboard, causing it to run aground on sensitive
coral in the Fort Jefferson National Monument, Beran said.
The steering mechanism must be turned in the opposite
direction of the intended course — the reverse of how most
such devices operate, Beran said.
Asked how future such accidents could be avoided, Beran said
the federal officials could require ships to go around rather
than through the national monument.
Jim Helman, Department of Applied Physics, Stanford Univ., Stanford, CA 94309
In RISKS DIGEST 9.40, Randy Davis says,
> Numerous stories have been reported on this list under the title
> "computer error" and "computer risk," that seem to me to have nothing
> essential to do with computers, and a great deal to do with very
> different issues.
> . . . I suggest the simple test above: Ask, can the identical
> problem can arise in the absence of computers?
I claim that it is not that simple. In a traditional library, it was possible
to invade your privacy by making a list of all the books you have every checked
out. All an investigator had to do was open every book in the library and look
to see if you had signed the card inside. The information was publicly
available, but actually it was benignly protected by an enormous collection
cost, so noone every worried about it.
These days, if the library has a computerized circulation system, and it is not
designed with proper regard for privacy, it may be possible to get this
information in a few seconds with a single request. Most computerized
circulation system protect this information and many installations
systematically delete it to avoid any possibility of such investigations. Yet,
when the first circulation systems were designed, some people said that the
circulation information has "always been public" as an argument against
protecting the information in the computerized system.
The Registrar of Motor Vehicles in Massachusetts has long used the "it has
always been public" argument on car registration information as an excuse for
selling tapes to mass mailers. But as I recall, I didn't receive that class of
junk mail back in the days when you had to personally visit the Registry and
copy the information out of their ledgers.
The point is that the speed and efficiency with which data can be processed by
computer can convert a neglible risk into one worth discussing. Had the RISKS
forum been around then, I think the library debate would have been quite an
appropriate topic. Ditto the Mass. Registry.
Finally, the availability of the computer to discover connections may tempt
people to create data bases that they wouldn't otherwise consider feasible.
When I saw the report in RISKS on the proposed child-abuse data base I assumed
that this was an example of a data base that probably wouldn't have been
proposed had computers not been available to implement it--especially the part
about identifying people who use multiple doctors.
Thus I am prepared to tolerate a certain amount of fuzziness in identifying the
edge of the computer-RISKS arena by our beleaguered moderator.
Jerry Saltzer
<>When five out of six hits are human errors, imagine the complaints!
>
> It goes to show the importance of considering the total effect of a system
> change, not just the project at hand. It was a serious design error [...]
I am very surprised at how much complaining there has been about
this error rate. I think finding one stolen car in every six stopped
is a phenomenally *high* success rate. It doesn't seem a major
problem to me to inconvenience five people for a relatively short
period of time in order to apprehend one serious criminal. I would
think almost any other form of police work would involve a much higher
level of inconvenience to the public for the same level of success.
For comparison of order of magnitude, look at neutron-activation bomb
detectors, to be installed in airports. They are said to have something like a
3% false positive rate (and that is in controlled tests, so the real rate will
most likely be higher). I don't have a number at hand for the actual rate of
bombs in checked luggage, but let's say that it is 1 in 30 million (I'm sure it
is less). That corresponds to 1 million false positives for every true
positive. *That* is a high rate of error. And our society has chosen to spend
nearly a billion dollars on that system.
— David desJardins, IDA/CRD
I finally had a reason to dig thru the same box which had the following reference in the history of Ada. The quote comes from Pascal News #13, December 1978, then published by the Pascal User Group. This is a bound journal (although basically Xerox(tm) copied sheets); it was unrefereed. By way on context, it should be recalled that the initial proposals for the new DOD language (then refered as DOD-1, various "colors," and the progression: Strawman, Woodenman, Tinman, Ironman, and then Steelman) had 17 proposals based on Pascal (the last was based on PL/1, you can guess who proposed that 8). So, the Pascal community was thrust into the limelight. (It was still a somewhat obscure language at the time.) The quote is authored by Andy Mickel, U MN, then the editor: Latest News About DOD-1 (ADA or DOD0) --Andy Mickel As we've told you in previous issues of Pascal News, the U.S. Department of Defense (DOD) has endeavored to procure a common programming language based on Pascal for all "embedded" computer applications — computer systems attached to weaponry. Reliable software should kill people reliably! ..... [above description removed] ...colors: BLUE-Softech, GREEN-Honeywell Bull; RED-Intermetrics; and YELLOW-SRI International. The article goes on for two more paragraphs, but Andy's comment about killing was not taken lightly. Pages 9-10. So much for the history of programming languages. --eugene miya, NASA Ames Res. Ctr. formerly joint ANSI X3J9/IEEE P770 Pascal Language Standards Committee
Please report problems with the web pages to the maintainer