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…
INTERFERENCE WITH MEDICAL DEVICES
There is an article on the effects of interference on medical devices,
``Electromagnetic interference and medical devices'', *Health Letter*,
Public Citizen Health Research Group, 12, 6, June 1996, pp, 6-7. Apnea
monitors have failed to sound the alarm when patients have stopped
breathing. At least one implanted defibrillator has failed, responding to
EMI and delivering a shock to a normally functioning heart. Power
wheelchairs have also been affected. The greatest risk still appears to be
implanted heart pacemakers, for which various problems are included in the
RISKS archives. EMI is particularly problematic in hospitals, where
sensitive monitors converge with radiating equipment (e.g., high-frequency
generators and electrosurgical, diathermy, MRI, and x-ray machines).
Cellular telephones are also a serious concern as emitters. Wireless
technologies are likely to make things worse.
The July 1996 issue of *Health Letter* summarizes the reports of two more
recent studies on the effects of cellular phones on pacemakers. In the
first study, tests of analog phones (90% of today's cellular phones) showed
minimal interference (3% of the time), while *all* of the digital phones
caused some level of interference. In the second study, 30 types of
pacemakers were tested. Motorola's MIRS (used in foreign markets) caused
EMI in 36% of those pacemakers within 3.5 inches or less. North American
Digital Cellular phones interacted with 10% of the pacemakers within 1.5
inches.
MISCELLANEOUS MEDICAL DEVICE SOFTWARE PROBLEM
Incidentally, the September 1996 issue of *Health Letter* notes a Class II
recall of 7200-series microprocessor ventilators (in particular, 7200ae, e,
and sp with certain serial numbers, 8402 in all), which can stop operating
when they are first turned on — due to defective software. The
manufacturer is Nellcor Puritan Bennett, Carlsbad CA, 1-800-255-6773. (2987
units of the model 7200 are also being recalled because of a defective
transducer that causes it to stop ventilation for certain data-dependent
settings.)
INTERFERENCE WITH AIRPLANES
There is an excellent article on the effects of electromagnetic inference on
airplanes: Tekla S. Perry and Linda Geppert, ``Do portable electronics
endanger flights? The evidence mounts'', *IEEE Spectrum*, September 1996,
pp. 26-33. Check it out. I learned a lot.
[ham@cs.utexas.edu (Hamilton Richards Jr.) summarized the *Spectrum*
article as follows:
The risk that RF emissions from carry-on electronic devices will affect
avionics, although not high, is still high enough to warrant tougher
government regulations.]
A copy of the warning letter crossed my display on 11 Sep 1996, and
immediately triggered the feeling of don't trust the information without
checking (the multiple levels of quoting by the time it got to my desk for
instance). So, I decided to do some checking using alta vista and dejanews.
One of the first things I discovered was that the product in question is not
called ptrax (though Lotus produces something with that name) but rather
P-Trak and that warnings first went out in early June about it.[1] Before
that time Social Security Numbers were visible, afterwards they weren't
though they were still in the database. I also found the description of the
product (date unknown, but I think June of this year).
http://www.lexis-nexis.com/lncc/products/media/issue396.html
Lexis-Nexis also seems to have put the following up within the last day
or so:
http://www.lexis-nexis.com/lncc/about/ptrak.html
I also noted that the database lists the person's maiden name (not the
person's mother's maiden name, as stated in the warning message), though
given a large enough database a searcher might be able to figure out your
mother's maiden name. [It is also typically on your birth certificate,
which is public-record stuff. PGN]
Risks: Most of us seem to have accepted the message without much checking as
even the simplest check should have turned up the correct spelling of the
product name (though admittedly by phone p-trak and ptrax could sound the
same). In this case, most of the information was correct — but will this
always be true?
Emma Pease
[1] See http://www.epic.org/alert/EPIC_Alert_3.12.txt (The Electronic
Privacy Information Center, June 25th newsletter). See also C-Net
http://www.cnet.com/Content/News/Files/0,16,1527,00.html
http://www.cnet.com/Content/News/Files/0,16,1539,00.html
for some articles on the matter in June.
[There are lots of items on this subject in today's media. Also,
sidney markowitz <sidney@research.apple.com> notes the web address of
<http://www.lexis-nexis.com/lncc/p-trak/p-trak.html>
has a form to fill in and submit on-line, to remove yourself. PGN]
Official statement form MR.Net, 16 Sep 1996, sent to a technical list: > InternetMCI's network experienced periodic outages on national scale from > approximately 3:30am til 10:00pm CDT yesterday. The effects of the outage > were not uniform network wide. MRNet was one of the harder hit, CICNet and > NorthWestNet were also badly hit. The Seattle area seems to be the hardest > hit. Some InternetMCI customers are said to have seen nothing but slow > downs. At one point the BGP routing to several of NAPs were affected. > The outage was caused by a bug in Cisco routers that was triggered certain > network events. The nature of these events and why they have not shown up > until now has not been determined. InternetMCI is still investigating all > the data gathered from the failure, until this is complete nothing is > being suggested or ruled out." [swb@mercury.campbell-mithun.com (Shawn Barnhart) updates Ted's R-18.46 message, noting that *not all* of Minnesota gets its connection through MR.Net — Minn-Net and at least one other use uu.net. PGN]
We at U of M were disconnected from the world for more than 12 hours. Starting at ~5am on Sunday the 15th, MCI was upgrading their routers. The engineer I talked to at the the MCI NOC said that something went wrong during the upgrade and all the software (I'm not sure if it was the actual software, or the routing information) was fried. Our connectivity to the Internet was pretty much gone at that point ... some of MCINet's peerings worked as we could get to msn.com, but not to microsoft.com. To compound problems, at about the same time, PSINet lost two of their BGP routers at MAE-East & MAE-West. This affected me since many of my customers & our corporate network are on PSINet, so I couldn't get to PSINet from MCINet (actually, mich.net, the academic ISP for Michigan) since their peering was at MAE-East.[*] By Monday morning all was resolved, including PSINet's problems. Happy ending to a bad weekend for the 'net, but at least the engineer I talked to at MCINet was able to joke about it. Jeremie Kass, Information Technology Consultant, Ciara Systems, Inc. University of Michigan jeremie@umich.edu * jeremie@ciaraweb.com [* I would have thought they were peering at MAE-West. You know, "Come up and C(++) me some time." PGN]
Reading the article written by John Vert <jvert@MICROSOFT.com> and then the two cited KB [Knowledge Base] pages it strikes me that the real RISK is the complexity of the software offered by Microsoft. It is difficult to use many of the Microsoft API's because the things they act on are inherently complex. Often, to do a 'simple' thing you have to call multiple APIs and many of these have a non-trivial number of arguments and/or must be passed complex data structures. In many cases these parameters set to 'defaults', so why have them in the first place? In any case, just how can all the combinations be tested? This situation is made worse by the incomprehensible documentation. I find that his article and the KBs verge on the incomprehensible. This is rampant through Microsoft documentation. I'm a University educated, native English speaker with 12 years in computing and much of the Microsoft documentation contains semantic contradictions, before it even gets to the technical level. At the technical level one wonders why anyone would design it they way it was designed [writing on a read-only object being permitting based on some perverse set of rules]. Combined with the confusing nature of the documentation you are left wondering if how you thought it worked is actually how it does work. Sometimes, as a last, turgid, resort you just have to try it out and see how it does work and hope that you are using it in the way it was intended and in the right context. This is no way to write software. I don't want to hope that it works. I want to know that it works. Looking at Windows 95 I see something that is maybe an order of magnitude more complicated than Windows 3.1, still only solving the same problem. Doing the same with more is not progress. Exploiting Moore's Law may be possible, but it's not desirable.
Late last Monday night an interesting sight met me when I went to get cash from an ATM. These ATMs come with a small color screen a numeric keypad with a cancel and an ok key, and 8 keys next to the screen. Normally you are first prompted to insert your card and type in your key, after which you are presented with a graphical menu allowing you to redraw money, check your account balance change your PIN or retrieve your card. This time things were different. First the person in front of me left the ATM cursing loudly. When I got there, instead of the graphical menu the screen was black with characters in white, several lines of "bad command or filename" ending on a "C:\exe>" prompt. After a little experimenting I found the keys 0-9 were mapped, as expected, to 0-9, while the OK key was mapped to <ret> and the CORRECT key was mapped to <del>. The keys next to the screen (of which there were 8) turned out to be mapped to A,B,C,D,.,<esc> respectively, with the 2 last keys apparently doing nothing. Since I didn't have a full keyboard, and lacked an <alt> key I couldn't enter anything useful, so after some brief experimenting I left it alone. I then called the banks 24 hour hot-line and told them their ATM needed rebooting. I got a rather vague response along the lines of "oh well just wait a few minutes and see". The risks ? Well where should I start... 1) It should never be possible for the user of an ATM to access it's operating system (if ms-dos + win 3.11 was the operating system, if not it shouldn't be possible to access to front-end either). 2) More to the point it shouldn't be possible to use anything but the authentication program prior to authentication. Note that during my experimenting with the ATM I hadn't put my card in. 3) I had always assumed that ATMs ran some kind of well designed embedded system. "Well designed" doesn't come to mind when talking about ms-dos. I am on the other hand certain that a pc with dos/windows is the cheapest way of building an ATM (cheap standard components, lots of programmers available for the platform, cheap standard tools available for development). What does this say about the general quality of the information resources used by this bank ? 4) Does the bank ever run virus-scanners on the pc in the ATM ? Having one of these things infected could lead to all kinds of problems. Of course virus-scanners are never 100% reliable. Seeing the problems these machines seem to have, it is only fair for me to report one occasion recently when my local ATM got something right: On requesting a certain amount of money, the ATM always hands your card back first, and then hands you the money. Last week my card jammed in the ATM and I got neither card nor money. I went to the local branch of my bank immediately, expecting to find the money I hadn't received deducted from my account, but apparently it hadn't been, indicating that at least this time the designers of said ATM got things right. Rory Chisholm rchishol@math.ethz.ch
My family and I have just recently returned from a year's assignment overseas and have moved back into our old house, which we rented out for the year. Of course, we gave up our old telephone number (though I kept my e-mail address — first things first!). When we returned this year, it was easy to get a new phone number; they still had my old account information handy. We've been gradually re-establishing contact with our friends. This week, two old friends told me that they'd been trying to call me, but that the number information gave them was "not taking calls at this time". I asked what number it was, and they told me our *old* number from last year! I called information (411 for local information) myself, and was given the correct number. I asked one of them to check again; again she was given our old number. She tried to explain that she KNEW it was the wrong number, and was told the equivalent of "Sorry, lady, that's what the computer says." She had dialed 555-1212 (the standard for non-local information questions) I called NYNEX service to ask what was going on. She checked the records -- they were correct. With me on the line, she called 555-1212 and was given the right number. She explained — reasonably — that she couldn't fix a problem that didn't seem to exist. My friend tried again. Was again given the wrong number. She then explained, again, that the records were wrong. At my request, she asked for the information on exactly which company she was talking to and where they got their data. She explained that they were contractors for NYNEX, Then she asked my friend for the correct information so she could change it! The RISKS? The usuals: a) Assuming that old data is good data; somebody somewhere seems to have decided that the same name at the same address must have the same number. b) Changing the data without having any proof at all that the new data is valid or that the change is authorized. Can you imagine someone doing this to a competitor? It was awfully easy. c) Our assumptions that there is somehow, somewhere, God's database of telephone numbers managed and maintained by The Almighty Telephone Company, and that changes propagate intelligently. 'Taint so, folks. So, I THINK that my phone number is now correctly stored in the information systems --- unless it gets overwritten by some other glitch somewhere else. I guess I have to keep testing it for a while. Kent Quirk, Acton, MA, USA kentq@world.std.com Phone: Call information ... if you dare.
The *Baltimore Sun* reports in its 17 Sep 1996 issue that people in Baltimore are paying for drugs with meat (page A1! [pretty saucy!]). Perhaps this is not yet anonymous digital cash, but certainly anonymous. [Now someone is going to propose keeping a database of all sides of beef, and steganographically watermarking the meat in the context of digitally signed scannable grade-stamps. Perhaps the next step in monitoring the private drug-meat trade would be to escrow the inspectors' private keys, derived from the product of two U.S. Primes, and put the database up on the net: the T-bone connected to the M-bone, etc.? PGN]
Dave Schulman's recent contribution ("Failure-mode risks revealed by
Hurricane Fran" RISKS-18.42) reminded me of an incident that happened to me
a little while ago. Back in December 1995, I was interviewing for a
residency position at a hospital in Toledo, and the hospital was being
generous enough to put its applicants up in one of the better hotels in the
city (which shall remain nameless).
The hotel had recently changed over to an electronic card system on their
doors rather that the traditional lock and key system. The morning of my
interview, I was coming back from breakfast, and was planning to get my
suit jacket from my room and check out. When I got to my room, I inserted
the keycard into the lock and, instead of getting the green LED and hearing
the mechanism unlocking, I was greeted with a series of all three LED's
blinking, in what I assume was an error code.
I went to the front desk and explained my situation to the manager who got
the 'master key' card and tried it in my lock, and got the same response as
my key. She went back to the front desk and put in a call to maintenance.
A few minutes later, the maintenance man showed up with what was supposed to
be a supermaster card. No dice, same result.
He went away and returned after a long wait with two other keycards. (He
said that it took a while for him to get in touch with his supervisor who
gave him some 'special codes'). He tried the two cards in the lock; they
obviously did something since the LED's blinking pattern changed, but the
lock still wouldn't open.
He went away again, and he then returned along with the manager and two
other people. The manager pulled out a laptop computer connected to a
probe which fit into the keycard slot. While she was working, one of the
two other people identified herself as the 'head concierge' and began
furiously apologizing to me. The manager did succeed in opening the lock
this time.
This anecdote illustrates a risk touched upon be Mr. Schulman — the
problems with not including a manual override in a computer controlled
system. Had the laptop computer not been able to convince the lock to
open, I don't know of any way short of brute force of getting the door open
as there were no openings in the lock other than the keycard slot. (During
the times I was left waiting in the hallway, I was half expecting the
maintenance man to return with a sledgehammer).
Although I'm not intimately familiar with the internal workings of
electronic locks, I don't believe that it would be a problem to include a
conventional mechanical keyway in the lock. In the ideal system, the
mechanical keys would be kept secure (say, in a safe in the office) and only
the electronic cards would be given to guests. This would keep the
advantages of the electronic locks (convenience, the ability to change locks
easily whenever a guest leaves) without having to keep track of mechanical
keys.
Bill Hutchens wthutchens@usa.pipeline.com
I must take exception to most of what Dave states here. I'm a life-time resident of North Carolina, and have lived in the described area (Research Triangle Park) in central NC for twenty years. >The area was clearly unprepared for a disaster of this magnitude, ... Was Florida prepared for Homestead? [>...] 1) Raleigh-Durham is over 100 miles inland from the coast. Hurricanes rarely effect the area with more than peripheral tropical-storm-type weather. Fran was a major exception to the rule. Flooding along the rivers and lakes here qualified as "200-year flood" waters, meaning that you should expect floods of this type only once every 200 years. Normal civil engineering for building sites relies on meeting the "100 year flood" limit in most cases. 2) Power lines are aerial still throughout much of Raleigh because Raleigh has been here a long time. It is impractical to bury all of the power lines due to the sheer number of miles of cable involved. Most subdivisions and other developments built in the last 15 years do have underground utilities. In Cary nearby, building codes require it. 3) The central NC area is covered in trees. Many of the streets in the area, particularly older parts of town, have large oaks with canopies extending over the streets. The trees are one of the things that gives the area its charm. Most widespread power outages were caused by the downing of high-tension distribution lines. More importantly, several gas leaks resulted from uprooted trees pulling lines UP out of the ground, so burial is far from a cure-all. Major trees are down throughout the central NC area. The storm had sustained winds of 67 mph in Raleigh, with gusts of up to 117mph. Remember, this is over 100 miles inland... [>...] The telling point: "where hurricanes are an established fact of life." Much of Florida's vegetation is tropical, which is suited to severe winds and storms. In contrast, Raleigh is known as the City of Oaks. Many of those trees are over 300 years old. Many are uprooted or broken apart now. Many power lines did come down. A week later, most people living in municipalities have power restored. While inconvenient, I can deal with a week of no power if the alternative is to cut down all of the trees anywhere near a power line. In the hurricane aftermath at Homestead, FL, some people didn't have power for months. [>...] Having a sole entrance gate that fails closed is stupid, but not particularly unsafe. Virtually all mechanical entrance gates are designed with shear pins in the mechanism. In the event of fire, the fire department simply drives through the closed gates, that's what those big bumpers are for. Most municipalities here will not allow you to build a subdivision or apartment complex with only one entrance. A tree could have blocked said entrance just as easily as the closed gate. Now compare this with the alarm system my neighbor's place of work has. He went to work to check on things in the aftermath of the storm. It turns out that after the backup battery on their system wears out (approx. 3 hours), the system OPENs all of the locks on the doors. Note that typical card-key-locked doors have a manual handle on the inside to open the door anyway if power is off, in addition to a mechanical key for entrance, so the risks of being locked in or out are minimal. In his case, NOBODY was locked out. Just what you need in the aftermath of a storm, when the opportunists are about. [>...] It's a near miracle that more people didn't die, but it has nothing to do with the utilities. The height of the storm was at approx. 3:00 AM, so most people were at home. The eye of the hurricane went directly over Cary, approximately 7 miles west of Raleigh. Carolina Power & Light and Duke Power both scrambled to obtain line crews from other regional utilities even before the storm had gone through the area. They have reciprocal agreements with other utilities to supply crews in the event of an emergency of this nature. Everyone actually expected the problems to occur along the coast. BellSouth sent their generating units there to maintain power on their cellular towers. They were dismayed to find that the problems occurred exactly where they had just dispatched their crews from... While there was extensive damage at the coast, the major damage was actually inland. Wake County alone has estimated damage in excess of 900 million dollars. Steve Holzworth SAS Institute Open Systems Cary, N.C. R&D VMS/MAC/UNIX sch@unx.sas.com
ARIANE 5 Flight 501 Failure, Report by the Inquiry Board, The Chairman of the Board : Prof. J. L. Lions is in fact available (in English) as http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html It is not that long, and explains that the proximate fault was a conversion of a 64-bit float to a 16-bit integer. [See RISKS-18.27,28,29,45. PGN] "The internal SRI [inertial reference system, en francais] software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. " The circumstances surrounding the code, testing, simulation, etc., are probably worth reading, though the suggestions as to how to prevent such problems in the future are mostly nontechnical, and where they are technical, do not provide any great insight, unfortunately. Richard Fateman, UC Berkeley
The third International Conference on Ethical Issues of Information
Technology, University of Salamanca in Madrid, Spain
Two international conferences have been held which address these issues. The
first was in the USA at Southern Connecticut State University and the
second, ETHICOMP95 was at De Montfort University in the UK. Both conferences
have been recognised as milestones in furthering the study and understanding
of the societal and ethical issues of IT. ETHICOMP96 brings together leading
international speakers to debate the current and future impact of IT and the
societal and ethical issues consequently raised. Madrid is an ideal location
for this conference as it is a major European capital with a high cultural,
academic and commercial reputation.
* Keynote Speakers
Professor James Moor, Dartmouth College, USA
Reason, Relativity and Responsibility in Computer Ethics
Professor Porfirio Barroso, University of Salamanca in Madrid,
A European dimension to codes of ethics for the computer profession
* A. Organisation and society structure and the location of work
* B. Privacy, property and computer misuse
* C. Value and accuracy of data and information
* D. Developing information systems now and in the future
* E. The IT Profession
* F. Education
* G. Frameworks
Conference Administrator, Maria Angeles Nevado
Conference Chairman, Porfirio Barroso
Contact address: Porfirio Barroso (ETHICOMP96), Clinica Puerta de Hierro,
San Martin de Porres 4, 28035 Madrid, Spain
Telephone and Fax: +34 1 3866775
(To send a fax when you hear the answer machine press START)
E-mail pbarroso@capilla.cph.es
To directly reach the ETHICOMP96 Homepage:
http://www.cms.dmu.ac.uk/CCSR/ccsr/conf/ethicomp/ethicomp96.html
[Centre for Computing and Social Responsibility, Dept of Computer Science,
De Montfort University, The Gateway, LEICESTER, UK LE1 9BH ccsr@dmu.ac.uk
http://www.cms.dmu.ac.uk/CCSR/ ] [This item excerpted for RISKS.]
Please report problems with the web pages to the maintainer