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…
Over the weekend National Public Radio had a piece about a new form of sports
wagering: radio-controlled mechanical horse racing. Apparently the robot
horses used are miniature, which allows racetracks to be placed in smaller
areas; the "horses" also of course do not require care, feeding or jockeys.
The idea is being proposed by an individual who has built a few operating
prototypes.
One reporter raised the question: What is to prevent an unscrupulous bettor
from interfering with or jamming the radio signals? The promoter replied that
he would be using military technology that prevents jamming.
I'm sure the Pentagon will be delighted to hear that they no longer have to
worry about radio interference.
Michael Trout
A small update on the death of the 13-year-old girl crushed in the elevator a few days ago: It seems that the elevator the girl was killed in was the same one that had been `repaired' only a few hours earlier. Also, a quote from today's story (The Ottawa Citizen, Tuesday April 4, 1989, pg A1 + A2): "The elevator was open and she took one step inside. But she didn't take the other one because the door closed and went up." ' [Idil Adam] (She was crushed against the upper door frame. I take it she must have been caught by the inner doors and carried upwards. No mention has been made yet of any possible reason the elevator was able to move with the doors open, or of why the usual obstruction sensors didn't cause the door to open when they started closing on her. Indeed, neither of these -questions- has been raised yet in the paper.)
Here in our office building we have elevators with similar problems, though
possibly not as dangerous. A lot of these problems seem to be due to bad
software.
The elevators are "Otis Elevonic 401" elevators. They appear to be
microprocessor controlled; they have voice synthesizers that announce
the floors, and scrolling text displays that give advertisements about
the stores downstairs, the date and time of day, etc.
They have a number of problems that I've seen thus far:
1) The sensors which are supposed to stop the door when they collide with a
person do not use mechanical switches; they seem to use electronic "body
capacitance" switches. These switches are often out of adjustment. On some of
the doors, the door will stop and reopen before it contacts you at all. But on
several of the doors, the doors won't reverse unless you actually touch both
doors' switches at the same time with your hands. Contact with a coat sleeve,
or hand contact with just one door, won't work. Apparently the traditional
mechanical switches were replaced with electronic switches to reduce problems
of mechanical wear on the switches, without consideration that the new switches
are not as reliable in the field because of this adjustment problem.
2) There is an evident software bug in the elevators' exception handling. If
the door is held open for longer than a certain amount of time, the elevator
enters an exception mode in which a buzzer begins sounding (the voice
synthesizer doesn't say anything during this time), and the elevator tries to
close the doors even if you are still holding them open. Sometimes when it
enters this mode, the elevator badly malfunctions. It will sometimes clear all
or some of the buttons that were pressed. I've been on the elevator following
this exception handling when the elevator was supposed to be going down and
would instead go up to a floor for which no button was pressed, stop without
opening the doors, and then after a moment go down to the proper floor. It
looks as if the programmer(s) didn't test this exception handling very well.
3) The timers for how long the door stays open, etc., seem to be implemented in
software, and use a mysterious algorithm for deciding how long to keep the
doors open that sometimes results in the doors closing before anyone can get on
the elevator. You can never tell when the door is going to close. Sometimes
it takes a long time for it to do so.
4) It is possible to confuse the elevator by pushing more than a certain number
of floor buttons at a given time.
5) The elevator has a feature whereby, if you accidentally get on the elevator
and intend to go up when it is going down (or if it changes direction due to a
timeout before you push the button), it won't let you push the button for the
floor you want to go to. You can push the button, but it won't light up, and
the elevator ignores it.
6) The buttons are apparently polled periodically by the microprocessor. When
you push the button, it lights up (apparently via a local switch) while you are
holding the button down; but if you release the button before the polling has
detected that you pressed it, the light goes off. The initial lighting of the
button seems to have been a bad design decision, since it gives the user the
incorrect impression that the button pressing has succeeded.
7) The buttons inside the elevator are labeled with cryptic icons. For example,
at the bottom of the button panel are some buttons labeled exactly like this:
<|> >|<
One of these closes the doors, the other opens the doors. Some elevators have
a front door and a back door, and the buttons for those are labelled like this
instead:
<|> <||> >|< >||<
Many people seem to be confused by these icons, and when trying to stop the
door from closing for someone, will push the button that causes the door to
close instead.
These are only the more evident problems. The elevators have other bugs, such
as a tendency to display "Japanese" characters instead of English on the
scrolling displays, to not detect the door position properly if someone stops
it (causing the elevator to sit until it goes into the exception mode), and
other anomalies. It appears that a lot has been implemented in software that
was formerly done in hardware, and the software has not yet been well-debugged.
In late October 1988 the Naval Postgraduate School was ordered to switch its
payroll from the Civilan Pay Branch at the Naval Supply Center in Oakland to
the Navy Regional Finance Center in Washington DC. Since then, there have been
hundreds of errors in paychecks reported to the comptroller's office at NPS.
The conversion was almost completely botched:
- Even though the data was computerized both in Oakland and Washington,
the switch was apparently done by manually keying in the data
(this conclusion is based on the types of errors that were made)
- There was apparently NO cross checking done between the original data
from Oakland and the data as recorded in Washington
- There were apparently NO sanity checks done on the data as recorded in
Washington
In my case, they messed up my last name ("Shimeall" at Oakland became "Shimball"at Washington), changed my federal tax status and number of exemptions (from
Unmarried and 1 in Oakland to Single and 0 in Washington) and removed the
deduction for state taxes (required of all California workers). My colleagues
have reported errors including failure to include deductions for health
insurance, multiplying payroll deductions (i.e., suddenly doubling the life
insurance deduction), greatly increased or decreased number of dependents, and
errors in amount of accumulated leave and sick days. According to the
comptroller's office there have been about 5 edge-inches of reported errors in
payroll.
I'm not certain if this changeover from Oakland to Washington involved just NPS
or if it involved other facilities in Central and Northern California. Do any
of the other RISKS readers have similar tales to tell?
Tim
In The New York Times, Monday, March 27 1989, page D15, Business section, there was a 7 page, multicompany advertising block entitled Special Report: NETWORKING TECHNOLOGY and Applications , which included the following "article". It was accompanied by, and was undifferentiated from, several vanilla technical "articles". Networking in the year 2000 A.D. In the year 2000 networked computing is not restricted by regulatory, political, geographical, or psychological boundaries. No longer is it of any concern whether an MIS department can deliver a cost-effective, reliable, and high-performance network. [...] [...perfectly networked world...] Security is not compromised in all this openness. Imagine one small computer virus roaming through this perfect network. Imagine just one mischievous hacker taking on your identity. Imagine just one fanatical terrorist manipulating the world's information sources. Needless to say, "the network" requires absolute integrity. End-users are screened via eye, voice, fingerprint, and brainwave patters. In the year 2000, a worldwide common access control scheme allows for easy yet authorized access by end-users to both private and public sector information. This is not to say that once you are in, you are home free. Not at all! Users, as they are born, educated, employed, and retired, gain (and lose) access to information. Provisioning of network services is by valid want, verifiable need, absolute necessity, specific job function, and paid subscription. There are no more privately operated and managed networks. Any privatization results in wasteful informational isolationism. The original concept of ISDN reaches its full technological glory and simply renders obsolete any other networking approach. Network processing grows to such gargantuan proportions that the telecomm companies of the world develop into non-profit, publicly funded United Nations' organizations that are chaged with the world's core central information resource. Corporate data centers become purely business application resources in 2000. [...] Direct memory and CPU access is available from within the corporation and from without. Technology is replaced long before it breaks, Murphy's Law is amended. [...] Programmers are a thing of the past. [...]
>Some newspapers ... perform statistical tests and cross-database matching. ...
Newspapers have been doing this for ages, they've just had to do it by hand.
There are a handful of companies that sell all sorts of organized information
to newspapers/media outlets.
If they can be proved to have been grossly negligent they're in trouble as
well. Also, a newspaper that builds up a record of attacking "poor, innocent
citizens" will be raked over the coals by the competition for attacking
"upstanding citizens and readers".
>Finding and printing an interesting coincidence ...
This sort of thing has been used to crack major stories concerning: real
estate dealers with racist selling practices, small town/county "accounting
errors" and a handful of other problems. It's still very new to the newspaper
industry (many of whom think a MacIntosh should be easier to use :-). Give it
a few years to wear off, and they'll use it as responsibly as any other
information gathering tool.
Check recent issues of Columbia Journalism Review, Editor and Publisher, et al.
for articles on "computerized data gathering". There are people out there, in
the newspaper industry, who are concerned about privacy and access to
computerized information about individuals.
J. Eric Townsend
Quote out of context from today's New York Times (p.35): "Engineers who design locomotives bristle at any notion that they are mired in a low-technology industry. Microprocessors control the operations of the latest generation of locomotives, they note..." Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
In the 6 Feb 1989 issue of Aviation Week: Air Force Gen. Bernard P. Randolph, commander of the service's Systems Command, bemoaned the state of military software as a "huge problem" that runs industry-wide. "We have a perfect record on software schedules — we have never made one on time yet and we are always making excuses", he said at an Air Force Assn. symposium. The general also weighed in with criticism of electronic combat [radar, countermeasures, etc. --HS] programs, calling them a "disaster". But he blamed government as well as the defense industry, saying Uncle Sam constantly changes requirements and budgets.
In thinking about the specific problem, originally discussed here under the heading of "Faking Internet mail", of determining whether or not the From: header line is valid, I came upon the following scheme which would authenticate that a given message was sent by the specified (user,host), if you're prepared to assume that the mail software at the actual host claimed in the message is trustworthy, and if you assume no perversions of the network short of line-tapping. The following is from the point of view of host A, receiving mail: 1) A connection is opened, and a mail dialog is initiated by a remote host. 2) In order to maintain upwards-compatibility with the current mail system, the dialog may proceed the same way that it customarily does, at the conclusion of which host A executes step 6 below and exits thereafter. 3) If the remote system supports this authentication scheme, it will send a special code to initiate the following authentication sequence. 4) Host A assigns an identification number n (say, the value of the system clock) to the mail message being received, and tells the remote host to associate the number n with this message. 5) The remote host sends the message and completes the connection. 6) A passes the message on to the user it is destined for, say X, with a header line: "Message n, not yet authenticated." 7) A decodes the From: line and constructs a message to send to the host, say B, specified as the original sending host. This will be a message containing special codes that talk directly to the mail servr on that machine. 8) A sends to B the message, which says: "I received a message, purportedly from user Y at your location, to which I assigned the identification number n. Did you send it?" 8) B receives the message. If it did send the message, it has kept a record in an authentication database cross-referencing
Advertising vs the net
Brian Kantor <brian@ucsd.EDU> 5 Apr 89 13:30:17 GMTCalifornia Assembly Bill AB576 (not yet passed into law) states that a person who uses a machine that electronically transmits messages or facsimiles of documents through connection with a telephone network to transmit unsolicited advertising material for the sale of any realty, goods, or services is guilty of a misdemeanor. The IEEE San Diego Section Bulletin (from which the above is excerpted) states that the SD-IEEE propose supporting that Bill. Apparently this is an attempt to control FAX junkmail. I do not have the full text of the Bill, but it seems to me that there is some possibility that it could affect the USENET (and other BBS-like) transmission of many types of messages that are currently accepted by this community. There might also be significant first-amendment issues. Possibly other states might follow California's lead on this; some states have already enacted or considered FAX junkmail legislation. It seems to me that such a law must be drafted carefully to avoid fixing things that aren't broken. It might well be worth your time to write for a copy of the Bill and comment upon it to your legislators. Remember that they don't read the net, so blowing smoke here won't help. - Brian
Gorilla pictures on credit cards [2nd Randell item, RISKS-8.48]
jcmorris@mitre.arpa <Joe Morris> Tue, 04 Apr 89 09:25:57 ESTIn RISKS 8:48, Brian Randell reports an experiment in which a UK organization tested the utility of putting the holder's picture on credit cards as a theft deterrent. The "holder's" picture was that of a gorilla, but there was no problem using the card. Is that *really* a valid test? Considering the number of strange things you can find on credit cards in the US (and probably other countries), and given that the merchants who accept the credit cards aren't expecting to have pictures on them as anti-theft measures, I don't find any justification for concluding that the test demonstrates a failure of the concept. The use of the photo ID on a driver's license as a check for age for booze purchases is well-established, and if the clerk is careful will filter out some of the more obvious "borrowed" cards. Nobody claims that it is perfect, just that it helps reduce the use of other people's cards. On the other hand, there is the famous (and possibly apocryphal) story of a WWII defence plant worker who demonstrated that the guards were not checking the picture badges...she replaced her picture with one of Hitler and wasn't ever stopped.
Re: Credit card magstripe-encoded pictures [Randell, RISKS-8.48]
"Jay Elinsky" <ELINSKY@YKTVMX.BITNET> Tue, 4 Apr 89 10:18:05 EDTWere photographs normally included on the credit cards used in this experiment? If not, then the store clerk would be going "beyond the call of duty" in checking the photograph. The clerk could even think that a picture of a gorilla is the issuing bank's logo. And if photos were normally used, the clerk might think that the person presenting the card is the gorilla's legal guardian, since you'd hardly expect the gorilla itself to walk up to the counter :-) The experiment might have been more valid if the cards had a photograph of a *person* who looked markedly different from the bearer of the card. Jay Elinsky, IBM T.J. Watson Research Center, Yorktown Heights, NY
Re: Credit card magstripe-encoded pictures
<eddie.caplan@H.GP.CS.CMU.EDU> Tue, 04 Apr 89 14:19:49 EDTSince the cashiers probably weren't aware that the gorilla was intended to be a form of identification, this result isn't surprising nor significant. especially now that many credit cards come with meaningless holographic images on them, like the bird-in-flight on the card i hold.Please report problems with the web pages to the maintainer
xTop