As an engineer who spent 12 hour days programming Fortran in college, and who now sits in front of a computer all day at work, I thought this would be of great interest to you.
On 2/14/95 CBS Evening News with Connie Chung, Dr. Bob Arnot did a story about negative ions and their effect on mood. They talked about a study done at Columbia University where exposure to a high density negative ion generator was as effective in treating winter depression as medication.
I became very interested because I have suffered from depression and anxiety for years, and I did extensive research on the benefits of negative ions.
This research turned out to be especially interesting to me because I found a newspaper article discussing the fact that computer monitors emit positive ions - the opposite of negative ions. In the article, a consultant to the FDA says that computer monitors give off large amounts of positive ions and can actually cause depression, stress, fatigue, etc. in people who sit in front of computers a lot - like all of us Netters - and that we need negative ion replenishment.
After reading the newspaper article, I realized that I always felt especially irritable, stressed, and depressed after long days in front of my computer.
In doing the research, I found that negative ions have shown to be therapeutic for stress, irritability, fatigue, depression, etc. So I purchased a small, high density generator and it has given me substantial relief from my symptoms.
If any of you would like me to e-mail you that newspaper article, the transcript of the CBS news story, as well as the other research that I have compiled, just e-mail me at DanielS222@aol.com.-dan
Headline News reported today (18 March 1995) that the nation's two largest home mortgage underwriters, Fannie Mae and Freddie Mac, will shortly be deploying computer systems that will allow for instantaneous analysis of one's loan application. It appears that, given a user's name, recent paycheck stub, W-2 form, appraisal etc, the system will perform automated checks and approve mortgages without the intervention of a human underwriter.
"The machine never says no," we are told, if a loan application is "questionable" it is referred to a human underwriter for review.
I guess the RISKS are obvious, but I'll state them anyway -- if business is good, and the human underwriter feels like playing golf instead of reviewing loans, the loan application may be "referred" to the circular floor-mounted file cabinet with no substantive explanation to the applicant. The news story didn't mention whether the algorithm used some simple set of minimal requirements, or if a neural net or expert system was involved. If the latter, an even larger and potentially nastier set of RISKS are apparent.Rick R. email@example.com
I received a letter in the mail the other day from my credit card company, kindly informing me that I can get cash with my credit card from any ATM, and that they had selected a nice random PIN for me. Lo and behold, the randomly-selected number was my birthday! I called the credit card people up, and the operator was somewhat amused, as she claimed that the number was "picked by a computer" and it was an "amazing coincidence" that it was my birthday. I asked them to pick me a new random PIN, and just yesterday received a new letter from the bank with my new random PIN, which was exactly the same as my old random PIN.
Would it really cut the random number space down too far to remove all "obvious" dates? Heck, in this day and age, they probably *know* my birthday...Bill
I learned the hard way that one can apparently cancel the account of any AOL (America On Line) member with a simple phone call. About two weeks ago I suddenly could not log on to AOL.
Following the on-screen directions, I called the 800 number for customer service. A nice gentleman there explained that someone had called in earlier in the day and asked for my account to be canceled. It was! This was even though the person calling could not (according to AOL's own records), provide the credit card number used to pay for the account as verification of their identity. The gentleman helping me also volunteered that an account could be canceled by leaving after-hours voice mail at the customer service number.
My woes were exacerbated by an error made when my account was reactivated. My account was reactivated 10 minutes after my phone call, but my incoming mail service was not turned on for an additional week. I had to make a second (30 minute) phone call to correct this, and wait another day.
The total lack of verification of who is calling seems to be a poor policy. What if I had not logged in for three weeks? I would have lost three weeks of RISKS! I tried to suggest that they leave incoming mail enabled for a few weeks after an account is cancelled without complete verification. The people I spoke to didn't seem too interested.-Ben Blout
When I checked into my hotel on a recent business trip, I was told that the hotel was "having a problem with the locks" and that my room would be re-keyed sometime the next day. The room locks in this particular hotel use plastic cards with magnetic stripes rather than traditional metal keys.
Sure enough, when I came back the next evening my key wouldn't work; the room had been re-keyed. The hotel sent a security person up to let me in and give me a new key. He was unable to open the door: the new key didn't work, nor did any of his master keys. More security people came, more master keys, same result; the door would not open.
Next to arrive were the maintenance people with the lock re-keying device. This turned out to be a lap-top computer with a special adapter attached to the serial port. The locks, it seems, contain battery-operated microcontrollers. Re-keying consists of inserting a special master key, then a second special master key, and then the lap-top computer's re-keying adapter. The lap-top then communicates with the processor in the lock and causes it to register a new key code.
All this was to no avail -- the lock failed to open regardless of what key was inserted, whether ordinary room key or master key. Eventually the maintenance people had literally to break into the room.
In discussions with the security people, I learned that what started all this off was a head crash on a disk. The hotel had lost track of which key codes went with which rooms because of the unreadable disk. As a result, the front desk couldn't just "write" new keys as guests checked in. The hotel started the process of re-keying all the locks in order to create a new key code file. This worked OK for all but a couple of the 600+ rooms, mine being one of the failures.
Risks? Obviously, not having a usable backup for the crashed disk is the first risk. This cost the hotel lots of employee-hours and some ill will from frustrated guests, not to mention the physical damage to the door of my room caused by breaking in.
The more subtle risk is in the locks themselves. I had stayed in this hotel many times before, but I had not noticed that the locks operated ONLY on magnetic stripe cards. Many such mag-stripe locks in hotels also have a traditional, mechanical lock that can be used by the cleaning and security people even if the mag-stripe mechanism fails completely. These locks had no such redundancy. I'm surprised that the hotel would ever allow itself to be in the position of being unable to enter a room in an emergency due to the simple failure of a battery-operated lock controller, other than by breaking down the door.Rick Simpson, IBM T. J. Watson Research Center, P.O. Box 704,
From the New York Times
One 29-year-old woman in Brooklyn in the Home Relief welfare program was sent more than 200 checks totaling $350,000 over seven months, prosecutors said. Five other got $96,950 to $246,925 each, according to the authorities, who said the welfare recipients then shared the money with the clerks. By yesterday evening, 62 welfare recipients were under arrest and more than 30 were being sought. [...]
"It was very easy for the data entry person to do this because there were absolutely no controls or checks on the computer system," said Howard Wilson, the Commissioner of the City's Department of Investigation, which began the inquiry 18 months ago. "That corrupt employee being at that critical point in the process was able to literally push the button and out came the money."
Prosecutors would not discuss many aspects of the scheme, including how the clerks and the welfare recipients started working together.
The risks are obvious, but how much is it a risk of technology vs standard procedure? Would a supervisor have been more likely to check in a manual system? Is there more leverage for fraud in the computer-based system? Or is it just one more example of lax procedures. One can, in fact, argue that much of the value in computerizing a system is doing a critical evaluation of existing and new procedures. This step seems to have been omitted in this case.
US News & World Report, May 15th had a story about a known terrorist being granted a visa because there wasn't a match on his name in the State Department's database. To quote the article:
"The State Department, which issued Khalifa his visa, declines to discuss the case. A knowledgeable official says that when the U. S. Embassy in Riyadh ran a check to see if its computer would flag Khalifa's name on the State Department's terrorism watch list, it failed. The problem is the English rendering of Arabic names. One State Department official explains, "Mohammad has several different spellings in English." (My spelling checker had Mohammed).
The risks are obvious especially when compared with the small costs for better (but not perfect) matchin. The more interesting question is the process by which these things happen. There has been lots of government-sponsored research into far more difficult problems. Why does this knowledge not extend to critical systems outside the well funded security services? Perhaps for the same reasons that our air traffic control system is a creaky antique.
Usual caveat: the news article might be wrong and maybe there are entirely different issues here. With very nonEnglish common names and mixed standards for identification, the problem is more difficult than just soundex.
In an article by Susan Carey headlined "Three Market Researchers Team Up to Provide Data for On-Line Services" the Wall Street Journal reported on page B7, Wednesday 17 May 1995, that ``Three of the nation's leading market-research concerns have teamed up to develop research services for the on-line world.''
(Errors in the following summary may be M. Seecof's fault.) Since measuring ``hit rates'' on WWW pages and like resources isn't a very effective or very informative method of measuring interest or usage (especially with large ISP's planning to cache data from popular servers to improve response time to their customers--effectively masking such usage from the real providers--and, BTW, the copyright and other issues here deserve a separate discussion to which I hope to contribute at another time), Neilsen Media Research (yes, the TV ratings folks), Yankelovich Partners, and ASI Market Research plan to develop and deploy means of measuring first WWW and later other kinds of Internet resource usage and provide such information to clients. Their joint venture is called ANYwhere Online.
(The article did NOT say...) I think this is interesting. Ideally, one wants data not just from servers instrumented by ANYwhere Online (hereinafter ANY-O) but from other servers as well. In the TV world, Neilsen measures usage of all servers (TV stations/videotape) by a sample of the client population and extrapolates by statistical inference to usage by the whole client population. One could certainly do this in the Internet world. But consider another tactic. One could instrument Internet routers or links and measure traffic to various destinations. I suspect that Bill Gates intends to instrument UUNET/AlterNet's backbone to gather data on his competitors. For a fee, he could provide a digest of such information to ANY-O (or anyone). Other commercial ISP's could do likewise. This kind of traffic analysis could be exploited for commercial or other purposes. I look forward to learning from ANY-O whether they will use TV/ radio-measuring tactics, data from selected servers, data from backbone traffic analysis, or some combination.
I would like to point out what I see as a big RISK for people who don't want their traffic analyzed (whether for personal, or commercial-competitive reasons): no current commercial ISP promises NOT to collect and sell information about net usage by customers. We can use end-to-end encryption (e.g., PGP) to limit content snooping by ISP's but typical public-access or commercial services, via e.g., WWW protocols use cleartext. Even if we expect the quantity of such traffic to hamper content-snoops, traffic analysis by or with the cooperation of ISP's could have grave competitive or privacy implications. I think that commercial Internet users should demand privacy clauses in their contracts with ISP's *NOW*, because tomorrow it'll be too late.Mark Seecof <firstname.lastname@example.org> My employer may not share my opinions.
A few months ago, our computing organization invited our EDP auditors in to have a look at backup procedures. One of the findings in the auditor's report was "there are no established procedures for preservation of magnetic media to provide assurance of the long-term integrity of archived data. Also, no written standards exist that denote when specific types of magnetic media are to be retired. The only procedure observed is that generally magnetic media are not reused if a read or write error has occurred."
We are wondering what other organizations have in the way of established procedures to provide assurance of the long-term integrity of archived data, and standards on when specific types of magnetic media are to be retired.
Any comments or suggestion would be greatly appreciated.Patrick Casey, Indiana University, University Computing Services, 750 North SR 46 Bypass, Bloomington, IN 47405 (812) 855-8745 email@example.com
Switch to the SAS(r) software. It correctly calculates back to 1582 AD, nearly 200 years "better" than Sybase(r) software.
I was recently plotting some data originating from a measurement and data logging program on a PC under MS DOS.
To my surprise, the time on my plot was not increasing monotonously; rather, it was occasionally jerking backwards by a considerable amount for a single data point. I took a look at the raw data file to try to discover what happened. It appeared that the first data point after each midnight (the test was running for several days) still had the date of the previous day.
I consulted the author of the software who gave the following, rather alarming explanation:
In DOS, the time and the date are updated by separate interrupts. The time update has higher priority than the date update (I wonder what the logic behind the different priorities is?? The only explanation I can think of is: The date is updated less frequently, so it has less priority, which is not a very sound reasoning).
It is, therefore, possible to read out the date and time at a moment just after midnight where the time has been updated, but the date is still the old one.
In our application, a measurement is triggered at given times, one of which is exactly midnight. The measurement generates a lot of activity for a few seconds, preventing the date interrupt from getting served for some time.
As a result, the first measurement of each new day consistently has the time 00:00:06, and the date of the previous day.
Our application is probably rather exceptional in allowing the wrong day to persist for seconds. More common applications may only see this for milliseconds or microseconds, so not many people are likely to ever see the problem. (We could get into a long discussion, similar to the Pentium arguments, whether this is good or bad. I will spare you this).
I will also spare you a discussion of possible work-arounds. What remains is the amazing fact that anybody can dream up a system in which the updating of date and time is not an atomic operation.
I've been using win95 for over year now, so can probably make some fairly accurate comments.
Firstly, I don't know about the "Registration Wizard", but that's because I can't connect to the Microsoft Network. It seems that whoever entered the table of area codes got Bristol's revised code wrong.
Secondly, the latest beta releases are a lot easier to install than the early builds, and a lot of legacy hardware and software does work -more than with Windows NT for example. It is of course useful to have a sheet of paper listing your IP address, subnet mask and DNS server, because you will be asked these questions near the end of the installation, when it is too late to look at the old files to find these facts out.
Finally, Autorun does seem a nice concept, and certainly for home users it makes sense in terms of ease of use. It's cool for audio disks.
It is claimed to work on any "disk drive" which supports removable media and automatic insertion notification. That means CD-ROMS, PCMCIA Cards and perhaps floppy drives on "Windows 95" PCs which can indicate the presence or absence of a floppy disk.
Now personally I like the idea of scanning a new disk for viruses, even if it does take forever on a large CDROM, so was a bit unhappy about the concept of autorun disks. After a bit of research I found that there is an entry in the Registry which lets you choose which program gets run, or possibly disable autoplay altogether. So in fact it may be possible to configure autoplay to run a virus scanner over every new disk...-Steve
References (relevant quotations on request):
Windows 95 guide to programming
Microsoft Developer Network CD, Aprl 1995
[Disclaimer: Windows 95 is still only in Beta, so any details which I or anyone else provide about it may not be valid by the time the product is released.]Steve Loughran Hewlett-Packard Laboratories, Bristol, UK
"In Short" column, page 88, _Information Week_ magazine, May 22, 1995:
: Microsoft officials confirm that beta versions of Windows 95 include a
: small viral routine called Registration Wizard.
The word `viral' here is quite inappropriate. Moreover, the column makes it seem as if this information is collected covertly and secretly uploaded.
Here's what happens, or at least, what happens today. (Things might change before the final release.) When you select "Online Registration", the "Registration Wizard" fires up and asks you the same sorts of questions that would be asked by a paper registration form: name, address, etc. It then does a hardware scan, displays its findings, and asks you, "Do you wish to include this information with your registration?" Then it does a software scan of the local machine (not "every system on a network" as originally reported), displays its findings, and asks for the same confirmation to upload. This is all quite explicit, and users are required to confirm whether or not to include the information in the registration. There is no default response, so an inattentive user cannot just keep hitting Return and end up uploading the information by mistake.
After the questions are answered, additional prompts and confirmations appear before the phone is dialed.
Other points for debate/discussion: There is no way to edit the hardware or software inventory. So if the hardware or software list is incorrect or contains information that you'd rather not upload (e.g., beta hardware or software), your only recourse is to suppress the information entirely.
[As is customary here, Raymond's extensive disclaimers have been deleted by PGN, but are globally implied by the standard RISKS info item.]
The 14th International Conference on Computer Safety, Reliability and Security Villa Carlotta, Belgirate, Italy 11-13 October 1995
Sponsors: European Workshop on Industrial Computer Systems Technical Committee 7 (EWICS TC7) and European Commission Joint Research Centre - Institute for Systems Engineering and Informatics (JRC-ISEI) Co-Sponsored by IFIP Technical Committee 5 WG 5.4 and OCG, the Austrian Computer Society. Organized by the European Commission - Joint Research Centre, and Institute for Systems Engineering and Informatics.
Safecomp is an annual event which reviews the state of the art, experiences and new trends in the areas of computer safety, reliability and security. Safecomp was initiated by EWICS TC7 (European Workshop on Industrial Computer Systems, Technical Committee 7) in 1979 and since then has been held in Germany (Stuttgart, Fulda), UK (Cambridge, Manchester, Gatwick), USA (West Lafayette, Anaheim), Italy (Como), France (Sarlat), Austria (Vienna), Norway (Trondheim), Switzerland (Zurich), Poland (Poznan). The conference focuses on critical computer applications. It is intended to form a platform for technology transfer between academia, industry and research institutions. Safecomp is a one-stream conference and typically attracts up to 150 participants.
09:15 Invited presentation :
A. Servida (EC) : Dependability of safety-critical applications in the IT Programme of the European Commission.
09:45 GENERAL ISSUES, GUIDELINES
E. Schoitsch (A): Software Best Practices in dependable systems:
The European Research Projects: ENCRESS, OLOS, ESPITI from the partners' perspective.
H. Krebs (D) : Assessment on the basis of standards - Gaps and how to bridge them
11:15 SAFETY ANALYSIS
A. Saeed, R. de Lemos, T. Anderson (UK) : Safety Analysis for requirements specifications: Methods and techniques
M. Chudleigh, J. Catmur, F. Redmill (UK) : A guideline for HAZOP studies on systems which include a Programmable Electronic System
J.M. Voas, K. W. Miller (USA) : An automated code-based fault-tree mitigation technique
14:15 FORMAL METHODS
C. Fencott, B. Hebbron, K. Chan (UK) : Formal support for the safety analysis of requirements model
J. Gorski, J. Magott, A. Wardzinski (PL) : Modelling fault trees using timed Petri Nets
I. D. R. Shannon, A.J. Harrison (UK) : The application of formal methods to railway signalling systems specification and the ESPRIT III project CASCADE
16:15 HUMAN & LEGAL ASPECTS
R.J. Tiezema (NL) : Eliminating the unexpected
S.J. Westerman, C.M. Crawshaw, G.R.J. HocKey, N.M. Shryane (UK) : Cognitive diversity: A structured approach to trapping human error-
D. Davis (UK) : Legal aspects of safety critical systems
Thursday, October 12
09:00 Invited presentation :
B. Littlewood (UK): How I learned to start worrying and fear the computer....
M. Heisel (D) : Six steps towards provably safe software
W. A. Halang, B. Kramer, N. Volker (D) : Formally verified building blocks in functional logic diagrams for emergency shutdown system design
G. Picciolo, P. Giannino (I) : Programmable electronic controllers (PEC) performance assessment - An approach for reliability quantification
W. Schynoll (D) : BOOTSTRAP: Europe's software process assessment & improvement method, experiences and further developments
K. M. Hobley, P. H. Jesty (UK) : Analysis and assessment of advanced road transport telematic systems
14:00 SAFE SOFTWARE
J. Blieberger (A) : Loops for safety critical applications
M. Viola (CAN) : Ontario Hydro's experience with new methods for engineering safety critical software
15:20 APPLICATIONS I
E. Ruiz Morales (EC) : A software development approach for robotics control systems
J. Christmansson, Z. Kalbarczyk, J. Torin (S) : An attempt to evaluate functional diversity employed in a reactor protection system
A. Coombes, J. A. McDermid, J. Moffett (UK), P. Morris (EC): Requirements analysis and safety: A case study (using GRASP)
17:10 APPLICATIONS II
A. J. C. Sharkey, N. E.Sharkey, O. C. Gopinath (UK) : Neural nets and diversity
C. Rabejac (F) : On-line software error detection by executable assertions: from theory to practice
Friday, October 13
09:00 Invited presentation :
J Heckmann, S. Shirlaw (F) : An industrial view on requirements engineering and safety.
09:30 CASE STUDIES
F. Fenelon, J. A. McDermid (UK) : Safety cases for software application reuse
P. G. Bishop, R. E. Bloomfield (UK) : The SHIP case study - A combination of system and software methods
11:00 VALIDATION & VERIFICATION
R. Tiusanen, M. Hietikko (FIN) : Practical approach for the evaluation of safety related programmable electronics
A. Anselmi, C. Bernardeschi, A. Fantechi, S. Gnesi, S. Larosa, G. Mongardi, F. Torielli (I) : An experience in formal verification of safety properties of a railway signalling control system
A. Bondavalli, Chiaradonna, F. Di Giandomenico (I) : Dependability of iterative software: A model for evaluating the effects of input correlation
Request for full registration information should be addressed to Safecomp'95, c/o M. Dowell, TP 361, Joint Research Centre, I-21020 Ispra (VA) Italy, firstname.lastname@example.org .
Telephone and fax contact:Dorit Schlittenhardt
JRC-Institute for Systems Engineering and Informatics
Tel: +39-332-789478 - Fax:+39-332-789991 E-mail: email@example.com
Please report problems with the web pages to the maintainer