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…
The "Stars and Stripes" (a "small-town" newspaper in English for the military communities in Europe, to which I am also allowed to subscribe in order to read the comics every day...) reports that the payments for the civilian employees in Germany this month were credited to the accounts of the employees twice. Seems that the payroll tape is usually run on the 24th of a month. Someone bright noticed that the 24th is turkey day, and ran the tape on the 23rd. Some other bright person also ran the tape on the 25th since the 24th was a holiday.... Suddenly they noticed that there were about 3.5 million dollars missing (good thing they have a bookkeeping system!). The "turkeys" spent most of Saturday fussing with the system and rolling back the second set of transactions. It is reported that the civilians are hoping for another such windfall at Christmas... Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, 13353 Berlin, Germany weberwu@tfh-berlin.de <http://sun24.tfh-berlin.de:8000/dww/> [Beware of Tur[n]key systems. They can gobble up lots of money. PGN]
[Russell submitted a longish item on how his phone company cleared a check of his for $150, but did not credit his account. To make a long story short, he had changed his address and phone number from his parents' home, and the $150 was credited to his OLD phone number, which was the number that appeared on his check. His father did not notice the credit on the home account. Apparently his phone company ignores the number on the bill! GROAN. PGN] In other words, that little portion of the bill that you tear off and put in the envelope with your payment is completely useless, because they only check the phone number ON THE CHECK ITSELF. I don't know how many phone companies use this type of a system, but let this serve as a warning to anyone who has recently changed address... Russell Stewart Albuquerque, New Mexico diamond@rt66.com
On December 5, the {Dallas Morning News}, not the most technically-aware newspaper in the world, ran an article from the {San Jose Mercury News} about the recent Pentium FDIV situation. Unfortunately, they ran it through a spell-checker first. The company names "Intel" and "Megatest" became "Until" and "Megadeath," which actually puts an interesting slant on the story. I've only ever seen one writer's byline on computer-related articles in the DMN, so the root problem may be that no one else at the paper knows enough to catch this obvious (to us) error. Paul Fuqua Texas Instruments, Dallas, Texas pf@hc.ti.com [Until Megadeath Do It Part. PGN]
Interlocutor: Why did they call it "Pentium"? Mr. Bones : Because when they added 100 to 486, the answer was 585.994257
Mike Kenney <mike@wavelet.apl.washington.edu> wrote > As CPUs get more and more complex, the chance of bugs slipping through will > probably go up. I just hope whichever company it happens to next handles > the problem better than Intel. When Inmos designed the T8 series of Transputers, they used formal methods to prove that the algorithms used in the on-chip FPU were correct. I am frankly amazed that a huge company like Intel relies solely on testing the hell out of a new chip — which, of course, *proves* nothing. If a small British company like Inmos can prove an IEEE math FPU correct, why can't Intel? Perhaps this recent debacle will convince at least some people that formal methods can be cheaper than mistakes. Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown, Dorset, UK, BH21 7PP lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404 [We have not had any discussions on the appropriateness of formal methods in any systems, let alone critical systems, in a long time. Time to open up the Testing vs Formal Methods wars again? PGN]
I have been inundated with virus alerts. Somehow, this virus alert has been propagating out of control. It must be a virus in the virus alert. (Note: I don't mean to belittle the alert, but there must be some way of controlling its propagation. I have received it 4 times now from different sources.) >I have just received this message and been asked to take it seriously: >There is a virus on America Online being sent by E-Mail. If you get >anything called "Good Times", DON'T read it or download it. It is a >virus that will erase your hard drive. Forward this to all your >friends. >It may help them alot. [I suppose you are lucky you only got 4 copies. But it appears to be a complete hoax, as suspected by Rob Furr <rfurr@jazz.ncren.net>, who was amused at the close timing of the AOL message and Michael Slavitch's item in RISKS-16.60, and who added There are idiots in the world who think it's awfully funny to cry "Wolf" as soon as someone else notices that it's theoretically possible that wolves exist. Rob F. PGN]
> ``A subscriber site that does not honor the "Errors-to:" Except that "Errors-To" was introduced by sendmail, and is not in any RFC, 822 or otherwise. The 822 Police will arrest YOU for false arrest. :-) (The Risk in assuming the most popular implementation of a protocol is The Way Things Are. See also Return-Receipt-To:) The correct way is to set the envelope FROM to the bounce address. On those systems which don't have envelope addresses, it's up to them on how to preserve the bounce address in-band — which is where much of the problems with mailing loops get started. It's surprising the number of people (and therefore the number of misconfigured mailers and gateways) which don't understand the mail specs. However, it's understandable given that 822 and 821 are 12 years old and are probably one of the most cryptic and vague out there, especially considering how critical they are to the Net. They really need to be updated and clarified. Something like "Precedence: junk" is bad, because there's never any feedback to the system. Addresses which fail simply get tossed, and they never get removed from the list. The list grows linearly, and you waste more and more resources trying to deliver mail to addresses that go nowhere anyway. --Dave [Also noted by brian@nothing.ucsd.edu (Brian Kantor), who said, "If you can find errors-to in RFC822, you've got better coffee than we do."]
I am a unix system administrator at the University of Virginia and we regularly run across "abandoned" mailboxes that are growing rapidly with messages from busy mailing lists. This is particularly troublesome over the summer break and winter holidays. I have noticed that some mailing lists have what I call a "deadman switch" feature, whereby the listserver periodically sends all subscribers a message requesting that they confirm their subscription by replying. Anyone who fails to reply gets unsubscribed. When a user is unsubscribed in this fashion, the listserver sends a final message with instructions for getting back on the list. I think that some of these lists are smart enough to not send requests for confirmation to members who have posted to the list recently. I think that this is an excellent feature because many folks who subscribe to lists never figure out how to get off them or never bother. Some folks get a new account and never bother to deal with mail still coming to the old one. I encourage anyone who runs a high volume mailing list to consider using a deadman switch to ensure that mail is going to mailboxes that are actually being read. It would also help if mailing list administrators would regularly send out a brief message with information on how to unsubscribe. Steve Losen scl@virginia.edu phone: 804-982-4711 University of Virginia ITC Unix Support
BKAPCRYP.RVW 941012 "Applied Cryptography", Schneier, 1994, 0-471-59756-2, U$44.95 schneier@chinet.com %A Bruce Schneier %C 22 Worchester Road, Rexdale, Ontario M9W 9Z9 %C 605 Third Avenue, New York, NY 10158-0012 %D 1994 %G 0-471-59756-2 %I John Wiley & Sons, Inc. %O U$44.95 800-263-1590 fax: 800-565-6802 800-CALL-WILEY %O jdemarra@jwiley.com aponnamm@jwiley.com %P 618 %T "Applied Cryptography" For anyone who wants to study cryptography, you can save yourself a lot of time and effort by getting Schneier's book. From the simple Caesar cipher to RSA and beyond, there is nothing the book doesn't at least touch on. Protocols, techniques, algorithms, and even source code are included. A "Real World" section looks both at specific implementations and at the politics of encryption. Schneier notes that his work is *not* a mathematical text. It is difficult to say how much of a shortcoming this is for any given reader, but a safe bet is "not much". For those who do need more rigorous treatments of specific topics, the bibliography lists almost a thousand references, all of which are described and cited within the book text at some point. He also states that the encyclopedic nature of the book detracts from its readability. Not so. The work is both encyclopedic *and* readable. Schneier has done marvelously well with what is normally a dead and dry topic. His examples are ludicrously absurd--and therefore lucid and memorable. (He even uses Monty Python's immortal phrase, "My hovercraft is full of eels" in one illustration.) As course text, research basis or just a (serious) hobbyist's reference, this work is highly recommended. copyright Robert M. Slade, 1994 BKAPCRYP.RVW 941012 DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733
Please report problems with the web pages to the maintainer