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…
AOL's software just makes it easy to pick a `screen name,' any screen name (up to 5 screen names, in fact). For the record, I am Steve Barr, reachable at GingrichN, SarahBrady, BARRST, etc. @aol.com, barrst@iris.uncg.edu, and barrsx@turing.uncg.edu. AOL did seem to go through federal agencies. IRS, [B]ATF, CIA, and FBI were all unavailable. BTW, someone else registered BClinton@aol.com. Just a cautionary note. Now all you need to spoof mail is a credit card (stolen?) and a '10 free hours on AOL' disk. Steve Barr
John Markoff thought the following item might amuse some of you. >From: Mark Colan <Mark_Colan.LOTUS@crd.lotus.com> >Date: 14 Dec 94 12:42:23 ES >Subject: Oral Hackers > >from PC Week, 12/12/94, "Some Outrageous, and Not So Outrageous, Predictions > >PC audio's next push into the world of corporate computing will be dealt a >major blow when a disgruntled layoff victim at General Motors destroys >hundreds of hours of work by running through a floor of cubicles yelling, >"FILE! CLOSE! NO!" The tactic, which will come to be known as oral hacking, >obliterates unsaved work on speech-enabled systems by closing files without >saving.
>From the Dec 11 edition of the Ottawa Citizen: MONTREAL - Myopic weather observation machines installed at Edmonton and Dorval airports to replace human observers as a cost-cutting measure can't tell rain from snow and are being withdrawn from service. Marc Gelinas, a weather specialist at Environment Canada's St. Laurent office, said the machines also cannot tell when there are clouds above 10,000 feet. "At 6:15 PM Friday, it was completely overcast and snowing at Dorval but the automatic weather system issued a report saying there were only scattered clouds at 4,000 feet," Gelinas said. The system at Dorval airport has been providing pilots with inaccurate weather reports since it was installed Nov. 15. Humans will remain on the job at the two airports until the machine can produce accurate weather reports. But the equipment will remain in place at another 48 smaller airports across the country.
Here's an expensive little mistake: American Stock Transfer and Trust Co. of NY, which handles the stock dividend reinvestment program of Wendy's, recently gave out double dividends to Wendy's shareholders. The company had to reprint and remail account statements to thousands of investors nationwide. I don't know if those receiving dividends via check were given double stuff, if so, that would have generated additional headaches I'm sure. Charlie Trew
Those who build computational hardware or software have a responsibility to ensure that their artifacts produce correct results, because these artifacts are used in many applications, some of which are extremely critical to life or property. I can't imagine any valid excuse for shipping a CPU which deterministically gives incorrect results due to a bad algorithm or logical fault in its implementation. Computer arithmetic algorithms and math libraries are simple enough to permit complete verification by a combination of formal methods and exhaustive testing. Here's a story that illustrates the lengths to which it is possible to go. In the late 60's I worked in the PDP-10 group at DEC. Digital had lost a benchmark to its then arch-rival, Scientific Data Systems. It seemed that the PDP-10 square root routine was too slow. I rewrote the routine and speeded it up by 25%, putting the new result on the master disk for subsequent distribution. Part of my speed up included removing unnecessary rounding in the early steps of Newton's method. Being concerned that the resulting code might produce different results from its predecessor, I tested the mantissa processing code exhaustively, verifying in each case that the resulting value was less than one LSB off of the exact answer. I also tested all possible values of the exponent and sign fields. A very little formal work showed that the combined routine was correct. (I would have felt even better if I had had the several months of computer time to test all 2^36 cases directly.) I was prepared to swear that my new routine always gave the same answer as the old. As it turned out, this was NOT true. In exactly one case my new routine did a better job of rounding the square root to single precision. I found this out several years later when Mary Payne called my square root routine "brilliant". My rejoinder was that it was merely "lucky". It seems that Mary had been working to a stricter criteria than mine and wanted the rounding to always give the closest possible value. For a long time, Mary Payne was responsible for Computational Quality at Digital. She consulted in the design of processors or math libraries, or anything else which was likely to result in bad numbers coming out of Digital's computers. It seems most unlikely that the Pentium bug would have gotten past her.
As a postmaster at a large site, I have to say I have a real problem with mailing lists which have this "must actively resubscribe" feature. The feature assumes that all recipients of the list are live humans, who can interpret the resubscribe message and reply. That assumption is not always true. At our site, we encourage users to *not* subscribe to lists directly, instead we prefer to gateway mailing lists into our bulletin board system. This approach saves disk space, mail delivery time, and most importantly administrator time dealing with expired or abandoned accounts. When some list sends out a resubscription request, at least one reader of the associated bboard has to forward it to an administrator, who has to manually respond. This is a waste of expensive staff time. Many times, the subscription just expires and any user who later becomes interested in the list sees what incorrectly appears to be an inactive list. On a different topic: after spending some time composing a reply to the list-looping query in RISKS-16.59, including technical information as to what the standards state various mail agents should do in various situations. In 16.60, I read a reply by Peter da Silva which gave information on the topic that was in fact *completely incorrect*. Later I was horrified to find my name included in an editorial comment as having given a "similar response" on the topic. I suppose this is a RISK of RISKS; by contributing to an edited forum I ended up having my name attached to a position I completely disagree with. I hope the editor will post this retraction: it is my professional position that error (and other) notifications be sent to the envelope return path as the standards specify, that sending them to Errors-to: violates the standards and should not be done. [Yes, indeed. Sorry for the guilt by association. I try wherever possible to prune items with similar messages. Here I elided a little too smoothly. Thanks. PGN]
And here is a good example of not RTFM'ing before sending an alarm: >With all this talk about self extracting mail "viruses", a friend showed me >that in emacs (which I use to read mail, along with vm) has the ability to >self-extract elisp code. This feature seems to be turned on by default, and >it not only applies to mail read with emacs, but rather every file visited >(when the feature is on, of course). There are actually two mechanisms at work here. First, emacs supports a per-file variable initialization mechanism. Whenever a file is loaded, emacs scans the end of the file for a special section of "comments" which provide emacs with values to set in certain buffer variables. Enabled by default, this mechanism only allows literal values and so does not constitute any significant risk. In Emacs 19, lisp forms may be included as the value for certain variables, and a special 'eval' construct is allowed which simply evaluates its form. By default, emacs shows you the code and asks if it should be evaluated. The risk is that emacs is a very complicated product and generally requires a fair amount of configuration and customization to be usable by a power user. When a less experienced user sees the "cool stuff" that the power user does, he simple copies the power user's emacs configuration file. Unfortunately, the inexperienced user cannot read the file and so picks up many unwanted changes. If the power user made use of the 'eval' feature, he would probably disable the execution query; the inexperienced user would then be unwittingly susceptible to trojan attacks. Being the primary emacs disciple at my site, I am usually the one responsible for propagating annoying functionality to coworkers. To avoid this problem, I have separated the benign functionality of my configuration to a centrally available file for other users to execute. Dangerous or annoying customizations are stored in my local configuration file which other users no longer need to copy. Morgan W. Jones — morgan@algorithmics.com Algorithmics Incorporated, Toronto, Canada
I just received something that I guess was sent directly to the RISKS
digest LISTSERV remailing address, thus bypassing the normal moderation
process of mail sent to risks@csl.sri.com. If I'm correct, those of you not
receiving RISKS via the LISTSERV distribution did not see it.
It was an ad for some computer hardware. Some people have been sending
commercial e-mail messages to lists of mailing list addresses, ignoring the
lack of relevance of their ad to the lists' topics. That is called
"spamming" and is considered by many on the Internet to be antisocial
behavior.
This particular message apparently was sent from e-mail address LIONEL
GOLDBERG <actuary@ix.netcom.com> (But read RISK #3 below!). I contacted
netcom and was told that they have an explicit policy against spamming from
their customers' accounts.
RISK #1: The LISTSERV system used by RISKS for automating list distribution
on BITNET allows this kind of bypassing of the moderator.
RISK #2: If actuary@ix.netcom.com really sent this message to RISKS and a
bunch of other mailing lists indiscriminately, complaints to
sysadmin@netcom.com can lose him his account.
RISK #3: E-mail can easily be forged. The LISTSERV software conveniently
removed all traces of the actual path that the message took before it
arrived at the list server and was redistributed, so I could not tell if
the message was even a crude forgery sent from someone other than the
account in the "From" header. So please don't jump the gun in accusing
actuary@ix.netcom.com.
RISK #4: The ad asks for people to send checks or money orders, no COD or
credit cards, to some unknown company for unseen equipment. Anyone want to
buy a bridge?
RISK #4.9999721: Some of the items listed are Pentiums :-)
— sidney markowitz <sidney@apple.com>
[Comments from too many of you to name on this, including
some who got multiple copies, and some of whom got copies
from lists to which they are not even subscribed.
netcom has disabled the account. RISKS was not the only
list hit.
As you all know, the BITNET LISTSERV is wide open to the world.
I have no control over what goes gets redistributed, although
perhaps one of its wizards will change that soon? Perhaps
it should have been set up that ONLY RISKS can cause E-mail to
be distributed to the list, but that is not the way it works.
Occasionally some overly moronic individual spams our BITNET
readers. Perhaps the automated server that we are trying to set
up might induce some of you to switch over, although my system
does not really need the added burden... Stay tuned. PGN]
Please report problems with the web pages to the maintainer