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…
At a dinner table conversation last Saturday night, the conversation turned Apple Macintoshes. One novice user exclaimed how confusing the error messages can sometimes be. She explained that the first time she'd crashed her MAC and saw the dialog box containing the bomb icon she'd rushed out of the room, fearing an imminent explosion. "It was the little sparks coming from the wick of the bomb that really convinced me of the danger." I doubt WYSIWYG was meant to be interpreted so literally.
The era of the-24 hour electronic bank teller seems to introduced a new twist into robberies. According to various news stories appearing in New York newspapers today, the body of a 66-year old doctor, Dr. Esther Lim, was found in Brooklyn. An article in today's New York Newsday by Bob Liff quotes an unidentified ranking police investigator as saying, "She was serverely beaten over a period of time. It appears that they were trying to get information out of her. We're looking at the assumption that it was the secret code to her bank account." The article goes on to say, "Investigators suspect that the two men had staked out the money machine and picked out Lim as a target for robbery, thinking she had more than the $50 that bank records revealed she had withdrawn." "They may have attempted to take the [ATM] code fom her," [Police Captain] Flinn said. "She only had $50. Obviously you can get a lot more money than that from the bank." Robert Lehman, Columbia University
Some time ago, there was a discussion in this forum about changes being made without anyone being told, e.g. floating-point arithmetic being done by software instead of in hardware if the floating-point hardware is broken. Optimising compilers often make very clever changes to the object code they produce in order to make the compiled code faster or smaller. One common optimisation which makes the code smaller is to remove unreachable code. Has anyone wished that the optimiser had told him/her that a large chunk of a program was unreachable when the fact that it was unreachable was due to a fault in the program? Does anyone wish optimisers were more forthcoming about the changes they make? J. M. Hicks (a.k.a. Hilary), Computing Services, Warwick University, Coventry, England. CV4 7AL
Australia recently flirted with, then dropped, an idea something like this.
The card itself was not to be "smart," at least not at first, but was supposed
to be a general identifier to be used in most interactions between individuals
and government. The "Australian Card" scheme got as far as a publicity
campaign run by an advertising agency, with glossy brochures and mocked-up
cards for the press. The Australian Senate killed the scheme. The story is
told in Roger Clarke, "Just Another Piece of Plastic For Your Wallet: The
'Australian Card' Scheme," COMPUTERS AND SOCIETY 18(1) 7-21, Jan. 1988.
COMPUTERS AND SOCIETY is the journal of the ACM SIG on Computers and Society
(ACM/SIGCAS).
- Jonathan Jacky, University of Washington
"So far there has been no real rationale for Congress to
consider [a national identity card], but the recent immigration
law, which imposes fines on employers for hiring undocumented
workers, will create a nation-wide constituency pressing for
some reliable form of citizenship identification."
If an employer has made a reasonable effort to verify an applicant's
right to work (birth certificate or I-9 form), they are in no danger if
the applicant turns out to have used forged documents. This just
happened in Oregon; an African national was hauled off from his
janitorial job for using a forged I-9 (he faces a possible *20 years*
in prison) and nothing happened to the employer. Under current law,
employers have no strong need to see a national identity card, so I
don't think this nationwide constituency will form.
"Imagine if you will, a clerk on the premises Sunday afternoon.
He is only paid $30,000 a year or so, and an alarm is noted on
his console or terminal. He picks up a hand held cellular
phone, walks into the room down the hall, sees smoke and grabs
the Halon cannister from the wall. On the phone he dials 911 to
tell them. He starts spraying the Halon, and likely gets the
fire out before the firemen arrive. Then he calls a couple
other numbers on the phone to key employees to get the word
out: get over here fast."
Now imagine another scenario. The clerk dials 911 but nothing happens;
cellular service has already been disrupted by the fire (as in fact it
eventually was at Hinsdale). A ceiling caves in, or she's overcome by
toxic fumes, and she succumbs. A few months later, her family files a
multi-zillion dollar lawsuit against the telco.
Proper disaster planning eschews best-case scenarios.
> Even assuming a day shift at all offices, another 3 shifts are required
> to cover the remainder of the week...
Actually it's worse than that. 4 shifts aren't quite enough for a 168-hour
week, even before you allow for vacations, sick leave, and the inconvenient
fact that humans need to sleep roughly the same 8 hours in every 24 and
can't be rescheduled daily. The standard rule of thumb for all-hours jobs
like police is that filling one 24-hour 7-day position requires hiring five
full-time people.
Henry Spencer @ U of Toronto Zoology {ihnp4,decvax,uunet!mnetor}!utzoo!henry
In connection with the Hinsdale Fire discussion, Chris Maltby writes:
`What no-one is talking about ... is whether society (i.e. government)
has a role in ensuring adequate redundancy in as important a strategic
network as the telephone system. ... The decision to route all the
trunks through the same building is ... a typical commercial decision.'
When analysing the missing redundancy in the (government department) `Deutsche
Bundes-Post', I have severe doubts that government agencies provide less risky
behaviour than commercially competing (and thus cost-minimizing) enterprises.
It seems more probable that *big* organisations (of `society' or as
economically competing entities) behave less adaptive and thereby more risky
than smaller, decentralised organisations.
The German lesson: our DATEX-P network (a packet-switched DATa EXchange system)
has only on central communications controller per (usually metropolitan) area.
Though dataflows may be re-routed between the node systems, intra-areal
communication as well as entry into and exit from such an area is *controlled
by a single control system*. Despite many discussions and arguments (of
influential managers as well as computer security experts), the Post office
managers argue that today, redundancy does not pay (a typical *commercial*
argument). They simply hope (and wait) for better redundancy when ISDN services
are implemented.
Apart from central control over large, well protected databanks, I think that
decentralised systems provide for more effective, less expensive systems. Such
an organisation is independent of `society' (and also of government
organisation).
Klaus Brunnstein Univ.Hamburg Fed.Rep.Germany
Unix is not friendly - let's face it. However, the true RISK is not in the
unfriendliness, but in the wanton use of root privileges! Peter Rowell
shows a wonderful (sorry about that) example of this.
Rule number 1: Don't use "root" unless ABSOLUTELY necessary.
Rule number 2: When necessary, be DAMNED careful.
Rule number 3: When the slightest bit in doubt, don't use "root".
Dumps should be run as "sys", or some other non-priv userID. Disks should
be owned by "sys", and protected r--r--r--. This way, you can only write to
them when you make a conscious decision to do so. When doing a restore,
either manually change the protection on the SPECIFIC disk, or run as root
(since root automatically gets write permission). However, "root" should
only be used to restore (not to dump), and then only if you TRIPLE check your
command line.
As to your specific problem - agreed, dump should check for bogus arguments.
"/dev/rmtxx" should not have been accepted as a numeric argument. However,
there are times when you want to dump TO a disk device (i.e. if you are
dumping to a WORM device). Agreed, though, "default" disks and tape units
should be eliminated, or at least configurable on a per-system basis.
However, you should not have been running as "root" in the first place. Far
too many system administrators become enthralled with the power, and forget
the RISKS. Most system administration tasks can be accomplished with a
non-priv UID, with the system still being secure. Doing things from a
non-priv account will cause some initial conversion headaches, but will save
you from the BIG headaches when you make a small, 1 character error later on.
In the cited example, the worst that would have happened would have been an
error message "can't write to /dev/...", when dump failed to clobber your
disk partition due to the file protection bits.
Please report problems with the web pages to the maintainer