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…
Greetings. Can you trust that messages sent via AT&T Wireless PCS Text Messaging will always be reliably processed and received? Unfortunately, the answer appears to be no. What's worse, when failures do occur, there may be absolutely no indication to the sender of the message that their communication has vanished into the ether. An an example of a serious risk associated with a more general class of modern, widely-used communications systems, I believe that this is worthy of a detailed explanation and significant concern. The use of text paging directly to digital/PCS cellular phones is rapidly replacing the use of conventional numeric and text pagers. Such phone-based text messaging, actually called "SMS" (Short Messaging Service) has a number of advantages over older paging systems. One of its biggest benefits is that the network will normally store messages for some extended period of time (e.g. 72 hours) for delivery to the phone, if the target phone is off or out of range. When the phone again is available, the message is delivered, and the network receives confirmation that the message was successfully delivered to the phone. SMS messages typically can range between 110 and 150 characters or so, depending on how they are submitted and various formatting considerations. The usefulness of SMS has caused an explosion in its use for all manner of free and pay information and warning systems, where automated systems will send messages (usually via an Internet e-mail interface provided by the wireless carriers) to users. Such messages could be anything from critical status messages for system support or medical personnel, to news bulletins and stock price warnings to traders. But how useful is the entire environment if you cannot depend on messages ever actually being delivered, and if messages can vanish into a "black hole" without any warning? AT&T Wireless (ATTWS) has, as you might expect, one of the most extensive SMS implementations. They provide three interfaces to the service: * a web-based "form" interface: type in your message and hit send * a direct dialup interface for specialized text paging software's use * an Internet e-mail interface: messages are sent to <cellular-number>@http://www.vortex.com; "Vortex Daily Reality Report & Unreality Trivia Quiz" http://www.vortex.com/reality
Hunter Godfrey is quoted as saying that EverQuest "is the digital version of crack." He has spent over 656 hours on the game in about four months, the equivalent of 82 8-hour days. There are over 150,000 players ``hunting monsters, collecting loot, and forging alliances in MUD world.' [Source: Noah Shachtman, EverQuest: the Latest Addiction, Wired Digital, 29 Jul 1999; PGN-ed] [Watch out for network congestion on corporate systems when this infiltrates workplace networks. M.E. Kabay, PhD, CISSP / Director of Education R&D Group / ICSA Labs <http://www.icsa.net>]
The U.S. 7th Circuit Court of Appeals is peeved at Microsoft. Seems as though unlike WordPerfect, MS Word doesn't count properly footnotes, and lawyers doing wordcounts have been running over length limits on briefs. Naughty, naughty, say the judges, who kvetch: that MS "ought to make it possible to obtain a count of words in footnotes attached to selected text." The august three-judge panel has forwarded a copy of its design recommendations to Redmond. More info in a Wired News story (4 Aug 1999): http://www.wired.com/news/news/politics/story/21096.html -Declan
All human activities entail risk. Indeed, to live is to take risks. In the medical realm, patients who undergo anesthesia and surgery are frequently concerned about the risks involved, such as the risk of *not waking up* (or as one patient put it, *waking up dead*). The risk of death or brain damage to patients undergoing general anesthesia is remarkably low, particularly for healthy patients in modern hospitals. When an accident does occur, its cause is often an error made by the anesthesiologist, either in triggering the accident sequence, or failing to take timely corrective action. The overall risk of death for general anesthesia in all comers is in the range of 1 in 10,000, the exact estimate depending on how one separates anesthesia misadventures (such as airway problems) from surgical misadventures (such as accidentally avulsing an artery). Risks for individuals with specific conditions are sometimes known, but usually not. For example, administering general anesthesia when a patient still has residual food in his stomach poses special risks since the food sometimes ends up in the lungs (known as aspiration), with consequences ranging from trivial to deadly. However, risk data specific to any patient in this situation are not yet available. For instance, factors such as the "state of the anesthesiologist", characterized in terms of alertness, vigilance, and competence, would also be important. (Of course, anesthesiologists employ a few good tricks to reduce aspiration risk. One trick that is not generally used would be to suck out all the food under visual guidance using a gastroscope. However, this procedure in itself introduces new risks and is at best unpleasant in the awake patient.) Some individuals are surprised to learn that in a great many situations (indeed, in most complicated clinical situations) the risks of anesthesia or surgery may not be even approximately known (as in known to within an order of magnitude). No algorithm yet exists that one can use to get quantitative risk estimates for all situations. An example illustrates the point. Recently I was asked to give an anesthetic for a man with several serious heart problems, the most pressing being a chaotic heart rhythm known as atrial fibrillation, which the heart doctors planned to fix with a big electric shock to the chest under general anesthesia (cardioversion). Once atrial fibrillation has started, it must be fixed within 48 hours or it will be necessary to start anticoagulant therapy (administration of *blood thinners*) to reduce the risk of a stroke. We had about 30 hours left. Because of concerns about harming the patient with a general anesthetic I initially recommended against the cardioversion (electric shock) procedure, viewing drug therapy to be a clearly safer alternative. The trouble with drug therapy, however, is that it is far less effective and in addition requires a much longer hospital stay. In other words, cardioversion was by far the quickest and more cost-effective choice, although drug therapy appeared to be the safer choice. But the final twist that lead us to go for the cardioversion was that the cardiologist pointed out that if drug therapy turned out to ineffective in this individual by the end of the 48 hour window, the option of subsequent cardioversion could not again be exercised until 4 weeks of anticoagulant therapy had passed. The risks (such as the risk of bleeding) and costs associated with that option now made cardioversion seem more attractive. The unique nature of this particular patient's problem list meant that any risk estimates from the literature would almost certainly be meaningless. It was therefore necessary to rely on judgement drawn from experience rather than formal risk data. Perceived risk must substitute for actual risk in many settings. D. John Doyle MD PhD FRCPC, University of Toronto and Toronto General Hospital djdoyle@home.com http://doyle.ibme.utoronto.ca APPENDIX The proposed drug therapy was intravenous amiodarone. Medical conditions included: recent myocardial infarct with impaired ventricular function, aortic stenosis, atrial fibrillation, gastroesophageal reflux (a *full stomach* equivalent situation.) The patient was also known to be very difficult to intubate because of a small chin! Finally, note that moderately reliable mortality estimates for multi-organ failure patients in Intensive Care Units can be obtained by using the APACHE II algorithm; this is one of the few situations where good risk data exist for complicated patients.
Risks readers may be interested in an article by Andrew Leonard in the online magazine, Salon, on the risks (and potential advantages) of open-source medical software: <http://www.salonmagazine.com/tech/feature/1999/08/05/anesthesia/index.html> "When he isn't in the operating room taking care of patients, [Dr. Stefan] Harms is hacking on the five computers in his basement. And he thinks he knows how to achieve his dream of low-cost, reliable anesthesia software -- by going the open-source </tech/special/opensource/> route. Last year, Harms founded LAMDI, <http://gasnet.med.yale.edu/lamdi/> the Linux Anesthesia Modular Device Interface. Harms thinks that the open-source software development model, in which the source code to a program is made freely available to the general public for redistribution and modification, offers fruitful possibilities for addressing anesthesiological software needs. ... "The obstacles faced by Harms in his quest for open-source anesthesia software suggest that there are some serious potential limits for the open-source software model. The experience of some medical programmers who have placed their code in the public domain indicates that open source is certainly no panacea for the problems faced by medical practitioners. But there are still some intriguing possibilities. If liability issues can be addressed, and if the peer-review component embedded in open-source software can be proven to result in pragmatically better software, then, suggest some open-source enthusiasts, wouldn't it be our duty to proceed down the open-source road?" (Transcribed by Martin Minow, minow@pobox.com, with apologies for any residual Windows formatting cleverness)
In RISKS-20.51, concerns were raised over http://www.imrss.org, their ongoing automated search for open mail relays, and the publicly accessible query database of the resulting data which they maintain. It was suggested that such a database might actually help spammers find potential relay targets. I was also concerned about this, and sent them e-mail asking for clarification on a number of related issues. After several attempts (they have various automated responders I had to deal with) I was quickly rewarded with a phone call from Ron Guilmette, who runs IMRSS. We had a long and friendly chat. While my own orientation towards fighting SPAM is different than his, and I do not agree with various aspects of his operation, I think it's worth noting that he seems quite level-headed and sincere, and clearly has a lot of experience in the real world of SPAM problems. Also, they are apparently about to address one of the more serious criticisms of their procedures, by beginning a program to attempt to send notification messages to "postmaster" and/or related addresses (when these exist!) for sites where open relays are found. This will at least provide such sites with an early warning that they were found to have an open mail relay, and that they were added to the IMRSS database. Lauren Weinstein, Moderator, PRIVACY Forum http://www.vortex.com Member, ACM Committee on Computers and Public Policy
Well the joy and risk of high-tech toilet! It must have been quite an amusing and hilarious way to really wake up to hear the interview on NPR (National Public Radio?). And many seem to think that the Japanese is too serious a nation without the proper sense of humour, but I digress. The case, eh, the toilet in question was an 18 years old toilet that caused a minor fire in April this year (1999). The cause seems to be a trouble in electrical wiring due to leaking water. Trying web search engines with "toilet fire" in Japanese didn't turn out useful pages at all. Below is what I gleaned from an article at Mainichi Shimbun newspaper site (in Japanese). By the way, fires believed to be caused by similar toilets were reported in October last year (1998), and July 1993. The fire in April this year was believed to have happened in the the following manner. The plastic vinyl water pipe (for supplying heated water, I think) degraded and water began seeping. The water caused the temperature sensor to get rusty. The rust caused the electrical resistance of some electrical contacts to go up much higher than it was supposed to be and thus the excessive heat was generated. Finally, the vinyl coating of the electrical wires caught fire. The family members had noticed the little water seepage about half a year earlier, but did nothing since the basic functions of the toilet such as heater, etc. were still operational. Many such toilets, of which life time the manufacturers say is about 7 years, are believed to be used in Japan. The fire fighting department of Tokyo government was quoted as saying that such toilets that outlived the warranty period ought to be checked early. (I could not find reference to the toilet at the fire-fighting dept. web site, though.) In Japan, these type of toilets showed up in the market early 1980's. Today, about third of such toilets are this type according to a survey mentioned in the article. Personally, it was shocking and amusing to find the toilets of this type when my office moved to a new building about 10 years ago. Being a gadget-interested person as I am, I tweaked the "control" myself. The reported toilets that have seat raise control must be the "Rolls Royce" of this type of toilets. The one at the office doesn't have such a luxury so to speak. Frankly speaking, I doubt if such toilets do exist: we need hydraulic piston or something for that, don't we? In a toilet? Anyway, even the Mainichi article had to have a cute headline talking about this subject: it goes something like "Many fires by toilet: it smells and your bottom is on fire!" Oh well. It was a good thing that the interview was not aired on April first. Nobody would have taken it seriously in USA. Risks? We probably should not put electrical circuits unless absolutely necessary. Toilets are not thought of as the cause of fire at least by many. Of course, run-away faulty microprocessor or whatever will get you in a real trouble such as minor burn! Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam Personal Media Corp., Shinagawa, Tokyo, Japan 142-0051
> ... Some of these have recently been implicated as a source of fires ... I was pleased to get the above explanation of at least some of the electronic controls on these toilets. Such controls are, not surprisingly a feature in the advanced research laboratory that I've visited regularly in Japan these last few years - one that I made a point of photographing for my unbelieving colleagues back here in the UK. I had hinted to my hosts that I would appreciate English language instructions or even a manual, so as to understand the multiple buttons, keyboards, and digital displays (including of dates and times) - but neither were forthcoming. However, they did accept the possible validity of my concern that these toilets might well not be Y2K compatible - and we had some interesting speculations as to the likely forms and seriousness of the possible consequences! :-) Brian Randell, Dept. of Computing Science, Univ. of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk +44 191 222 7923
My wife and I went into a department store in Tokyo and she visited the toilet. When she came out she was soaked and she couldn't stop laughing. After she'd used the toilet (and used it well) she went to flush it and discovered a row of pushbuttons with Kanji labels. Not wanting to leave the toilet in an unsuitable state for the next user, and not reading Kanji, she stood back as far as she could from the toilet and pressed one of the buttons. Hot air started to blow up from the bowl. She tried the next button, and got sprayed with water. Luckily it was winter and she was wearing a raincoat. The other buttons didn't seem to do much at all, perhaps adjust the temperature of the toilet seat or something. None of them caused the toilet to flush. So she gave up, turned to the washbowl (in the cubicle with the toilet, as they often are in Japan). When she turned the tap on, the toilet flushed. A good design. And the Japanese are so fond of cute icons. It's a pity no one thought about the illiterate. Colin Sutton, Development Manager, Siemens Building Technologies Pty. Ltd. 14-18 Suakin Street, Pymble NSW 2073 Australia +61 2 98551310 [What about the ill-litter-rate? PGN]
A few miscellaneous risks from recent risks issues: 1. Risk of not explicitly stating the risk. Marshall Lindsay wrote of the "Conversion service for viewable formats." Our Esteemed Moderator wrote: "But, security by obscurity does not work too well for strange formats." This suggests to me that perhaps the risk that Mr. Lindsay was referring to wasn't sufficiently clear. The risk is not that formats are decoded; but rather, that the people supplying the conversion service could readily make a copy of every document passing through their translation service. Sooner or later they are likely to acquire plenty of interesting information! 2. Risk of promoting silver bullets. M. Simon wrote a couple of articles; one teaser and one sort-of real article, promoting the FORTH programming language. First of all, the "teaser" article should *never* have been printed in RISKS. It contained no actual information; it was just a shameless plug for something that wasn't even named. Second, as I hope all RISKS readers know, there is no "silver bullet" to the programming challenges facing us, and this article certainly promotes FORTH as just that. Third, I've used FORTH, and it is a lovely little language, but I think that it's a particularly poor candidate for such a silver bullet if one were to exist at all. First of all, by its very nature it does not support static error checking. It completely lacks the concept of a "type" which renders its ability to do even run-time error checking very limited. It is great for small projects and for controlling real-world objects. (Controlling telescopes, for example; the application for which was originally designed.) I cannot even begin to imagine managing a large (hundreds of programmers) project with it, and I do not believe that a project that takes hundreds of C or Java programmers could be done with a mere dozen FORTH programmers, either. (Though a project that takes a half-dozen C programmers may very well be doable by a single FORTH programmer, and FORTH is underutilized, it's not a language which scales up to enormous projects well, IMHO.) 3. Risk of waiting for risks to be proven. Bob Frankston wrote of "Fear in the the skies" and stated that "The real risk of this nonsense is in relieving the airlines for responsibility for safety" and Our Esteemed Moderator observed that lots of e-mail had been received, "most of it suggesting that there is still little hard evidence of bad effects." All this is true, and yet when we weigh even slight evidence of risk and the airlines responsibility for the safety of its passengers against the rather minute convenience that a cellular phone offers on a plane; and when we consider the social risks of allowing the passengers to determine which safety rules they will follow and which they will ignore when the well-being of their fellow passengers is at stake; I do not believe that the decision in this case was outrageous. BRIAN TOD SCHELLENBERGER bts@unx.sas.com
The most astonishing part of the information provided in RISKS-20.51 regarding the eBay scam was the response from eBay found on the web site we were pointed to (http://mars.superlink.net/jason/ebay/ ). eBay's response, "PLEASE, do not give out details of this, as it will only cause more users to try it." Is classic security through obscurity. In this case, with all of the media attention this is getting, certain eBay employees are no doubt lamenting the Risks of the media discovering what they've attempted to obscure. :)
> You mean: > * Forth Go One reason that Forth is simple is that it reads from left to right: Go Forth AND * Leo Wong hello@albany.net http://www.albany.net/~hello/
> athena% weather bos > Conditions at KBOS on 7/6/99 at 7:56 PM EDT (18:56 GMT) Note also the unusual time conversion. 7:56 PM EDT is 19:56 EDT, which is 23:56 GMT, not the 18:56 they reported. Or is there an EDT other than (American) Eastern Daylight Time, presumably somewhere in England? --David Wittenberg dkw@cs.brandeis.edu
Please report problems with the web pages to the maintainer