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…
Just after 1 p.m. on Sunday afternoon, April 6, a San Francisco Municipal
Railway car (1228) was headed for the car barns when it crashed into the rear
of another car (1304) that had stalled in the Twin Peaks Tunnel. 15 people
wound up in the hospital. It took all night to clear the wreckage, and full
service began again only on Monday morning. The causes of the stall and of
the crash were still unknown.
The signal system and the safety controls are as follows:
* An `automatic' speed-control system has three speeds, 10, 27, and 50 mph.
[Apparently ZERO is not considered a speed.]
* A cab-signalling system informs the operator of the maximum permissible
speed, red for 10, yellow for 27, green for 50.
The controls were thought to be `foolproof', because the car automatically
slows or stops if the operator exceeds the maximum indicated speed. There are
also impedance bonds in the tracks that are supposed to determine whether the
track ahead is clear.
The operator of car 1228 is named Johnny Wong. Three possible scenarios were
suggested:
1. Wong or someone else had disconnected the cab-signalling system,
which would bypass the speed controls. [This is allegedly not easy
to do, and has various voice protocols associated with it.]
2. There might have been a failure of the track-signal system, which
would have made car 1304 invisible to the control systems.
3. Human failure was also mentioned, although in the absence of the
first two scenarios, that does not seem to make much sense.
[Source: An article by Carl Nolte in the San Francisco Chronicle, 6 Apr 1993,
pA1, following up on the previous day's reportage.]
Well, the next day's report begins with this paragraph: The crash
``... was the result of the operator deliberately disabling the
safety system so that he could speed up his train, sources close to the
investigation said''.
The investigation continues. Stay tuned for any further revelations.
[Source: article by Phillip Matier and Andrew Ross, SanFranChron, 7 Apr 1993,
p. A1]
[By the way, the "Another" in the subject line is because I was
reminded of the Ghost trains that plagued the Muni Metro repeatedly
beginning about ten years ago. PGN]
On 22 March, Columbia's main engines were shut down three seconds before lift-off, because of a leaky valve. On 5 April, Discovery's launch (STS-56) was aborted eleven seconds before lift-off. Early indications pointed to a valve in the main propulsion system. In this case, the engines had not yet been ignited. (There had been an earlier one-hour delay at nine minutes before launch, due to high winds and a temperature sensor problem.) [Source: San Francisco Chronicle, 6 Apr 1993, p.A2] A computer glitch is now being blamed for the 5 April delay. Computer data had indicated that the valve had not closed. ``However, engineers believe that the valve closed properly and a bad circuit might be to blame.`` That is, the computer was in error in reporting the valve status. [Source: AP item in the San Francisco Chronicle, 7 Apr 1993, p.A3]
[...] The real reason for sending this is that the reporter said "since it is a bug in the computer software it will be easy to fix and the shuttle will be able to launch in the next 24 hours". Seems the expectations of fixing something as 'simple' as software are set way to high. I understand the idea behind the statement: If the problem was in the valve the shuttle could be delayed for more then 24 hours, while all you need to do to fix software is fix the code and reload the 'application' (possibly by floppy disk (-8 ). The risk has to do with people having a little knowledge. Not to long ago software was a big and nebulous idea to most reporters. Now everyone has certain ideas about how software actually works, which in most cases is actually wrong (heck I know people who still have trouble understanding the difference between ram space and disk space).
<< this was originally posted on sci.space.shuttle by Ken Hollis of the Kennedy Space Center <> [...] STS-56 abort at T-20 seconds (or thereabouts, maybe 16 seconds per my GLS DD?) was called today because of the GLS (Ground Launch Sequencer). It detected that the MPS (Main Propulsion System) High Point Bleed valve (PV22) closed indicator did not come on as expected. PV22 is a monostable, normally closed, helium pneumatically actuated valve on a line attached to the LH2 17" manifold. This 17" manifold is the line that goes between the ET (External Tank) and the main engines to supply LH2 to the engines. The high point bleed line is situated in the Orbiter at the "high Point" of that manifold. The LH2 manifold between the ET and the Orbiter looks like an inverted "U". One end of this manifold goes down to the bottom of the LH2 section of the ET (as opposed to the LO2 section at the top of the tank), the other end goes down towards the engines. Since LH2 is very cold, just about any temperature rise will tend to let it gas off. The high point bleed allows any gasses / bi-phase liquid that may accumulate at the top of this U to be siphoned off overboard, where it is sent to the flare stack & burned. It only takes a couple of seconds for this valve to be closed before a gas pocket forms in this section of line, so the valve must be open as close to lighting the engines as possible so that the engines don't ingest a hydrogen bubble. Believe it or not, this still simplifies the operation of the LH2 system with the engines & loading the tank. The lines in the aft for the MPS / SSME system are commonly referred to as "a plumbers nightmare". During the "terminal count" at about T-20 seconds, the open command is removed. Since this is a "monostable" valve, if there is no helium supply or no power to the solenoid that lets helium to the valve, the valve will close. GLS then verified at about 16 seconds (per my last DD) it is closed and everything is fine. Today the Open indicator went from ON to OFF (indicating it cycled) but the Closed indicator never went from OFF to ON (indicating it did indeed close) thus causing the abort. A downstream temperature transducer went from cold to very warm also indicating that the valve closed, but GLS does not check that temp ducer. A 48 hour scrub-turnaround has been called contingent on relying on the temp ducer rather than the Close indicator. Last I saw the indicator was not still working. It would be easy to say the it is a microswitch failure on the valve, but it could be quite a few things wrong (as always on the Orbiter) and further troubleshooting will have to be performed in the aft to figure out exactly what the problem is. Any problems after T-31 seconds is an abort for the day. No more holds are available. Ken Hollis INTERNET: HOLLIS@TITAN.KSC.NASA.GOV SPAN/HEPnet: KSCP00::HOLLIS
A new survey by John Haugh's Telecommunications Advisors, Inc., claims that technically sophisticated organized-crime rings are annually defrauding U.S. businesses and telephone companies of $4 billion in long-distance calls. 70.3 percent of the almost 700 companies surveyed reported they had been hit by toll fraud at least once in the past five years, with an average loss of $125,000 [inferentially, I conclude, per company rather than per hit]. Haugh predicted that 35,000 companies will be victimized this year. [That multiplies out to $4.375 billion for the year if the past average holds true.] [Source: An article by John Eckhouse, San Francisco Chronicle, 7 Apr 1993, p. D1]
If you look in the manual for "at" you will see that one of the recommended ways of using it is to have each at job schedule a new one a day or a week or a month later. Some find this easier than editing the /cron file or they may not have authority to do that. I regularly use this trick to schedule a daily backup of my files onto a tape that I always leave in my tape unit. Last year in April it stopped working. I thought perhaps there had been some kind of outage or bug and simply restarted it. This year I noticed that when it ran (early this morning) and try to schedule tomorrow morning's backup, at gave the message "too late". I thought it might have been some problem caused by a series of power outages we had yesterday but then I noticed it was also happening on two other machines. I did some experimenting and found that at would not schedule any jobs from 0200 to 0259. A few hours later I understood. Tomorrow morning there is no 0202 (the time that schedule my backup) because of the switch to EDT. We will go directly from 0159 to 0300. I read the manual and there is no indication in the manual that any such check is made. It says you can use any time between 0000 and 2359. This is clearly a case of incomplete documentation. Is it a case of the author of at being too clever, or me being too stupid? I think it a nice example of how subtle can be the error that leads to a failure. It never occurred to me that they would be checking for that missing hour. They probably never thought of someone having a regularly scheduled call for 0202. However, there is something even nicer. If it skips the run in the spring, shouldn't it run it twice in the Fall? I checked my records and it doesn't do that. Even though the clock is going to drop back it schedules the run for the next day. Now, is that a bug? If so whose? A question of documentation! Dave
Yesterday I went down to the local Babbages for a copy of DOS 6.0 with
expectation of a similar experience as when 5.0 was purchased. Well the
box was the same size but that was about it. (What do you expect for
US50.00 anyway).
It seems that MS-DOS now comes much like an automobile or cable television:
the base price doesn't include the options.
Inside the two-inch-thick box was a slim volume (321 pages vs 668 pages
in the DOS 5.0 manual) mostly on the new "features" (as in "that's not
a bug, its a feature" 8*) and three high density disks (and a coupon for
low density - one of many coupons).
Well, I can say this much, its not really for monochrome laptops, its not
really for XTs, the commands are not consistent, and it has its share of bugs,
but seems ok otherwise.
Towards the end of the book you find a set of coupons: the first asks you
to send in US24.95 + US5.00 for shipping + tax. This gets you the "Microsoft
MS-DOS 6.0 Resource Kit" which includes the "MS-DOS 6.0 Technical Reference",
and a set of "supplemental disks" which include things like COMP, EDLIN,
EXE2BIN, and LCD.CPI which were left out of 6.0 (everyone in Redmond must
like to wait on EDIT and has an active matrix laptop in their Porche).
If you are using STACKER, for US5.00 you can get a conversion utility for
DBLSPACE & possibly repeat my experience (on my venerable but 100% compatible
XT clone, WD controller, & ST-225, attempting to use DBLSPACE resulted in a
"Divide Overflow" half-way through the conversion & left the machine
unbootable even from floppy - had to reboot with a lesser DOS version and
clean off all of the DBLSPACE files to recover - happened more than once so no
fluke).
Speaking of DBLSPACE, when formatting a 360k floppy with /S, you now get three
hidden files and have only 180k free: seems DOS 6.0 grew a bit and now puts
50+k of hidden DBLSPACE.BIN on the floppies too.
There is an anti-virus tool from Central Point but by now every virus-writer
in the world knows how to turn it off with a high function of Int 10, 16,
or 21h (haven't tried it but was told by a reputable source). Even so there
is yet another coupon at the end of the book requesting another US19.90 for
two updates, one "now" (they knew it was obsolete already ?) and one in
3-4 months. Actually cheap compared to the (pounds)29.90 they expect from
UK residents (includes VAT).
What really got me is the lack of a simple environmental variable to turn
of the color in the utilities for a monochrome display. I told SETUP to
use monochrome but this ended when SETUP (which also informed me that
an "incompatible disk compression" was present - nope) was done. For EDIT,
/B is the switch and /NOHI helps. DEFRAG wants /BW, MSAV allows /BW but
/MONO works better (you can go out for lunch while the memory scan runs
on an XT).
Now there are alternatives to cubic money. You can download the supplemental
file (DOS6SUPP.EXE) from the MS BBS in Washington (206.936.6735), all 480+k
of it & the BBS does support 9600 baud but do not confuse it with v42,
v42bis, or MNP. 33 bad blocks (a record) during the download but my
trusty Supra, 16550 chips, and Procomm+/Zmodem (plugs) handled it ok.
The Anti-Virus update can be downloaded from 503.531.8100 - not on the
coupon but on page 277 - probably Central Point.
In short, the product has the feel of "not ready for prime time" but it
did appear in the first quarter '93 (last day actually - well Egghead
had it the day before).
A final note: I did try to call Microsoft tech support about things
encountered (90 days "free" support is available starting with the first
call). I got through to the lady who took serial numbers (and started the 90
day timer) quickly enough only to be informed after that I was 86th in line &
could expect a 90+ minute wait. Not an 800 call. From Florida to Washington.
No thank you. (At least they told me 8*).
Padgett
At present, companies have the right to require their employees to use
company computers, including E-mail access, only for company business.
Employees who participate in the Internet discussion groups may violate
this restriction. Then they incur the risk of harassment if they ever
fall out of favor and/or hold unconventional political beliefs.
The remedy?
Next time you accept a job, negotiate (along with your salary and fringe
benefits) the right to use your company's E-mail also for private purposes,
subject to reasonable limits (which are based ONLY upon quantity of mail
send and received) and the understanding that the time you spend on
private E-mail is your time, not company time.
Companies have the right to control the use of computers which belong to
them. On the other hand, they are required to compensate you for your
work in their behalf (in the form of salary etc.). So considering E-mail
access to be another fringe benefit will solve the problem.
--- Omer
On < Mon, 29 Mar 1993 13:24:37 (PST) > In Comp Privacy 2-11, Steven Hodas <hhll@u.washington.edu> > If I send a personal letter to someone do they have the right to > disclose it to others without my consent? No. The Copyright act of 1978 and later amendments gave statutory protection at the federal level for the first time to unpublished works. > Does this vary state by state? No. Prior to the 1978 law, an unpublished work was subject to the protection of the common law of the state in question. The new law expressly excludes states from having any jurisdiction over unpublished works and voids any "common law copyright" which might have existed. All works are automatically protected under federal law. > If it's prohibited, is it a civil or a criminal issue? Civil. > If it is permitted doesn't that suggest that we have greater privacy > protection for electronic communciation because the ECPA would prohibit > that kind of disclosure? I think you are confusing things. The ECPA gives to Electronic mail the same protections which are available for telephone conversations - the protection against interception by third parties or the use of intercepted E-Mail by law enforcement personnel without a warrant, i.e. what the laws against wiretapping and recording of telephone calls, the ECPA provides to the same extent to E-Mail. The ECPA does not apply to the sender or recipient of the message. It only applies to anyone who may see a message prior to its delivery to the designated mailbox or delivery point. It applies to the E-Mail providers who carry the message and to anyone who delivers it. I am also posting this to the Risks Digest for a reason which has to do with another issue which almost no one has noticed. As of April 1, 1988, the United States became a member of the Berne Union for the Protection of Literary Works. This treaty is most famous as the reason companies would simultaneously publish a book in Canada in order to obtain protection under the Berne Convention. As of four years ago, that process was no longer necessary because the U.S. is now a member of the Berne Union. The most significant issue under Berne (I refer to this as "It Berne's me up") is that there are no formalities or requirements of notification in order for a work to obtain copyright protection. What this means is that copyright notices became totally optional after April 1, 1988 for all works first published on or after that date. In theory, if you obtained a computer program from someone which simply had his name and address on it, and wanted to use it, you would have to find out if the person who wrote it wanted anything to license it. You can be sued, and lose, and the other party can collect damages, even though the work has no indication of copyright notice. I live just outside of Washington, DC and the Copyright office is just a 20 minute train ride away. A frightening fact is that despite the treaty having been around for more than four years, the Copyright office still does not have copies of the text of the treaty. They have copies of the Phonolog Convention (for protection of sound recordings) and they have copies of the Universal Copyright Convention (which instituted the C in a circle copyright notice.) But Berne is conspicuously absent. It makes me wonder what things are stated in this treaty that are so bad that nobody wants people to know what it says. (The last time I tried to get a copy was about a year ago, but that still was 3 years after implementation and the Copyright Office STILL did not have copies of the text of the treaty. It makes me wonder why. Just remember this little piece of information. A treaty, once ratified by the Senate, has the force and effect of an amendment to the Constitution of the United States and can override its provisions. Think about that some time. Paul Robinson — TDARCOS@MCIMAIL.COM
risks@csl.sri.com writes: >ps Turning off the "in band" sequence & using DTR I can understand, but > 128 (80h) is just as likely as "+" (2Bh) in a binary file unless the > Motorola firmware interprets it as "none". In general, most modems treat anything above 127 as ignore. Having been bitten by the triple plus sequence even with the Hayes guard time (back when I used rn, for instance, and was '+'ing through articles...) I learned to turn this off very early.
I am looking for experiences, anecdotes and comments relating to security, or the lack thereof, in "groupware" applications and systems. This material will become part of an article to be published later this spring. Any replies that I wish to quote I will contact the author first. For those replying from the newsgroups, I would appreciate copies to roberts@decus.ca and rslade@sfu.ca for backup. Vancouver Institute for Research into User Security Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca
Opinion, editorial and news worthy submissions are currently being
(sought and) accepted for a new start-up electronic news journal.
This monthly compilation will be called 'The Legal Net Monthly
Newsletter' and will focus on the legal and ethical aspects of
computer networking. Legal Net Monthly will be a non-biased, open
forum electronic newsletter keeping in step with the networking
environment of the '90's and will be availble by E-Mail subscription.
Legal Net Monthly is aiming to release it's first issue on May 1st,
1993. Articles on the following topics are especially welcome:
o Defining "Criminal Mischief" on the Nets
o Authoring/Distributing Computer Viruses: Legal Implications
o Legislative news around the world
Send all submissions, subscription requests and correspondence to:
fergp@sytex.com
Paul Ferguson, Network Integration Consultant, Centreville, Virginia USA
fergp@sytex.com sytex.com!fergp 1:109/229 (FidoNet)
This is a pointer to a basenote and discussion pertaining to computer
pointing device injuries (mouse, trackballs, puck, stylus, etc.) in
sci.med.occupational. For convenence I have included a copy of the
basenote below. To follow net etiquette, please direct all responses to
the basenote below in sci.med.occupational notesgroup ONLY.
(Copy of Basenote)
This note (which is being posted monthly) is for anyone that has been injured
using a computer pointing device (mouse, trackball, puck, tablet, etc.). I
have been assisting computer operators who have been injured using pointing
devices for the past 4 years. I am now presently doing research at the
University of California's (San Francisco and Berkeley's) Ergonomics Lab on
the design of computer pointing devices with the goal of reducing injuries
associated with their use. In order to do this, I need to collect information
on pointing device design characteristics (button design, button force, device
size, device shape, etc.) that are important in minimizing and/or reducing the
physical stresses operators are subjected to. Some of this information will
be collected through my laboratory research, but a major and important source
of information has to come from operators like yourself. I need to collect
all the information I can from computer operators that have been injured as a
result of pointing device use.
In order to do this, I need your help. If you have been injured using a
pointing device, I would appreciate it if you would send me a note with
information pertaining to your injury. I would like the information e-mailed
directly to me (petej@garnet.berkeley.edu). The format I would like the
information sent to me is as follows, fill in as much as you can:
1) NAME: (optional)
2) COMPANY: (optional)
3) PHONE #: (optional)
4) NUMBER OF HOURS SPENT IN FRONT OF THE COMPUTER PER DAY:
5) PERCENTAGE OF TIME SPENT USING A POINTING DEVICE:
6) MANUFACTURER OF COMPUTER AND MODEL NUMBER:
7) POINTING DEVICE USED AT TIME OF INJURY: (Please be specific)
a) MANUFACTURER
b) MODEL OR PART NUMBER
c) DESCRIPTION OF DEVICE
8) PRIMARY SOFTWARE APPLICATION USED AT THE TIME OF YOUR INJURY
9) TYPE OF INJURY
10) WHAT YOU THINK CAUSED YOUR INJURY
11) IF INJURY IS RESOLVED OR YOUR CONDITIONS HAVE IMPROVED, WHAT CHANGES
WERE MADE (This is probably the most beneficial information)
My intent is to enter this information into a database in order to gather
information and look for trends. Each month I will share relevant information
by posting a monthly summary in sci.med.occupational similar to what has been
done with keyboard information. If you are presently experiencing problems,
feel free to call me (510/231-9405) and I will share with you what I know. I
am also open for suggestions, please post responses to this basenote or e-mail
me if you have any further suggestions or input.
If your company has internal bulletin boards, please post this note or provide
a pointer telling your co-workers about this basenote in the
sci.med.occupational newsgroup. I will be also be posting a pointer to this
basenote in comp.risks, comp.human-factors, and sci.med as well.
Finally, if you have any opinions or inputs on a particular pointing device or
pointing device design in general, send me a note or call me. Our lab is
assisting some of the major pointing device manufacturers with the design of
their pointing devices. If you have some inputs for a particular company, I
will be happy to direct them to the appropriate person.
Thanks for your help.
Peter W. Johnson
(End of Basenote)
FTCS-23:The 23rd Annual International Symposium on Fault-Tolerant Computing
Diagora, Centre de Congres de Labege, Toulouse, France, June, 22-24, 1993
To receive a hardcopy of FTCS-23 Advance program [or a complete version of
the on-line announcement, which was much too large for RISKS], please contact
Mohamed Kaaniche: LAAS-CNRS,7 avenue Colonel Roche, 31077 Toulouse, France
Tel: +(33) 61 33 64 05, Fax: +(33) 61 33 64 11
Email: Mohamed.kaaniche@laas.fr
[The full announcement is also in the CRVAX.SRI.COM RISKS archives
CD RISKS: with the file name RISKS-14.FTC . PGN]
FTCS is the world's most important forum for the presentation and discussion
of state of the art developments in dependable computing systems. This year's
program features 60 regular papers, 5 practical experience reports, 6 software
demonstrations and one panel. This program is the result of a very stringent
selection process carried out by the international Program Committee on more
than 300 submissions. The regular paper sessions cover a breadth of topics
from concurrent error detection to software-implemented and application-based
fault-tolerance, from theoretical issues in modeling to field measurement of
fault- tolerant system dependability, from testing to fault injection. The
opening plenary session will be devoted to practical experience reports on two
safety-critical, software intensive systems currently in operation: the
digital fly-by-wire systems of the Airbus family of airliners, and the speed
control system of the Paris subway. The panel will discuss the limits in
dependability, and the software demonstrations will encompass tools for
hardware and software dependability evaluation.
Exhibitors from both industrial and academic communities will present
commercially available products, advanced prototypes and tools relating to the
conference theme. An exhitors' forum will offer technical presentations
relating to the exhibited products, prototypes and tools.
The symposium participants will be given the opportunity to attend a
pre-symposium review of the research conducted at LAAS-CNRS, as well as
joining post-symposium technical visits of Aerospatiale, CNES and Matra
Marconi Space.
On Monday June 21, a welcome reception will be organized at Hotel Capoul. On
Tuesday June 22, the Mayor of Toulouse will give a reception in the famous
"Salle des Illustres", followed by a concert at the Jacobins Cloister. On
Wednesday June 23, the traditional excursion will be to Albi, home town of the
famous painter Toulouse-Lautrec, followed by a banquet.
Please report problems with the web pages to the maintainer