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