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…
I just got this out of the info-atari16 mail group.
It illustrates one of the more unusual risks I've seen :-)
Date: 22 Jul 87 03:54:28 GMT
From: mtune!akgua!rbk@RUTGERS.EDU (R. Brad Kummer)
Subject: ST keyboard parts needed
To: info-atari16@score.stanford.edu
Does anyone have a damaged ST keyboard that they could send me a piece of?
I need one of the little rubber "nipples" that sits under each key. If you
remove all those tiny screws from the back of the keyboard, there is a
little rubber cup with a small piece of carbon attached underneath each key.
Why do I need it? Don't ask... My kids spilled a Coke on the keyboard, I
took the keyboard apart to clean it (that part worked fine), but I dropped
one of the little "nipples" on the floor and the [...] dog ate it!
If you could help me out, I'd be eternally grateful. (Would you consider
trading it for a dog? :-)
Thanks, R. Brad Kummer, AT&T Bell Labs, Atlanta, GA {ihnp4, akgua}!akguc!rbk
[(Very lightly edited.) Doggone! PGN]
Those not in the Unix community may not be aware of the excellent security
paper that was published in the Bell Labs Technical Journal a few years ago.
Some parts of it are Unix-specific, but much of it is fairly generic. The
most interesting parts are discussions of how supposed enhancements in
security actually make things *worse*; the paper is clearly the result of
practical experience, not just theoretical navel-contemplation. For example,
the problem of logs of incorrect login/password combinations being a source
of useful information is worse than it seems: even just logs of login names
alone can be informative, because people do accidentally type passwords in
response to the login-name prompt now and then. For another example, aging
schemes that try to enforce frequent password changes have bad side effects:
"...the most incredibly silly passwords tend to be found on systems equipped
with password aging...".
The paper is "UNIX Operating System Security", by F.T. Grampp and R.H. Morris,
AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, Oct. 1984, pages
1649-1672. Any good engineering library will probably have the B.L.T.J.
(formerly the Bell System T.J.), since it is/was one of the top technical
journals of the communications industry. This particular issue, the second
special issue on Unix, can also be ordered from AT&T, although I don't have
ordering details handy.
Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
[While you are in that issue, you might just keep on reading. The paper
following Grampp and Morris' is also worth looking at: "File Security
and the UNIX Crypt Command", J.A. Reeds and P.J. Weinberger, pages
1673-83: "crypt" was not very secure. PGN]
Date: Wed, 5 Aug 1987 16:54 EDT
From: DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: Risks@csl.sri.com
Subject: Factory automation and risks to jobs — "apparently" not
From Risks 5.23: (Factory automation and risks to jobs — James Coombs)
The BIX report {on the effect of robots} was based on the work of Randall
Davis, a professor at the MIT Alfred P. Sloan School of Management and the
MIT Artificial Intelligence Laboratory. Apparently Microbytes Daily
interviewed Davis.
"Apparently" is the key word here.
First of all, the information about robots and their potential impact on human
employment is the work of Warren Seering (prof of mechanical engineering at
MIT and a member of the AI Lab). An accessible (and quite entertaining)
reference is his article in "Technology Review", April 1985 (pp 58-67); the
impact and cost figures are on pp. 66-67.
All of which I would have been happy to tell BIX, had they asked. They didn't.
One of the RISKs of giving talks in public is having magazines quote as if
from an interview (I don't recall an interview with BIX; I do use those
figures as one slide in a 3-day long course). This curious procedure is
apparently routine; it has in any case happened to me previously. The
practice is at best disingenuous, suggesting that they have conducted a
careful interview and summarized it, rather than picked a few entertaining
sentences out of several hours of lecture.
It also quite often results in misinformation, as in this case. When you have
an hour to explain a subject you do it one way; when faced with a reporter who
is going to reduce everything to single sentence pithy quotes, you proceed
quite differently (and quite a bit more carefully).
> Stephen Colwill <mcvax!praxis!steve@seismo.CSS.GOV>: > Secondly I fail to see how people who propose automatic control of > nuclear power stations and ATC can presume to do this when the > conceptually far simpler problem of the control of trains on a closed > railway network has not yet been solved after years of trying. I'm not sure I agree that controlling trains (actually operating them, as opposed to telling a human engine driver where she is supposed to go) is conceptually simpler than controlling a nuclear power station. A nuclear plant has a lot of sensors and actuators, in well known locations and required to be in well defined relationships to each other. A train is a large object whose position is only approximately known at best, whose speed is hard to change and is changed using systems whose performance is subject to wild fluctuations with age, maintenance, and track conditions, and whose surroundings are totally unvisible to the controlling system. I wouldn't argue that a power plant is easier to control or safer, but I think I would rate them similarly far beyond the realm of things I feel comfortable about yielding to fully automatic control. scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece
Other fora ("forums" for those under forty) are perhaps suitable for
expressions of political position regarding the mix of electrical
generation methods, including conservation. We must recognize that
substantial computer related RISK is attached to nuclear reactor
generated electrical power, and that little computer related RISK
is attached to other generation methods or to conservation. I am
disappointed that so little commentary occurs in RISKS regarding
computers as realtime control devices of nuclear power plants.
My interest in seeing more such commentary should not be taken as a
political position regarding the appropriate mixture of electrical
generation methods. We might indeed all learn something about
mishap and accident prevention methods by learning more about what
is done in the nuclear power industry.
It seems perfectly consistent for a professional in computer related
areas to on the one hand be interested in learning more about computer
RISKS in nuclear power plants and on the other hand to take any
position whatsoever regarding the desirability of such.
I remind RISKS readers of the issues of AAAS Science, and the articles on
risks and risk perception therein, which I cited on RISKS a few months ago.
In conclusion, I hope we might continue to see in RISKS contributions
regarding computer risks in the nuclear power industry, without thereby
attributing to either our Dear Moderator or to the Contributor any particular
stance on the desirability of nuclear generated electrical power. I would
prefer the politics to appear elsewhere.
David B. Benson
[Me too. (By the way, now this issue of RISKS has both fora and fauna.) PGN]
My credit union uses a PIN system that is designed in such a way that no one is supposed to be able to obtain the PIN once it has been sent to you. The PIN is generated "randomly" and pre-sealed envelopes are produced with the PIN printed on the inside via carbon paper, and a serial number is printed on the outside of the envelope. When the PIN envelope is sent to a card holder, the serial number of the envelope is entered into the computer and the serial number is cross-referenced to the PIN which is then stored in that card's record. If you forget your PIN number, a new envelope with a new PIN is sent to you, because no one can access the actual PIN, only the computer knows what it is. Of course, that is the theory, but I'm sure that someone somewhere can get to them given enough time. [MILNET TAC access cards are generated the same way from a dedicated non- net-accessible system managed by the Network Information Center at SRI. PGN]
In RISKS 5.22: mogul@decwrl.DEC.COM (Jeffrey Mogul) says:
> A friend of mine tried to withdraw money from a Versateller (Bank of
> America; she's a BofA customer). After asking her to re-enter her PIN
> several times, it told her to give up...
This happened to me when I needed cash for the weekend (on a Saturday morning).
From talking to the "ATM expert" at the credit union, I found out that the ATM
asks you three times to re-enter your PIN, then determines that you should
not be allowed any further transactions for the rest of the day. In my case
it had a blank line where my name normally is when it first says "hello".
The solution, according to the ATM expert is to immediately hit cancel when
the machine asks for your PIN a second time, clean the magnetic strip on the
card, and try again. This method has worked since then. I don't understand
why the ATM can't figure out that something is wrong when it reads the card.
Don't they use checksums?
Assuming an ATM will work properly when you need it leads to the
risk of being without any cash over a 3-day weekend. Now I only
use them to avoid a long line inside during business hours.
Scott R. Nelson, Evans & Sutherland Computer Corporation
UUCP Address: {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!nelson
Alternates: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!nelson
seismo!usna!esunix!nelson
Seattle Times, Wed. 8/5/87 (used without permission):
We knew it would happen eventually. Computers do this, computers do
that. Now, we're told, computers *assume*. M.G., a Bellevue consumer,
learned this when he tried to phone home from the Red Lion Inn at Portland's
Lloyd Center. He phoned several times and no one answered, but he was
charged for making long-distance calls. When he inquired about the charges,
he was told the hotel computer ``assumed'' he had made a connection and
talked with someone at the number he dialed. When M.G. explained to a live
desk clerk at the hotel that no one had answered his phone calls, the
charges were removed from his bill. M.G. suspects that many travelers pay
such phone charges without realizing they've paid to hear a brrr-ring, not
to speak with a real person.
Is this practice sanctioned by the Washington state Utilities and
Transportation Commision? M.G. asked. Hotel and motel phone systems are
private telecommunications systems, and are specifically exempt from
regulation by state law, according to Susan E. Sumner, public-information
officer for the commision. Sumner checked with Red Lion headquarters and
was told the hotel's computer equipment cannot determine whether a call that
has been placed actually has been answered. ``Consequently, in the first 45
seconds after a call has been placed, the computer `assumes' the call has
been answered,'' Sumner said.
The hotel's policy is to adjust the bills of guests who have been
charged for calls that were not completed. Red Lion's management has
indicated that printed notices will be placed by phones in rooms so guests
will know how they are being charged for these calls. It would be wise for
consumers to ask about this policy when checking into any hotel. Some
hotels and motels charge an access fee even when consumers use their own
credit cards to make long-distance calls.
Shelby Gilje, Times staff columnist
--Bruce Forstall ...!uw-beaver!uw-larry!forstall
[Old-time RISKS readers who are still with us after
two years may remember earlier discussions of this
problem, or by now might have forgotten... PGN]
Please report problems with the web pages to the maintainer