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…
Apparently airline passengers with portable PCs are using the shaver
outlets in the toilets to recharge their PC batteries. Since recharging a
battery can take some time, this behavior dramatically reduces passenger access
to toilets. [Computers constrain key bodily functions... :-)]
I've encountered three pieces of information that suggest this is not just
a nice urban myth. First, two colleagues have reported encountering the
problem. One on a flight to Japan (where apparently at one point, almost all
the toilets were taken by folks sitting inside recharging their PC batteries),
one on a flight cross the US. Second, there was an article several weeks ago
(I think in the SF Chronicle travel section) on business travel that mentioned
that some business travelers were now requesting seats at the back of the plane
for easier access to the shaver outlets (the article suggested said passengers
were using extension cords...)
Craig Partridge
[HIT or MYTH? Not aMYTH. I noticed on last week's cross-country trip that
ALL of the shaver outlets had been blocked off, with a sticker over the jack
saying that this blockage was effective as of something like November 1991.
A myth is as good as a mile-per-hour increase in speed. Some planes provide
phone hookups in each row group; perhaps we will soon see per-seat
electrical outlets as first- and business-class perks. Opportunity for a
SURCHARGE? <Quadruple pun intended.> Call your favorite airline now. PGN]
Phone May Trap Kidnapper, by Paul Cheston (London Evening Standard, 7 Feb 1992) Detectives hunting the kidnapper of estate agent Stephanie Slater believe they can trap him through the mobile phone he used to pass on instructions for the 175,000 (pounds) ransom drop. Courier Kevin Watts is convinced the kidnapper used a mobile phone to direct him in thick fog towards the disused railway bridge where he left the money. Mr. Watts had been ordered by the kidnapper, descirbed by police as Britain's most wanted man, to a remote phone box near Penistone outside Barnsley. Parking nearby, he carried the ransom money into the booth when the phone rang almost immediately. The ring was so fast the estate agent branch manager realised the kidnapper had been watching him and must have been using a mobile phone. A mobile phone's unique electronic serial number is recorded by the computer which runs the network and can be used to trace the phone user.
The note about extradition problems is interesting. They become especially acute with computer crimes (ecrimes?). In the old days one would commit a crime and then escape to a "safe" country. Today one can first escape and then commit the crime. What are the implications and remedies?
In partial answer to Bob Frankston's question, the implications are of course quite profound. We need more international cooperation to establish and hinder what is illegal. (Cf. the US-Dutch noncommunication noted in RISKS-13.11, 12, 13, 14.) Might we see pirate ships from which cracking would be legal? And a new breed of international terrorism protected by safe havens? The existing international legal situation is certainly inadequate today, but it is also intrinsically limited in what it might eventually be able to do even with greater international cooperation. In addition, we need more-secure computer-communication systems, better user and system authentication, meaningful audit trails, etc., to hinder misuse. Without them, crying over electronically spilled milk money leads to ECrim(e)osus/lacrimosus/lactimosus/ galactimosus. The -osus with the mos'us is the crime that won't rhyme.
On Jan. 27th, D.C. Lawrence reported on D. Gerlernter's "Linda" for distributed computing, and the possible lack of risk awareness shown in related trends. He asked for related trends. In the "NetWork Project", the StatLab Heidelberg has been working on another system for distributed computing making use of idle times of workstations on a net. We agree on the critical asked by D.C. Lawrence. Here is how they are delt with in the NetWork Project. (1) Privacy and user control. The owner should always be in full control of the machine. NetWork uses a demon as a communication agent. All communication for the NetWork system is funneled through this demon, the "NetWork Processor". This "NetWork Processor" is under full control of the owner of a machine. The owner can set up the machine not to participate in NetWork distributed computing at all. Or the owner can set up a certain threshold of idle time after which the machine can be used for distributed computing. The "NetWork Processor" takes care to repect these settings. A machine will only visible to the NetWork System if it is published and is idle in terms of the definition of the l o c a l user. And if the local user comes back, the "NetWork Processor" guaranties to remove (kill, if necessary) any guest processes immediately. (2) Code and information security. How do you prevent the introduction of worms, and how do you guard local information ? At present, we did not see any solution to this problem. We would have liked to migrate code. And we would have liked to Program/train a recipient machine "on the job", as is done in the Japanese TRON system. But we did not see any sound possibility to overcome the risks involved. So we had to refrain from code migration. Again, we put control back in the hand of the owner of the local machine. Using the "NetWork Processor" demon, the onwer may set up one trusted path, and only programs in this trusted path will be accessed by NetWork. So we rely on the risk awareness of the owner, and the usual local system provided by the file system access privileges. To educate user awareness, we took the aggressive way. We gave an example of how you can risk everything by putting an unrestricted shell in the trusted path. And we told everyone to take a lesson from it and never to do this. (3) Competing access. This is an issue which was not addressed in D.H. Lawrence's letter. But we felt it of utter importance. If you have a distributed computing system, it will compete for network bandwith. Moreover probing and look-up will generate computing load even on those stations which are not used for idle time computing. In particular, any machine must be handle every broadcast it sees, even just to discard it. Competing communication load will be negligible for small sites. But it may become a major problem if the number of compute clients increases. If a distributed computing system does not address these problems, mere communication load may lead to a denial of service with increasing system size. NetWork takes three means to address this problem. (A) instead of using high overhead protocols like RPC, we use lightweight communcation - for UNIX, based on UDP - and have special techniques to reduce communication load, (B) we limit the additional bandwith taken up by the NetWork administrative system to an arbitrary fraction (1 per cent) of the bandwidth on the transport medium available, (C) we control and limit the global rate of broadcasts and multicasts used by NetWork. G. Sawitzki <gs@statlab.uni-heidelberg.de>
The following was reposted to comp.text from an original BIX newsgroup (ibm.utils/onions???). This is the first time I'd heard of such an elaborate scheme associated with shareware. I have not looked at the book yet, myself (perhaps I should be fore submitting a real posting to comp.risks), but even if the story is inaccurate, it bears passing on because it points out yet another possibilty in mistruth-in-advertising. In article <52928@cup.portal.com>, Lynlee@cup.portal.com (Linda Stefny Baum) writes: > From: Lynlee@cup.portal.com (Linda Stefny Baum) > Subject: Beware the THOUSAND DOLLAR BOOK. > Date: Fri, 17 Jan 92 17:07:10 PST > Organization: The Portal System (TM) > > The author of the following article has allowed me to repost his article IF > I did NOT post his name with it.. He is a BIX user.. The article was posted > to BIX. The Header info is complete with the exception of the authors name. > > TINAR = This is NOT a Review.. > ============================= Beginning =================================== > ibm.utils/onions #4290, from ------, 1245 chars, Mon Dec 30 00:45:24 1991 > There is/are comment(s) on this message. > -------------------------- > > TITLE: Beware the THOUSAND DOLLAR BOOK. (TINAR) > > "DOS Power Tools, Second Edition" looks a lot like the First Edition. The > price is $10 higher, but, why not? The first edition only had one disk, > containing a lot of useful, ready to run, PAID FOR, utilities, at $39.95. > This one's got THREE disks filled with "over 100 all-new utilties", at $49.95. > > I've had the book for a week, and I'm reading page 811. This is where the > author urges you to register shareware you use; it's the right thing to do. > > Sounds beautiful so far, what makes this an ONION? > > MOST OF the "100 ALL-NEW UTILITIES" with this $49.95 book are SHAREWARE! > 48 programs, by 7 authors, asking for a total of $925 in registration fees! > 18 additional programs ask to "call or write" to 5 more authors for prices. > If each "write for price" is only $25, the grand total is $1,375. Even if I > pay each author for ONE program, the total registrations would come to $242. > > On the covers, there's NO notice of the $1,375 shareware bargain inside. > This important information is on page 815 thru 965 of this 1070 page book. > > Bantam Computer Books, ISBN 0-553-35464-7. Down payment only $49.95. > Total price approximately $1,424.95. Postage and taxes not included. TINAR. > > ================================ END ======================================== > > Personally speaking, I feel this type of practice, if not illegal, is > unethical.. The first edition did not require the purchaser of the book to > pay large sums for the use of the Shareware included.. There was an > agreement with the publisher and the shareware authors For which, Im certain, > the authors were compensated for their labors.. I, for one, will not support > this type of tactic.... TINAR > Lynlee@cup.portal.com I agree with Linda, hence my forwarding this to comp.risks. Caveat Emptor and don't let them get away with it when despite your best efforts to prevent being taken, you are. Bill Putnam, INTERACTIVE Systems, 26635 W. Agoura Rd., Calabasas, CA 91302 A Kodak Company uunet!isc!ism!billp 818/880-1200 x2119
I recently needed to use my "prescription drug plan" employee benefits,
available to Maryland state employees. (This is in response to problems with
a flu virus rather than computer virus, as usually discussed in this forum.)
This presented my fever-ridden imagination with an interesting array of risks
due to a system that is substantially supported by computer.
The prescription drug plan in Maryland is contracted out to a separate company
called PCS, Inc. Our membership ID is, unfortunately, assigned by social
security number. All transactions in the system are recorded in a "PCS
databank", a centralized facility that is billed as being an important employee
safeguard, since it is intended to warn pharmacists when you are given some
conflicting medications. The obvious sorts of computer risks here have been
discussed previously — what if the databases' list of drug interactions is
not correctly recorded, what if the data being entered for a patient is mis-
entered or associated with another patient, etc.
But the fine print in our benefits contract reveals there is room for other
sorts of problems. We aren't given much in the way of promises concerning
accuracy of information ("... neither PCS nor your ... sponsor is responsible
for any damage or liability out of or in connection with the performance, or
failure to perform, ... services for you.") Neither are we given much in the
way of assurance concerning how information is to be used. Is PCS free to
decide someday to sell mailing lists based upon records? Or (more likely)
sanitized records? Send all those heart patients advertisements for the latest
Ronco CPR-o-matic! (And what if they mix it up and send diabetics those
chocolate ads really intended for folks with eating disorders....?) A longer
range issue, of course, is that this is one more way for the state to get
access to personal medical information. Want to custom-tailor a benefits
package to the employee? No problem --- just tap into the centralized medical
records and see what kinds of problems they'll likely have down the line.
(Let's see, this Purtilo guy is overweight, attitude-ridden and near-sighted...
better charge him the max for medical insurance. Now if we could only cross
reference the DNA mapping info in order to predict other diseases....) Entry
into this database is mandatory for any employee who uses the plan benefits.
This assumes you can use the benefits. The cough syrup I wanted to buy took
about 40 minutes to prepare. 10 of these minutes were due to waiting in line
and paperwork, 30 were due to the lab person fooling around at the computer
terminal. The pharamacist was not very open to gab about this, so I cannot
report on his perceptions concerning system reliability, but I got the distinct
impression that if they could not log in to the centralized facility, then I
could not buy the medication (under the plan). Moreover, since membership
cards are only issued in the employee's name, it is plausible that a valid user
might _not_ get medication at all: spouse goes with prescription and no cash,
expecting to get critical prescription filled under terms of the plan; computer
is down, denying verification of user [the card explicitly states that only the
user whose name is on the card can get benefits ... participating pharmacies
are told to overcome this problem for family members by checking in the
computer]; spouse has different last name than on card, so the pharmacy cannot
even honor the card based upon paper records; and spouse doesn't have the cash
to buy the medication (and hope the paperwork doesn't kill him or her later).
Jim (purtilo@cs.umd.edu)
All I know about the recently reported radiation therapy underdoses are what I read in RISKS. As usual, it is not possible to determine what actually happened from the news account. However, since I do work in a radiation therapy clinic, I can provide some general information. Doctors prescribe the radiation dose that is to be delivered to particular sites in the patient's body. Typically the prescription includes, in effect, a lower limit on the dose to the tumor and an upper limit on the dose to various healthy tissues such as the spinal cord, etc. Then a physicist or dosimetrist creates a treatment plan, including a geometric configuration of radiation sources (usually beams from a linear accelerator), and the amount of radiation to be delivered from each source. Because of the nature of the radiation producing machinery, and the physics of radiation absorption in the body, physics calculations are required to determine the machine settings needed to deliver the prescribed doses to the prescribed sites. Clinic staff usually use computer programs called "treatment planning programs" to perform some of these calculations. Usually, these programs produce a printed chart with instructions for setting up the treatment machines, including the total quantity of radiation to be delivered. The treatment planning computer system is usually a completely separate system from the therapy machines. Usually the information from the planning program must be manually entered into the control console for the therapy machine (whether or not the therapy machine itself is computer-controlled). Recently some vendors have produced treatment planning systems that allow some calculated machine setup information to be loaded directly into a (computer-controlled) treatment machine via some kind of network connection. All treatment planning programs depend on tables of data representing actual machine characteristics measured at the clinic. Clinic staff must measure this data and enter it into tables in the format required by the planning program. These days, the data is often collected with the aid of a semi-automated "beam scanner" that includes a small computer. This system is usually completely separate from both the therapy machine and the treatment planning system. Sometimes there are facilities for loading data from the scanner into the planning system via network, without having to type it in manually. In addition, the therapy machines themselves have calibrations that must be adjusted frequently by clinic staff. On some of the newer computer-controlled machines, a computer is involved in this process as well. Besides the therapy machine, the treatment planning system, and the beam scanner, clinics have other instruments that are used to calibrate the rest. I hope I have conveyed that there are many steps and stages where the clinic staff have the obligation to measure, record and update information that must be accurate and consistent. Computing is involved in many of these stages. There are many opportunites for errors, in particular there are many opportunities for dose delivery errors other than the therapy machine itself. Clinics must have quality assurance procedures in place to detect and correct the errors that do occur before they can affect patients. To me, the most alarming aspect of this recent story is that some kind of error was apparently allowed to remain uncorrected for years. One thing that is important to understand is that many clinics do not depend solely on stock equipment from vendors; some use quite elaborate procedures and instruments that are custom built by clinic staff. As part of this tradition, it has long been common to use custom computer programs written by clinic staff for treatment planning and other tasks. Many clinics that own and use commercially produced treatment planning systems and beam scanners also use locally-written programs for some special applications, or to act as pre-processors, post-processors or interfaces between purchased programs. Moreover, almost all commercial offerings are actually adaptations of systems that were originally developed by staff at some clinic to meet some local need. Quite often there is no clear distinction between "the physicist" or "the expert" and "the programmer". Many people who develop software that is used in radiation therapy clinics (including yours truly) also have clinical service duties, and their formal education often does not include specialization in computer science or software engineering. I don't believe this is necessarily a bad thing, but I think it is fair to say that the quality of the methods used and of the resulting products varies a great deal. - Jonathan Jacky, Department of Radiation Oncology, University of Washington
> [The Therac 25 case was one of OVERdoses being life critical. > It is appropriate to note that UNDERdoses may also be life critical. PGN] If a machine is expected to do it _right_ then people should have a way of monitoring whether or not the machine did it right. There should be some way of measuring what the machine is doing while it takes place. They could monitor the radiation and keep a record of what the patient actually received. These machines should be subjected to routine measurements and calibration checks to insure that they're doing what they should. The state department of weights and measures goes around and verifies that gas pumps and grocery scales are accurate. Shouldn't we expect that hospitals could do the same to their radiation machines? Any museum worth its salt has thermographs and humidigraphs all over the place, recording on paper the temperature and humidity next to their valuable relics. I'm sure that all of these buildings have central heat/AC/climate control. But they stil use separate measuring tools to verify the results of the automatic systems. Perhaps we're just seeing the "black box to solve all your problems" mentality in the buyers of these automated radiation machines. Or else it's another case of cost containment. Rick Smith, SCTC, Arden Hills, Minnesota.
<> With regard to computer risks in general:
<> I think it is time to establish licensing of software engineers, ...
Is it a meta-RISK that making such a controversial recommendation
(which has been beaten into the ground before) to such a large
audience is likely to flood PGN with responses to the point where he's
likely to ignore all of them?
Marc
> I think it is time to establish licensing of software engineers,...
I strongly disagree.
Licensure of most professions exists not to protect the public, but to restrict
entry into a field so as to artificially protect the wages of the professionals
belonging to the newly-formed guild. This concept of licensure goes back to
medieval times. One would think that we had advanced beyond feudal times, but
it appears that we have not. A recent cause celebre in Washington, DC has been
a hair salon fighting the districts strict cosmetologist licensing laws. You
heard me: licenses are required to style hair in Washington. The AMA has, via
its legal right to control accreditation of medical schools and licensure of
physicians, systematically reduced the supply of Doctors in our country, thus
driving up the price of health care. Lawyers manage every day to drive anyone
who is willing to help people fill out simple legal forms out of business with
lovely laws about practicing law without a license.
All of this is silly. There is little or no evidence that licensure
does anything other than creating a new protected class of people who
can jack up their fees arbitrarily because they can restrict entry
into their field. No studies or statistics exist to show that people
get better lawyers, cosmetologists, or even physicians, thanks to
licensing laws. However, in the absence of any substantive evidence
for quality improvements in the presense of licensure, people anxious
to run the lives of other people add hundreds of new protected classes
of people every year. Recently, the state of New Jersey created a new
protected class of food specialists. No one but a licensed dietitian
can pronounce your carrots nutritious these days; anyone else giving
out "dietary advice" can get their fannies whacked by the long arm of
the state licensing board.
Even if government licensing could increase safety, the costs involved would
have to be considered. Just as safety could be enhanced by forcing all cars to
travel under 10 MPH, but needed productive uses of automobiles would then be
eliminated, government licensing could drastically increase the costs of
software development without a commensurate improvement in safety.
Government is a fearsome weapon, and rarely a useful tool. I think of it in the
"guilty until proven innocent" category. Until someone can present clear and
sound evidence that licensure of software engineers has actually dropped the
number of dangerous product failures, without incurring excessive costs to
society, I will oppose the concept.
Perry Metzger
>I think it is time to establish licensing of software engineers,... I might agree with this in theory, but want to point out that licensing and review boards are not silver bullets, to borrow a phrase from Fred Brooks' recent article in "Computer". The history of civil/mechanical/electrical engineering is replete with examples of disastrous projects designed by appropriately trained and licensed engineers, and approved by suitably experienced review boards. I'm not sure the situation would be any different for software engineering; we just might feel better about the issue if licensing and boards existed. >Many programmers of such systems have no knowledge whatsoever of the techniques >of reliable programming. They were the scientist, or expert, or whatever on the >object under software control, and were chosen to write the program because >they could hack out something that worked. Sometimes they're chosen because they're the only person available who understands the entire task at hand. I wrote some of the firmware that controls the X-ray tube gantry in the Omnimedical Quad-One CT scanner; I was selected because I understood something about X-ray tubes, stepper motors, power control circuitry, real-time software, 6809 assembler, sliding-ring mechanics, and gate-level TTL circuit design. A person with a better background in software engineering almost certainly would have written better code — but they may not have understood the electromechanical aspects of the system as well as I did. >Consequently, they turn out spaghetti. Well, sometimes they turn out spaghetti, and sometimes they do a pretty good job of organizing the code into something that's robust, testable, and maintainable. But "they" may turn out to be software engineering graduates or medical physics specialists — and it's hard to tell which by looking at their code. ---Rsk rsk@gynko.circ.upenn.edu Cardiothoracic Imaging Research Center
Please report problems with the web pages to the maintainer