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…
> (Karen Sollins quotes story from Boston Globe - to paraphrase, patient > would be badly overdosed if operator first selected electron beams then > changed selection to X-rays. David Parnas observed that two kinds of errors > were made; first, system should not have accepted inconsistent or unsafe > input specifications, second, synchronization problem elicited when operator > types rapidly. I work in a radiation therapy department, so my observations may be of interest. First, this is a VERY SCARY STORY. It was estimated that patients got 17,000 to 25,000 rads in a single treatment. For comparison, typical therapeutic doses are in the range 4000 - 6000 rads, delivered in 20 to 30 separate daily treatments administered over a month or more. What is really alarming here is that the therapy machines are set up to deliver dose rates on the order of 100 rads per minute. I believe that most therapists would assert that there was no way, physically, that a machine could deliver tens of thousands of rads in a few seconds. That was my reaction when I first read the story in the New York Times (Sat. June 21, p.8, national edition). The New York Times story mentioned that when the accidents first occured, the operators thought the patients had somehow been electrically shocked (by leakage currents through the couch or something) rather than overdosed. The New York Times story did not mention the x-ray/electron confusion, and that is the key to this accident. A modern radiation therapy machine is based on a linear accelerator that produces an electron beam with an energy of 25 MeV or so. You may direct the electrons directly into the patient (at this energy electrons are ionizing radiation), or, to produce X-rays, you put a heavy metal target in the electron beam, and when the electrons hit the target X-rays come out the other side. The target is moved in and out of the beam automatically. Here is my speculation of what happened: I suspect that the current in the electron beam is probably much greater in X-ray mode (because you want similar dose rates in both modes, and the production of X-rays is more indirect). So when you select X-rays, I'll bet the target drops into place and the beam current is boosted. I suspect in this case, the current was boosted before the target could move into position, and a very high current electron beam went into the patient. How could this be allowed to happen? My guess is that the software people would not have considered it necessary to guard against this failure mode. Machine designers have traditionally used electromechanical interlocks to ensure safety. Computer control of therapy machines is a fairly recent development and is layered on top of, rather than substituting for, the old electromechanical mechanisms. I suspect there was supposed to be an interlock between beam current and target position, which should have prevented the beam from going on at all. Maybe there was, but it was broken, too. I stress that I am not familiar with the design of this particular machine and that these are just speculations. I should also mention that these are the first incidents I have heard of where an overdose was delivered due to an error in the therapy machine dose rate. Overdoses in radiation therapy do occur, but in all the cases I have heard of they are due to incorrect planning and patient positioning: that is, the radiation beams pass through the wrong part of the patient and irradiate healthy tissues rather than the tumor, or the therapists incorrectly estimate the dose rate inside the body that will be produced by a specified machine dose rate. -Jonathan Jacky Department of Radiation Oncology University of Washington, Seattle WA
I have a question for the RISKS readership.
I want to make an arrangement in which I can feed data to a computer
in the physical possession of an adversary. The output of the program
can be certified via a public-key encryption system. The question if
this: can the computer hardware be designed so that its programming
cannot be compromised, even though the data would be entered by the
adversary? Alternatively, can the computer detect attempts to
compromise it?
(Assume that the data is known to be good.)
[Herb, You have almost gotten to the MUTUAL SUSPICION problem, where a
vendor provides the program and a customer provides the data — and where
neither trusts the other. Limited solutions can be conceived, but many
assumptions must be made about the integrity of the communication paths, the
trustworthiness of the environment in which the mutually trusted arbiter
must run, the absence of all sorts of side effects (such as Trojan horses)
and covert channels, the adequacy of the hardware if a general solution is
sought, the nontamperability of the hardware and the trusted software, and
so on. In your specific case, the answer is to a first approximation NO,
although if you start making (unreasonable?) assumptions, MAYBE. Peter]
<<I'm not concerned about the hardware being maintainable
(though it can be replaceable at great cost). Herb<>
Radar detectors are presently legal in 48 states. Only in Connecticut,
Virginia, and (I think) the District of Columbia are they illegal. As
I understand it, Virginia's law is based on the idea that it is illegal
to use radio frequencies in the commission of a crime. Thus, it would
seem that using a radar detector in Virginia is illegal only if you are
committing a crime (e.g., speeding) when the police use radar on you.
This sounds too good to be true, so it probably is :-). I know nothing
about the specifics of Connecticut's or DC's laws on radar detectors.
If you are interested in the risks of NOT using a radar detector I
would be happy to explain why I am a very satisfied owner of one. This
issue isn't really appropriate for RISKS (even though the good ones
*do* contain computers!) so let's keep this sort of discussion private.
:: Jeff Makey
Makey@LOGICON.ARPA
Clipped from the Telecom digest...
------- Forwarded Message
Date: 21 Jun 86 03:22-EDT
From: Moderator <seismo!XX.LCS.MIT.EDU!Telecom-REQUEST>
Subject: TELECOM Digest V5 #122
TELECOM Digest Saturday, June 21, 1986 3:22AM
Volume 5, Issue 122
Date: Fri, 13 Jun 1986 06:06 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Northern Telecom DMS-100 digital switch problems
On Wednesday, May 28, the Southfield, MI (suburb of Detroit) Michigan
Bell ESS office's Northern Telecom DMS100 digital switch went down for
almost the whole afternoon, reportedly depriving 35,000 subscribers of
service (they couldn't even get a dial tone).
Thursday, May 29, it occurred again sometime in mid-morning and the
digital switch was down for almost the entire business day (it came
back around 5:30 pm local time), this time reportedly taking out
50,000 subscribers, including the police and fire departments.
In an interview, a spokesman for Michigan Bell was quoted as saying
they don't know what caused the problem. He went on to say they are
working closely with Northern Telecom to find the cause.
A spokesman for Northern Telecom, in a recent telephone conversation,
said that some 20-30 software updates for the DMS100 were necessary to
cure certain problems with passing 212a and V22.bis modem signals
through the switch. It is unclear at this time if these updates have
any bearing on the outages of the past two days. According to sources
at Michigan Bell and Northern Telecom, the updates have not been done
to the DMS100 digital switch in the Southfield central office. They
are reportedly scheduled to be done on June 7th.
Stay tuned...
- --Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
uucp: {ihnp4,allegra,cmcl2,dual,decvax,mcnc,mcvax,vax135}!seismo!w8sdz
I offered some thoughts to RISKS which were reprinted in ARMS-D. I have gotten some interesting feedback to those thoughts, which I would share. First, let me thank you one and all for the character of your replies; they have been cogent, courteous, and convincing. No hints whatsoever about doubts of my intelligence or integrity - even by those adamantly opposed to my point of view. Let me summarize (and restate) my principle points: 1. SDI will roll on, at least until '89; i.e., the Reagan Admin. is firmly committed to it. "Nature abhors a vacuum." Americans demand adequate defense, while complaining of its cost [which is usually excessive]. Most groups [e.g., Common Cause] who have tried to stop MX et al have offered no alternative; by default, that leaves us stockpiling weapons; we already know that doesn't work; for it costs too much, raises the balance of terror, and besides the USSR is getting ahead of us now. 2. You and I don't have the wherewithal to stop SDI; but perhaps we can glean some benefits from it, especially if we work within the system; e.g., to pursue compatible overall goals, BUT doing valuable things. 3. Bringing our traditional ["non SDI?"] defenses up to reasonable state- of-technology is probably a good idea; e.g., using computers that encourage good software practices, run efficiently, etc. 4. SDI does NOT equate to "ICBM defense." You will search my earlier messages in vain for the term "ICBM." I made it plain - or tried to - that ICBM's from the USSR [or wherever] are [in MY opinion] less of a threat than less exotic weapons in the hands of criminals/terrorists, of whatever race, religion, nationality. Now to add some new points: 5. SDI need not cost as much as some fear it might. For example, going to the moon in the '60's cost the USA nothing! Miniaturization of electronics, and encapsulation for space led directly to domestic products like the now common "pacemaker." The DIFFERENCE between tax dollars paid by those wearing pacemakers, and the "aid to their families" that would have been paid had those heart patients died or been disabled, is more than $25 billion. [Data from a CPA friend of mine.] 6. An adequate defense MUST be one that we can afford; and I don't mean by ignoring the deficit, and spending billions just because that's do-able. Example: Why are we dismantling Trident subs, while still more funds go to "MX?" Trident IS MX - demonstrated, workable, paid for. If a particular sub becomes obsolete [like some old computers I mentioned], then replace it; but what's the need for "mobile silos on rails?" Common sense tells me that there IS a good reason; security regs probably tell WHY I don't know that reason; but Murphy's Law suggest that maybe, just maybe, it's the "military-industrial complex" going after profit. That's NOT necessarily bad; it's "free enterprise." But that choice is not necessarily optimum, either. That's why our debate is valuable. 7. Advances in computer technology made in pursuit of SDI can be applied to other problems; e.g., crime prevention. I'm arguing that reliable real- time networks, intelligent "signature recognition" systems, and other digital "tools" can help us intercept dope traffic, as well as ICBM's. 8. Last, but certainly not least, if this work is to be done, it can either be done by the "best and the brightest" or by technocrats and bureaucrats in government, industry, and academia. If that happens, if the best do not rise to the challenge, then I guarantee that the costs will be much higher than necessary, and the results much lower than deisrable. But if we do take the opportunity, then we can use the managers' short term interests to an advantage; i.e., we can honestly say that "Star Wars" [R2D2 et al] is not possible today; and then diligently work to produce what is reasonable. Many managers [in government and elsewhere] will go along with that incremental progress, because it IS a "bird in the hand." Indeed, Mr. Reagan is reputed to lead by concept rather than in detail; so let's supply him the details, rather than abandon that task to the technocrats - of whatever stripe. This argument is all the more relevant in light of recent observations that Challenger failed for managerial reasons, not [just] technical ones. If the best managers neglect SDI to bureaucrats, then decisions will be less than optimum; if the best scientists neglect SDI to technocrats, then even the best decision makers will be hamstrung by second-rate sys- tems. Our only hope is to marshall our best minds, then evolve SDI. Finally, to state a position. Some readers have [tried to] guess which side of SDI I'm on; most have been wrong. That's because I won't take a side, as the question is presently posed; viz., am I for or against the President's SDI program? That's too close to "have I stopped beating my wife?" A complex question defies a simple answer. I'm FOR adequate, affordable, ethical defense; I don't believe that SDI, as presented in the popular press, is THE answer. Unlike some readers, I have no direct source of information about what Mr. Reagan and Mr. Weinberger REALLY think; I only have the press summary of their summary of closed sessions in the Pentagon and White House. That's third-hand information. And, I assert again, we must begin with a land-based system; that minimizes the costs, reduces the technical risks, and causes the least threat because such a system could not be used offensively. Bob Estell p.s. The opinions above are not necessarily shared by any other person or any organization, real or imaginary.
About 5 months ago I advertised a transcript/tape for a debate on the economic implications of Star Wars, held at MIT on November 21, 1985. Finally, I have uploaded it from my Mac, and it is available online. The debate is between: Lester Thurow, MIT Economist Leo Steg, GE Space Systems Division (retired) Bernard O'Keefe, Chairman of EG&G For FTP'ing it, it is located in MIT-XX:<cowan>economics.sdi If you can't FTP it, tell me and I'll send it to you. -rich
Please report problems with the web pages to the maintainer