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…
San Mateo County has spent $35 million thus far on a new Health Services computer system (now two-years old) that was expected to integrate 40 different stovepipe entities that previously were unable to communicate with one another. Over the past few months, the system has been so unreliable that it could not even send out medical bills. The backlog of account receivables is now more than $40 million. Blame is being distributed among poor initial outside advice, a sudden cut in anticipated money, and damaging turnover in consultants. The costs are about double what had been budgeted. [Source: Article by Mark Simon, *San Francisco Chronicle*, 25 July 2000, A17] As an aside that seems relevant to many other situations if not to this one, outsourcing of responsibilities (from requirements to design to implementation to operation and maintenance) is increasingly popular, but doomed if you don't have serious in-house competence to understand what is being outsourced.
[From Dave Farber's wonderful IP distribution. PGN] The complex structure of the Internet makes it resistant to errors or failure but it is also its Achilles' heel [...]. Because the system is so varied, if one or more nodes — the crossroads through which Internet data travel — goes down it has very little impact. But researchers at Notre Dame University in Indiana ... have found if the networks with the most highly connected nodes were attacked by cyberterrorists, it could fragment the Web into isolated parts. [Excerpt from an article by Patricia Reaney, http://www.zdnet.com/zdnn/stories/news/0%2C4586%2C2607716%2C00.html, Reuters, 26 Jul 2000] [But the Internet is a well-heeled beast: it has MANY Achilles' heels. PGN]
Companies in Silicon Valley, California, are being forced to build private power stations amid growing evidence that there is not enough electricity in America's grid to drive the booming high-tech industry. US demand has grown by 35% in the past 10 years. [Is that all?] More than 10% of all US power is for computers and related stuff. The Internet is making it even more of a problem. According to Karl Stahlkopf of the Power Research Institute, "You may think electronic gadgets can't use much electricity. In fact, when you look at the servers and the computers that back up the wireless Palm Pilot for example, you'll find it has the electrical load equivalent of a refrigerator." [PGN-ed from an article by Simon Davis, electronic Telegraph, 11 Jul 2000] [Another item from Doneel noted an Associated Press article by Nicholas K. Geranios, Power rates in West jolting economy, 10 Jul 2000, discussing the effects of a sudden large hike in the cost of electric power on the West coast — including cases of rates being multiplied by a factor of 40 in one case. PGN]
He's back. Horror writer Stephen King has now used his Web site (www.stephenking.com) to post the first two installments of his new novel "The Plant," which is about a "vampire" plant that takes over a publishing company. The material will be posted as pdf files, and readers will be trusted to pay the author a dollar to download it. If King receives payment for at least 75% of the downloads, he will continue with his plans to post the remainder of the book on the Web. People in the publishing industry are skeptical. Literary agent Mort Janklow says that King is "a fellow sitting up in Maine having fun, but it's not a way to run a business." And National Writers' Union president Jonathan Tasini says, "You still need a lot of money and power to promote a book. The same people who already make a good living at the top of the bestseller list may have another way to sell, but I don't believer there will be dramatic change for other authors." [AP/[San Jose] *Mercury News*, 24 Jul 2000; NewsScan Daily, 24 July 2000 http://www.sjmercury.com/svtech/news/breaking/ap/docs/230313l.htm] The truth about e-books Despite the hoopla surrounding the e-publishing of Stephen King's novella, "Riding the Bullet," the truth is that most of the 500,000 electronic copies distributed were purchased by Amazon and Barnesandnoble.com, which then gave them away, and many other copies downloaded were simply "experiments" by people who wanted to see if the technology worked. According to a survey of 3,000 subscribers conducted by the Book Report Network, only 1%, or 5,000, of those who downloaded King's first e-book actually read it. "No reader is asking for e-books," says Book Report Network CEO Carol Fitzgerald. "This is not the Sony Walkman." Publisher Simon & Schuster, which distributed the novella, disputes the Book Report sampling. [*Los Angeles Times*, 24 Jul 2000 http://www.latimes.com/business/20000724/t000069317.html NewsScan Daily, 24 July 2000]
Last week I received an e-mail informing me that annual enrollment for benefits at my company would now be handled on the Internet. The e-mail included a login ID and password for use at the enrollment Web site but, oddly enough, not the URL for the Web site. Web enrollment is mandatory. The e-mail contained an attached memo in MS Word format (itself wrought with RISKs). The memo in the e-mail was entitled "Read this to find out how you can win cool stuff courtesy of ____ HR!" (Company named deleted.) It goes on to say that "This will enable you to complete open enrollment on-line, view your enrollment elections and tax withholding information anytime, change your address, change your 401(k) contributions, add dependents or beneficiaries, and soon you will be able to view your pay stub here too." I sent off a complaint about having so much data accessible on the Web. Today there were several developments. First I discovered that I was not on the company-wide mailing list used to distribute announcements about benefits. Then I received a reply to my complaint that the company was "sensitive to the security issues" and described two conflicting security measures. without a URL to rule out possibilities, either: a) the benefits Web server is behind the corporate firewall, where its security is administered by a third-party sys-admin shop, or b) the Web server is on a third party machine where we have no direct control over the security arrangements. (I'm not sure which alternative is worse.) Is there any kind of audit or accrediting that Web sites can go through to verify at least minimal security arrangements? If so, I'd really like to know about them. Among the RISKs I can list: 1) the company's jumping into this whole hog, without an apparent backup plan, or alternatives for people who don't want their entire employment record and benefits package hanging out in inherently insecure and unreliable Web space. 2) The login and passwords sent out by e-mail could be intercepted; they were in no way protected. 3) The format of the logins and passwords make it extremely easy to guess others. (NOT the first time I've encountered this here. The third party company responsible for sys admin has a habit of assigning incredibly obvious passwords based on the user's name.) 4) Once guessed, a user ID and password could at a minimum provide for a denial of service attack on an individual. I don't know (and I hope I don't have to find out) what procedures are in place for changing or recovering a password. 5) Using Web enrollment has been made into a lottery game with prizes, which causes me to wonder if we're really supposed to take any of it seriously. 6) Overreliance on Internet technology has already caused me to miss out on receiving some important information on the benefits package. 7) The deadlines for enrollment obviously assume that there won't be any major glitches in the system. "You must enroll by 7/31 or risk having your benefits canceled." Yet just two months ago, when my company moved the employee stock purchase plan to Web-based administration, glitches caused several weeks delay in enrollment for many people.
One of our web users seems to have had a lot of trouble with broken links in his personal webpages on our Apache webserver over the last couple of years. Instead of / as a directory terminator, he'd have \. Or he'd have bizarre stuff like /\Directory\ instead of /Directory/ in his broken links. I'd put it all down to him being a Microsoft fanboy who didn't know what he was doing; after all, he was generating the HTML pages using Microsoft Word, and therefore deserved everything he got. (bugs in Frontpage such as leaving in local file:c:\\\ urls for images, so only the author gets to see incredibly fast-loading images when he checks his composed pages, are well-known.) However, I had occasion to use Microsoft's Internet Explorer 5.5 today. So, I went to view his pages to see the world through his eyes. And, through his eyes, everything worked just fine, as if there were no backslashes there at all. Every known-to-be-broken link did just the right thing. Which was odd, because I knew the links in the pages stored on our Apache server hadn't changed. So I viewed source in IE, and discovered... no backslashes. IE *stripped out or converted the backslashes* before rendering the source to screen - even before rendering the source to 'view source'. The user wouldn't know the backslashes were there, because IE was *deliberately hiding and converting them* for him, presumably in order to compensate for the html rendering deficiencies of other Microsoft products - and interoperability with non-Microsoft browsers be damned. The user thought he was doing a good job, based on checking using the tools in front of him. If you view source, you expect to see the actual source, and not a prefiltered version. This filtering is clearly a risk in that it allows behaviour that would previously have been clearly exposed as bugs in the composing products to stay, unnoticed and uncorrected, because it means you can't trust the tool you're using, and because it screws up interoperability testing. (Which, because IE comes from Microsoft, is hardly a surprise.) <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
When I was leaving home to travel to the IETF meeting in Pittsburgh next
week, the pre-ordered taxi did not come on time. After waiting five minutes,
I phoned them and was told that they had had a computer crash during the
night, and all pre-bookings had been erased. They sent a cab when I called,
and I arrived at the airport 20 minutes late (the bus on the second leg on
the journey was also delayed). I did catch my flight, but with criticism
from the ticket checkers that I was late. I did not have time to change
money at the airport as I had planned. So my loss was only perhaps 10-15
dollars in more expensive credit card buys as compared to cash buys. Others
may have been less lucky. The flight was not delayed, this airline obviously
did not feel that this was a reason for delaying the flight.
I do not know of the cause of the crash, so one can only guess:
1: The computer stopped, and no one on a Saturday night knew
how to reboot it.
2: Software failure.
3: Random disk error in the data base files made them unusable.
4: A real disk crash had occurred.
One wonders about
1: Did they have adequate instruction on error handling and education
to their operators, or a system with a software specialist on call?
2: Was the software tested well enough?
3-4: Did they use some disk redundancy system capable of
continuing running if a single disk crashes or a single
disk error occurs?
In particular, disk redundancy systems and fail-safe computers (not 100 %
safe, of course) do exist, but how often are they used when they should have
been used? A time-scheduling system, whose breakage would delay hundreds of
people by 20 minutes in going to the airport, would that be a system which
should have a disk redundancy system? Perhaps the companies marketing such
systems could use this example as a basis for selling their software to
companies who do not understand the risks and what can be done about them.
The cab company involved was "Flygbusstaxi" — which is a shell company for
several other cab companies providing the actual transportation services
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/
> The real cost isn't in the 10-minute fix; it's in verifying the 10-minute > fix. That is the RISK. NO! The real risk is using an invalid analysis to reach a bogus conclusion. THAT is the risk. How is Mr. Liber's analysis invalid? Well, off the top of my head and in no particular order, he makes an "apples to oranges" comparison, adds costs to the bloat removal process that aren't necessarily there, does not fully account for the costs of bloat, and assumes facts not in evidence. When comparing the costs of the bloated software to the cost of removing the bloat, Mr. Liber compares the amount of time required to remove the bloat with the amount of money required to store the bloated software on a hard disk. Obviously, he should compare time against time or money against money, but he cannot compare money against time unless the conversion between the two is known. This is especially true when he concludes: > Your fix is worth, at best, a fraction of a cent to your customer. If this > causes you to slip shipping by even one day, you've made a bad decision to > work on it. This begs the questions: How much is a one-day slip in the release of a commercial application worth to a customer? Mr. Liber appears to assume that it costs quite a bit . However, it is not that hard for me to imagine a situation where a single day slip in the release date of an application has a significant NEGATIVE cost to a particular end user. In no case is the answer to my question large and positive for end users of mass-market software. Waiting an additional day for the next version of "Word" simply doesn't cost the user very much. How is the cost of removing bloat overstated? Well, because the regression testing mentioned in Mr. Liber's message would need to be done anyway as part of the release process for any new software version. Since removing the bloat would, most likely, be done before the application began the long road through the QA department (assuming, of course, that there IS a "long road through the QA department" which is another discussion for another time) then there is NO additional testing cost associated with removing the bloat. Perhaps the strongest disagreement I have with Mr. Liber's message is the attempt to argue the costs of bloat out of existence. The cost of bloated software is more than just a few cents worth of hard disk space. You see, when used, that software needs to be transferred from the hard disk into main memory. While the capacities of hard disks have expanded rapidly, the time required to transfer large files from a hard disk has not decreased quite so much and the time is not linear with the size of the software to load: Programs that are twice as large typically take more than twice as long to load. And this time adds up. If bloat causes the software to take an average of one additional second to load and the software has an average of 100,000 uses daily over the entire customer base, then over an 18-month lifespan the product wastes 1545 man-days of time just waiting for the software to load. Compare that to a couple of weeks for a couple of guys and you get quite a different answer for whether it is worth the effort to reduce the bloat than that presented in the original message. Especially in light of the fact that, if the total production run for the software is 1,000,000 units, the bloatware reduction effort takes 100 man-weeks, and each man-hour costs $100, the total increase in the cost of each unit as a result of that bloatware effort is 40 cents. Nor is the time required to transfer the program off the hard disk the only cost that was missed in the original analysis. In addition to the cost of the additional hardware required to run ever more bloated applications, you've got to include the downtime required to upgrade the hardware to satisfy the requirements of software that won't run on older hardware. If the application lives on a file server, then you've also got wasted network bandwidth and wasted time to periodically upgrade the network to handle the additional load. Further, it seems likely to me that the larger an application is, the more likely it is to exhibit poor locality of reference which means that bloated applications make less effective use of semiconductor cache and require more effort to make effective use of virtual store. The net effect of bloatware is, therefore, to make the entire computer system perform more poorly, even on higher-performance computers of recent manufacture. The facts not in evidence? Well, Mr. Liber's message implies that the decision to release bloatware is always the result of a careful analysis, made by the software vendors, of the relative costs and benefits. If only that were the case! There is a profound difference between a conscious choice to reduce the cost of a product by not reducing the size of an application and releasing bloatware because of ignorance or apathy. Use of the additional resources available in recently manufactured microcomputers is allowable. Waste of those same resources is, to me, unacceptable, and waste is certainly what it appears, to me, to be. In fact, the part that really makes me angry is the fact that the benefits of not reducing the bloat are reaped solely by the software vendor, but the costs are borne solely by the consumer. This shows a disrespect of the end user that borders on contempt. I don't like to be held in contempt by those who want me to give them money. One opinion, worth what you paid for it. Jonathan Guthrie, Brokersys, 12703 Veterans Memorial #106, Houston, TX 77014, USA +281-580-3358 http://www.brokersys.com/ jguthrie@brokersys.com
> ... Sprint Canada's The Most Online service had one of its regularly > unscheduled outages last week, this time affecting incoming e-mail. There is a related risk here - the risk of assuming that you are dependent on a provider for E-mail services. It is a relatively simple matter, given a static IP address, your own domain name and a (semi-)permanent link, to run your own mail server which will allow you to have some control over E-mail reliability. So long as your server is actually connected to the Net, (which you can test) the ISP's mail server is now out of the loop as E-mail can pass directly from the source to your destination. Nick, Pacific Internet +61-2-9253-5762 http://www.zeta.org.au/
> ... If the member of staff has to leave for some reason, he or she *MUST* > deactivate the system, which opens all the gates. This is a Health and > Safety issue, and LU would be fined heavily if caught breaking it. You never fix bad design by kludging around it. That, by definition, proves that it was badly designed. You design it right and you design it so that it's fail safe. Boyd Roberts <boyd.roberts@ca-indosuez.com>
> You never fix bad design by kludging around it. [...] "Don't let people get trapped behind unmanned gates" is a bad design? I hope you don't design life-critical systems. Clive D.W. Feather <clive@demon.net> +44 20 8371 1138 http://www.davros.org
> You can type a home phone number into their voice menu system and it will
> answer back with the account standing, recent payment amounts and dates,
> without any password or other authentication. ...
Were you calling from home? — I[1] would check if the number you typed
matches CLI[2] we get from the exchange when answering your call. If it does
there's no reason for extra security: whoever's calling is already inside
your house...
Telstra[3] voice mail works the same way: if you call from home you're
asked for PIN, if you call from somewhere else you have to type in
mbox number and pin[4].
[1] my last job was IVR programming
[2] caller line id
[3] main carrier in .au
[4] of course you don't know your mbox number — you've always called
from home before and nobody ever told you your mbox has a number...
Dima
[Also noted by Jonathan Kamens, who added:
Sure, there's the possibility that someone without legitimate need for
that data could call AT&T from your home telephone, but that's not a
particularly likely scenario or one with much risk associated with it.]
* From: Frances Kemmish <archaeo@iconn.net> * Newsgroups: alt.usage.english * Subject: Re: Susan * Date: Wed, 26 Jul 2000 08:50:17 -0400 John Steele Gordon wrote: > Alex Chernavsky wrote: > > Frances Kemmish wrote, quoting _Finest Hour: The Battle of Britain_: > > > > >A fuller quotation, from page 179 of the US edition: > > >"But a forced peace, rather than Panzers in Susan villages, > > >was the most likely way Britain might lose the war in 1940." > > > > Pandas in Sichuan villages? Certainly, that strategy would have been > > a less likely way for Britain to lose the war. > > Panzers in Sussex villages, however, would have done the trick. I think this is the answer; it fits both the references to "Susan". I assume that the US edition was spell[ing]-checked using the same spell[ing]-checker which I have - it offered me "Susan" as first replacement for "Sussex". Fran [This thread included a variety of other computer-aided mispelingz. PGN]
Please report problems with the web pages to the maintainer