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…
Surprise! London Underground Travelcards that are at least 2 years old just happen to work. As a result, the cards are being sold on the black market for over 50 pounds for four-zone cards. The mag stripe information format just happens to match, giving unlimited free rides. However, not of the all old cards work. Estimates of fare fraud already exceed 25 million pounds a year, just over 3 million of which is offset by 10-pound fines for misuse. [Source: Touts cash in on old Tube Travelcards, by Dick Murray, Transport Editor, London *Evening Standard* http://www.yahoo.co.uk/headlines/19990709/london/newsstory154274.html] [As usual, the suggested fix is to completely replace the system — with a new smart-card system. Interesting that the cards aren't specifically tied to the calendar date, which would have prevented this. Risks lie in costs of manual achecks to safeguard the intent of the system... Lloyd.] <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
The latest (and independent) report to the Australian Gov. concerning the problems with its new Collins class submarine project recommends the entire combat system be scrapped and replaced with a new off-the-shelf system (at a cost of hundreds of millions). The McIntosh-Prescott report, released 1 Jul 1999, also notes other major problems with the new submarines, including unreliable diesel engines, excessive noise, cracking propellers, poor communications and periscope vision. Deficiencies in project management and procurement were also criticised. The hardware issues, though serious, can be fixed — but the software for the combat system is considered unlikely to ever work. Currently Boeing is working on an interim fix which is described as a "short-term band-aid" which should provide some quick improvements, but which will not lead to a satisfactory solution. We also have an urgent joint US/Aus. Navy project which will spend $A 80 million to help rectify some of the key software problems inter alia. The major conclusion of the report however, is to completely dump the software and start again - "A preferred new system would be configured with less-integrated architecture and would utilise more off-the-shelf equipment". Note the comment "less-integrated". The plans for the combat system called for a tightly integrated system which instead of having dedicated stations for specific tasks (i.e. a sonar station, a separate torpedo control station, comms station, etc.), would have 7 general purpose workstations which could each be configured to perform any (or all) tasks as required. At the time this ambitious plan was rightly criticised. Fears of cost over-runs led to an insistence on a fixed-price contract originally signed in 1987. Computer technology advanced significantly during the life of the project, so that many components were out-of-date by the time they came into use. It appears that the top brass failed to respond quickly enough to many warning bells about the combat system. The result is that Australia has only 1 obsolete submarine in service, and if the problems on the Collins are not fixed quickly, may end up with no working submarines at all for some time. Quentin David Jones
On 8 July 1999, a glitch in a computer system caused train signals in the area around Flinders Street Station (a major station in the central business district of Melbourne, Australia) to fail. The glitch occurred at 5:40pm, and was not rectified until 6:20pm — right in the middle of peak hour. The congestion was not completely cleared until 7pm, and even then, trains were running up to two hours behind schedule. The glitch affected trains traveling to and from the south-eastern and eastern suburbs (definitely Lilydale, Belgrave, Glen Waverley, and Alamein lines; also the Hurstbridge and Epping lines, according to the local tabloid). In addition, trains traveling through the underground city loop to northern and western suburbs had to be re-routed to travel direct, bypassing the loop. There have, apparently, been other similar glitches in the past, lasting for up to five minutes; this is (to the best of my knowledge) the first lengthy delay, certainly in the middle of peak hour. Speaking as somebody who was caught in a train for half an hour between Richmond and East Richmond, I have to say that I've discovered a new swear word: "Public Transport". :-) Standard RISK: all the eggs in one basket, with no backup (electronic _or_ manual) in place. Time to move closer to work and start using my bicycle, I think.
The 14 Jan 1999 issue of the *New England Journal of Medicine* (arguably the most prestigious medical journal published) contained an unusual retraction. This time at issue was not the discovery of fraudulent research, a nasty problem afflicting top medical journals for some time now, but the discovery of a computer programming error in a study of suicide rates following natural disasters. The mistake resulted in the software erroneously counting some deaths twice. When the data was restudied following the correction of the error, the conclusion of the original paper was found to be incorrect. The authors acted ethically in reporting this error and retracting their paper, despite the embarrassment and career implications involved. How many others would have merely kept quiet and not issued a retraction, especially knowing that failure to weed out this misinformation would not likely result in any patient harm (as compared to, say, an error in a dose-finding study)? This problem also raises the issue of the role of senior clinical investigators, most with very limited programming skills, in supervising the efforts of the programmers that work on their research team. REFERENCE: Krug EG, Kresnow M, Peddicord JP, Dahlberg LL, Powell KE, Crosby AE, Annest JL Retraction of "Krug EG, Kresnow M, Peddicord JP, Dahlberg LL, Powell KE, Crosby AE, Annest JL. Suicide after natural disasters. N Engl J Med 1998 Feb 5;338(6):373-8 " N Engl J Med 1999 Jan 14;340(2):148-9 D. John Doyle MD PhD, Associate Professor, University of Toronto djdoyle@home.com
A recent report in a medical journal describes a life-threatening event in a 70-year old man in whom an implantable cardioverter-defibrillator had been previously placed to regulate the patient's erratic heartbeat following a previous cardiac arrest. Unfortunately, a software malfunction in the unit later occurred such that the patient developed an "acute onset of dizziness" from "loss of ventricular output due to an internal software problem". The problem was corrected by reprogramming the unit via the external programmer. REFERENCE: Coppess MA, Miller JM, Zipes DP, Groh WJ Software error resulting in malfunction of an implantable cardioverter defibrillator. J Cardiovasc. Electrophysiol. 1999 Jun;10(6):871-3 D. John Doyle MD PhD, Associate Professor, University of Toronto djdoyle@home.com
Patient monitors are used extensively in acute care medicine, especially during surgical procedures or when transporting critically ill patients. In an interesting report by two anesthesiologists a potentially life-threatening situation is described whereby a transport monitor provided data that did not seem to match the doctors' clinical assessment of the patient. Among other things, the digital pressure display never varied from 120/70. Suspicious that something was wrong, the doctors rechecked everything only to find that on close inspection of the fine print on the transport monitor's screen the words "demo mode" appeared intermittently. They then realized that all of the waveforms and data on the screen were simulated! Even worse, attempts to turn off the "demo mode" failed because a password is needed both to enter and to leave the simulation mode! The doctors switched to another monitor. No harm came to the patient. An investigation later revealed that "the hospital biomedical engineer had used the internal password to place the monitor into the simulation mode for testing, but had neglected to return it to normal patient monitoring mode before certifying it as fit for clinical use." The following comments from the authors are worth heeding: "Anesthesiologists should be aware of this novel form of monitoring "failure." . . . Obviously, human failures were involved in this incident, but improved equipment design could have helped prevent our patient from being exposed to the risk of not being monitored. In particular, we believe it is inappropriate for a password to be needed to exit from an internal simulation mode. We also recommend that manufacturers make "demo mode" messages more obvious when a monitor is in a simulation mode by appropriate use of text size, color, and/or brightness and by having it flash. Such messages should be present continuously, not intermittently. A high state of vigilance continues to be warranted, particularly around the time of patient transport." REFERENCE: Ramundo GB, Larach DR. A monitor with a mind of its own. Anesthesiology 1995 Jan;82(1):317-8 D. John Doyle MD PhD, Associate Professor, University of Toronto djdoyle@home.com
The Justice Department has filed a civil suit under the Clean Air Act (on behalf of the EPA) against Toyota for faulty smog-control computers on 2.2 million 1996-1998 vehicles (Camry, Avalon, Corolla, Tercel, Paseo; Lexus; Sienna minivans, etc.). The suit seeks repairs and fines up to $58.5 billion for faulty software that failed to detect above-threshold emissions. California had apparently approved the systems based only on simulations. Toyota claims the rules were altered after the initial approvals. [AP item, 12 Jul 1999, PGN-ed] Taz Daughtrey, SOFTWARE QUALITY PROFESSIONAL, SQP_Editor@asqnet.org
Many financial planning articles, including a recent Jane B. Quinn Newsweek column, tout a new retirement planning service at http://www.financialengines.com. This operation uses risk-driven models from co-founder Bill Sharpe, a Nobel Laureate, and is strongly VC funded. Incorporating risk gives a probability of certain annual income with ranges and "what-if" scenarios for various portfolio allocations. The on-line implementation is a Java applet with portfolio data held and updated on their server. I put in my approximate data and ran the forecast. Amazingly, no matter how *high* I cranked the annual income goal, e.g. $200K, the result was >95% sunny (literally) forecast. Not real, I was sure, so I ran it on another PC. Same data, held on their site, but this time no matter how *low* the annual goal, e.g. $5K, the applet always gave <5%, very stormy, forecast. In other words, complete opposite results depending upon PC (MICRON pentium-I was more optimistic than Gateway Pentium-II, independent of browser). FinancialEngines tech support responded quickly to the problem and in a few days the schizophrenic forecasts settled down, apparently fixed and downloaded. I'm still hoping for a technical explanation but haven't heard from customer support. Clearly the program didn't have any built-in guards against ridiculous answers. Some people using the model might be blissfully over-spending and others suicidal depending upon their Java/Pentium interaction. But most users of these planners know they have to try several, examine assumptions and models carefully, and pray. Even well-funded Nobel Laureates have QA problems. susan gerhart
Subtitle: Serendipity = Error2 - Error1 ? (or Serendipity = [Error1,Error2] using commutators!) RISKS spends a lot of time bemoaning the negative side of errors. Perhaps more time should be given to "serendipity" which I loosely translate as "order from chaos". Serendipity is celebrated by authors and film-makers as the way to find love after some disastrous mistake. But science also proceeds in such ways. A famous example is that of Kepler. I quote from "Fundamentals of Astrodynamics" by Roger Bate, Donald Mueller, and Jerry White, 1971, Dover ISBN 0-486-60061-0 (Sec 4.1, p. 178): "Kepler's first task was to determine the radius of the circle [of the orbit] and the direction of the axis connecting the perihelion and aphelion. At the beginning of a whole chapter of excruciating trial-and-error calculations, Kepler absentmindedly put down three erroneous figures for three vital longitudes of Mars, never noticing his error. His results, however, were nearly correct because of several mistakes of simple arithmetic committed later in the chapter which happened very nearly to cancel out his earlier errors. "At the end he seemed to have achieved his goal of representing within 2 arc-minutes the position of Mars at all 10 oppositions recorded by Tycho. But then without a word of transition, in the next two chapters Kepler explains, almost with masochistic delight, how two other observations from Tycho's collection did not fit: there was a discrepancy of 8 minutes of arc. Others might have shrugged off this minor discrepancy between fact and hypothesis [or fudged his numbers a la Newton's Moon]. It is to Kepler's everlasting credit that he made it the basis for a complete reformulation of astronomy. He decided that the sacred concept of circular motion had to go. [...] "Forgetting his earlier resolve to abandon circular motion he reasoned, again incorrectly, that, since speed was inversely proportional to distance, the line joining the sun (which was off-center in the circle) and the planet swept out equal areas in the orbit in equal times. This was his famous Second Law--discovered before the First--a law of amazing simplicity, arrived at by a series of faulty steps which he himself later recognized with the observation: 'But these two errors--it is like a miracle--cancel out in the most precise manner, as I shall prove further down.' The correct result is even more miraculous than Kepler realized since his explanation of why the errors cancelled was also erroneous!" The search for the source of errors is often times hugely more valuable than the original error. The progress of science is pretty much fueled by errors. How many times have you searched for a minor bug and in the process of correcting it fixed a major bug? (I seem to recall that David Moon, ex of Symbolics and Apple, used to call these "dead bears", probably having something to do with letting sleeping and/or dead bears alone.) Henry Baker
I noted the old RISKS postings in the archive about traffic signals going
"all green," allowing conflicting traffic:
RISKS-18.94:
Traffic signals, red-runners & all-greens (J. DeBert)
RISKS-18.95:
Re: all-ways green lights (Robert Miller, Sean Ercanbrack, Barak Pearlmutter)
RISKS-19.01:
Re: all-ways green lights (Mark Brader, Steve Summit, Dik T. Winter)
RISKS-19.03:
All-ways green lights ... it's all in the timing (Richard Cook)
So, I thought to ask my uncle, a recently retired traffic consultant living
in the San Francisco area. This is his response:
From: Glenn Grigg [SMTP:glennmg@juno.com]
Date: 25 June 1999
Subject: Re: "all-green" on traffic lights
First of all let me tell you, after a collision at an intersection, [...]
they ALL say [they had a green light]! Now, lets talk chips and
software. The modern traffic signal controller IS software driven, however,
they are rather simple machines with "if this, do that, but not the other"
kinds of decisions to make. Bugs? Maybe, but I've never seen conflicting
greens due to controller software! I have seen wires get crossed, like when
someone knocks a signal pole down and the insulation on the wires get
stripped.
NOW, let me tell you about the conflict monitor. This is a device that is
connected to the field wires at the terminals where the 110v AC wires go
from the cabinet directly to the light bulbs that illuminate the signal
faces. This device does NOT monitor the controller or its software, it
monitors the 110v AC lines. If a software bug were to direct the load
switches close and send 110v AC to green signal faces that face conflicting
traffic, this monitor would detect this conflict and put the intersection on
flash. Do conflict monitors fail? Are they made by Humans? That's why we
test our conflict monitors on a regular basis. Well, how do we do this? The
sophisticated way is to bring it in the shop and hook it up to a special
monitor tester. However, there is a simple way to do this in the field. You
take a short piece of wire, preferably insulated, and you stick one end in
the 110v AC terminal of any green indication wire. With the other end, you
stick it to any other green indication terminal. You have 110v AC in your
hands, that's why I use an insulated wire. When you stick it on a
conflicting green terminal the monitor will "trip" and the intersection will
go immediately to flashing. DON'T do this during the rush hour! You'll be
getting off lightly if people only curse at you!
Glenn
From a website's privacy statement:
Children 12 years of age and younger are not permitted to opt in
for these future e-mailings because the opt-in software requires
users to fill in their age and only users above 12 years of age
are able to submit opt-in authorizations.
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark
The Chris Nandor who deluged the All-Star ballot site with 22,000-some votes for the Red Sox shortstop is not only a huge Red Sox fan [no kidding - his e-mail handle is 'pudge' for Carlton Fisk], but also a known Perlite. He is the Chris Nandor who co-wrote "MacPerl: Power and Ease" with Vicki Brown. He merely used the LWP::Simple module with a few lines of Perl code to produce his anti-Jeter machine. He clearly didn't try to obscure his identity. It would have been trivial for him to spoof his e-mail address, as well as generating random valid numbers for phone number and zip code. Given this thought, one has to wonder how many people actually made the effort to conceal the fact that they were making multiple votes. I see a major-league RISK just around the corner for the All-Star voting site. What happens when someone makes the effort mentioned above and dumps 500,000 votes in on the last day to get their favorite player(s) in? In 1957, the Cincy fans did such a good job of ballot-stuffing that the commissioner had to step in and hand-select other players to start. The names of some of the players who had been pushed out? Oh, no one big, just Musial, Aaron, Mays, ... Now it will only take one person and a 40-line Perl script to do the same thing. David Cassell, OAO cassell@mail.cor.epa.gov Senior computing specialist, mathematical statistician
> Similar to problems AOL has had, it seems that someone, most likely > someone involved with the ISS program, obtained the name of a user with > administrator access, then called the help desk and asked for a password > reset. They were promptly given that new password, after which they > proceeded to do something objectionable with the password file. (That > part's still not quite been released.) Argggh! I know I'm preaching to the choir here, but when I've been administering a system, the policy was that to get a new password, you did one of three things: 1. Show up at my desk and have my hand you the new password. 2. Call me *directly*. This was *only* allowed for people I could recognize over the phone. 3. Call or e-mail me, and the new password would go out via internal *physical* mail sealed inside a use once envelope wit CONFIDENTIAL on it in large letters. At one time we allowed people to informally request accounts & passwords for people working under them. This was stopped after someone slipped in a request for an account for "John Tuttle" (M*A*S*H reference) into the system. They then posted some inappropriate messages to the internal e-mail system. After that, we went *strictly* formal on new account requests. > [... PIN for resets ...] Yeah. Some folks just don't get it. :-( Leonard Erickson (aka Shadow) shadow@krypton.rain.com
> [...] leaving the circuit in a non-deterministic state [...] A question for those who know about such things: is current education in digital circuit design sufficiently attuned to the subtleties of the physical world, or do students have an overly simplistic view of how bits are represented in hardware? Given the deterioration of continuous math education in high school and universities, I wonder...
> 2. Since Hotmail accounts are notoriously anonymous, how was this tracked > back to him so that he could be arrested? > [Anonymity is generally only a relative concept. Who pays the bills? PGN] You don't seem to know that Hotmail accounts are free, hence truly anonymous. Cameron Hayne (hayne@crim.ca), Centre de recherche informatique de Montreal
Couple of comments regarding this interesting item... 1. Hotmail and many other Web-based e-mail accounts aren't really anonymous. They can be pseudonymous in that the user can choose whatever handle and registration info he may want. It is not unique. There are other Internet access resources where identity is not particularly verified. Sounds like end of all accountability but it isn't. There are still many clues available if an incident draws enough attention. 2. Many Web-based e-mail services do give some useful clues in their e-mail's headers. The most useful is the IP address of the system from which the e-mail was submitted via HTTP. I have used this to trace a series of e-mail harassment using Hotmail.com. A form of whois lookup can provide the info for who has the set of IP addresses that include the one listed in the header. The owner of the IP address can be contacted and they can use their logs to find out whose account was used. That is probably what happened in this e-mail panic case. J.D. Abolins
Every e-mail sent out from the hotmail system carries, in the e-mail headers, the IP address of the machine hosting the web browser used to compose the message. This is another risk, isn't it. The risk of assuming that a system is anonymous just because it is notoriously anonymous. :-) Get Your Private, Free E-Mail at http://www.hotmail.com
I've been using a trick to identify abusers who used hotmail already. And the recent Risks article: 'E-mail writer arrested for starting panic' showed that this trick isn't as well known as I thought. Many webmail providers I have seen tend to introduce interesting headers into e-mail sent by them. For example, hotmail appends the following header to outgoing e-mail. Past this, identification is trivial. X-Originating-IP: [206.47.244.30] Regardless of whether or not the webmail provider actually appends such a header, they are very likely to log e-mails anyways. Thus it is very easy for legal or political pressure to grab the logs and identify the user. So perhaps the risk here is that people have been thinking that webmail means anonymous e-mail.. It doesn't. The most reliable way I can find to truly send e-mail anonymously is through the anonymous e-mailer network. (Or maybe a mixmaster network). If you wish to also get responses anonymously, supply a reply-block that sends responses through a web-forwarder service dumping into a webmail dropbox. Then access the dropbox through onion-routing. Scott
Please report problems with the web pages to the maintainer