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…
>From: Michael Travers <mt@media.mit.edu> Toronto, Canada: Archbisop George Cram enjoys a banana once in a while, but he's not the kind of primate that ape researchers had in mind. The University of Wisconsin's Regional Primate Research Center sent Cram, primate (senior archbishop) of the Anglican Church of Canada, a questionnaire while preparing an international directory of primatology. The envelope was addressed to "George Cram, Primates World Relief and Development Fund." The Reverend Michael Ingham, secretary for the senior archbishop, suggested in a letter of reply that "primates in your study are perhaps of a different species. While it is true that our primate occasionally enjoys bananas, I have never seen him walk with his knuckles on the ground or scratch himself publicly under the armpits," Ingham said. "There are a mere 28 Anglican primates in the whole world," he said. "They are all males, of course, but so far we have had no problems of reproduction." The research center's director, John Hearn, promised to strike the church from a computer database and added in a letter to Ingham; "In our zeal to develop a comprehensive directory, we have strayed on this occasion from the arboreal to the spiritual."
Date: 03-03-92 07:59:18 PM MEMO From: John Bartlett [WITH PERMISSION TO RISKS] I'm sitting on an American flight to Dallas working on a presentation for tomorrow and I can't believe what I've just been told. A flight attendant came over and politely said that it was ok to use my portable (Compaq LTE) on the plane but that according to a new regulation, I would not be able to use my mouse (Microsoft ballpoint)! I of course thought she was joking but apparently according to a new regulation only portables with a built-in mouse are allowed. She actually showed me the regulation which specifically states that mice with umbilical cords can't be used because of interference with flight navigation systems.. This basically limits the use of mice to Mac Powerbooks and a few obscure portables. Using Freelance without a mouse is just about impossible. I tried to argue that there wasn't any difference between a mouse connected with a cord and one that is internal. The flight attendant spoke to the captain in this instance let it go but all should be aware of this new American policy when flying.
The Wall Street Journal, "Apple Computer Backs Technology of Two Companies,"
by G. Pascal Zachary, March 4, 1992, states:
In connection with its support for data encryption, Apple said it had applied
to the U.S. Commerce Department for the right to export software containing the
technology, which is generally restricted as a sensitive technology. Apple
said it expects to receive export approval because the National Security
Agency, a leading agency on cryptographic policy, has reviewed the design and
raised no objections to it.
[The two companies are Adobe and RSA.
The Tail of Two Companies may wag the dog.
Apple's InCider? PGN]
Bargain Harold's, a local discount retail chain has just been petitioned into receivership by its creditors. 160 stores across Canada will likely be closed. There are several RISKS related reasons for this situation: - new management spent $15M on store refurbishment and on a computerized point-of-sale system with centralized inventory management. This was $7M more than was authorized by the companies creditors. - the companies immediate financial difficulties are being blamed on several factors including undetected errors in the new management information system. Apparently this system was incorrectly predicting gross margin on sales and profits. Based on this incorrect information management built up excessive inventories and were unable to reliablely predict the company's annual profit. A profit estimate of $500K on Oct 2 was changed the next day to a estimated loss of $3-4M. The projected loss grew rapidly over the next few months (currently $20M). Details on the reasons for the MIS system failure are not yet available.
I have not seen the Channel 4 TV program and cannot comment on the angle taken in that presentation. However, the impression I am getting from this forum is that the only protection mechanism for Sizewell B is the 100,000 lines of code software system, about which we could reasonably be concerned. I would like to point out that I have been led to believe that a secondary protection system exists that also has the capability of shutting down the reactor and that this secondary system is a more traditional hardware based system. Further, I have been told that these two systems are independent. So, before we raise concerns over the safety of Sizewell B, can we have all the facts relating to the protection mechanism and not just the worry over the software? Pat Place prp@sei.cmu.edu
Our moderator's comments about the potential fraud problems with AT&T's operatorless collect-call system reminded me of my one experience with it. I had to call AAA, for the obvious reason that the car I was traveling in had decided to fry its clutch, and they tell you to call collect. The conversation ran as follows: Me: [Dial 0 + number] Pleasant recorded voice: "...If you are making a collect call, please press `1-1' now." [or some such] Me: [Key 1-1] Voice: "Please say your name." Me: "Charles Olson" Voice: "Please wait while we determine if your call will be accepted..." [brrrring...brrrring.....] [click] AAA recording: "Thank you for calling | AT&T recording: "You have a collect AAA Emergency Road Service. We will | call from [my voice] Charles Olson. accept your collect call. If you... | If you accept this call, please... Me: "AAARRRGGGHHHH!!!!!!!" [SLAM!]
I snagged this one from the alt.folklore.urban group, but it doesn't seem to be
a legend, but rather a risks illustration. There are already lots of cars out
on the road, where the new owner has never bothered to file the change of
ownership (why you should always go with a buyer to re-register the car). But
a junkyard? How many states don't have any provision for the owner declaring
the car dead, but rely on a possibly unscrupulous junkyard to send in paperwork
(and/or plates)? Having sold a junked car myself, once, I wondered about
whether the change of title would actually be sent in, or if there was a black
market for plates. (My understanding of California law is that sending in the
"I've sold it" slip to the DMV does not actually modify the computer records on
the car. That must be done by title change. I have no idea what the procedure
may be in other states.)
Also, it brings up the issue of identity, when a car is "salvaged," and the
only witness who can establish an identity for the driver is a camera. In a
manned pullover, the cop asks for a driver's license and checks it against the
registration, and if the owner isn't in the car, that person had better have a
good story. There is no hope of catching a person who is operating a vehicle
illegally if the only enforcement is robotic.
Jane Beckman [jane@swdc.stratus.com]
Ghost Car Speeding? Photocop Snaps Auto `Retired' 8 Months Ago
By Stephen Hunt, The Salt Lake Tribune [last month sometime]
Susan Johnson laid to rest her 1984 Toyota Tercel eight months ago. The car
had 200,000 miles on it. When it quit running in June, she sold it to a
wrecking yard for $50. She was sure she'd seen the last of it.
But according to a traffic ticket Ms. Johnson received in the mail last week,
the car has been resurrected and is speeding about the streets of West Valley
City. The ticket says Photcopy — a computerized ticketing system that snaps
pictures of speeding carss — caught the car traveling 47 miles per hour in a
35 mph zone on Jan. 10.
Since the car was not even running last time she saw it, Ms. Johnson is
wondering how it could be breaking speed laws. "I was so surprised," she said.
She believes someone must be using her old license plates, which were left on
the car when she sold it.
According to Utah law, license plates are to be returned to the state Motor
Vehicle Division when a car is sold. However, once the title has been signed
and delivered to the new owner, the previous owner is no longer liable,
according to the DMV.
Ms. Johnson was to appear today in West Valley City 5th Circuit Court to deal
with the ticket. There, she will be allowed to see the photo and, she hopes,
prove her innocence.
Photocop uses radar, a computer and a camera to snap pictures of speeders that
show both the car's license plate and the driver. "I hope it's not someone who
looks like me," Ms. Johnson said.
Photo radar has become a controversy at the Legislature. Two bills regarding
the device are before lawmakers. One would limit the use of photo-radar to
school zones only; another would ban it altogether.
Opponents say Photocop smacks of Big Brother.
Imagine That!
Bert Nelson, Weber State University, bnelson@csulx.weber.edu
The Nova show on PBS last night (3 Mar 1992) was about banknote printing technology, covering the endless battle between the banknote printers and the forgers. One interesting item they mentioned in passing was that some new Dutch banknotes have a barcoded serial number, supposedly as a means of detecting forged notes, which would have a duplicated, or unused serial number. Whenever a batch of notes gets back to the central bank all their serial numbers are checked by computer. The RISKS of this are pretty obvious. Cash will no longer allow anonymous transactions. It would be a simple step for ATMs to make a record of the serial numbers of all notes they issue to each customer. It would also be simple and 'logical' for stores and supermarkets to use their bar code scanners to check the serial numbers of notes they receive (in case of forgery). The Police could also check the numbers of notes they confiscate in connection with crimes. Then citizens would have to explain why a bank note they were issued by an ATM at 08:31 on 1/2/99 was found on the person of a drug dealer at 11:20 on 1/2/99, while no stores have records of that note being spent in the intervening hours: "If you did not spend the money at an authorized retail outlet, what did you do with it, sir?" Barcoded bank notes was a pretty obvious step, but it seems to me that the unpleasant civil liberties consequences to us all far outweigh the benefits of catching a few forgers. Mark Gonzales
Safeway stores in the Washington area (and perhaps other areas) recently introduced a "Frequent Shoppers Club". By filling out a form which includes various demographic and financial information, you get discounts (typically 10%) on a few sale items each week (i.e., 10% below the price offered non-members). There's no cost to join the club. Safeway is obviously trying to build a database of buying habits which can then be resold to advertisers for targeted advertising. Many people are up in arms about "invasion of privacy". Safeway has a program now where every time you use your frequent shoppers card, you're automatically entered in a mini-lottery (to encourage use of the card). What strikes me as curious is that people don't seem to realize that the RISK is already there. With UPC scanners coupled with check cashing cards, there's already the opportunity to gather and correlate the information for a large fraction of the population. Are there any laws which prevent the grocery store from selling that information? The check cashing application forms don't preclude the store from doing whatever it wants with the non-financial information. Are there any instances of stores which actually do the correlation and resell the information? I'm also curious what reactions have been to these sorts of programs in other parts of the country/world. Jeremy Epstein, Trusted X Research Group, TRW Systems Division, Fairfax, Virginia +1 703/803-4974 UUCP: uunet!trwacs!epstein
The obvious solution to the DX-7 dilemma is to sample the patches used in the performance using a sampling synthesizer. Of course, something is lost in the process (especially if the timbre is modified dynamically). You could always sample the entire performance, of course, but then you may as well just roll a tape. The band Pere Ubu seems to have left its old Moog synth (knobs and patch cords and all) behind on the last tour, but not before sampling it into a slightly more modern synth.
Geoff Kuenning discusses the risk of not having DX-7s available to classical music in 20 years time. (Hmm, mine's about a third of the way there and still going strong). Anyway, it's really not that hard to do a DX-7 in software if you have the processing power. In twenty years, I'll expect my wristwatch to have that much processing power, if not my athletic shoe!
USA Today reports in Friday, March 6th paper that the Dept. of Justice is floating a proposal that would require phone companies to centralize phone tapping and make it easier for law enforcement agencies to listen in. They note that this would raise monthly phone bills for all consumers. Peter Wayner Department of Computer Science Cornell Univ. Ithaca, NY 14850 EMail:wayner@cs.cornell.edu Office: 607-255-9202 or 255-1008
The 6-Mar-1992 San Jose Mercury News has an article about this on page 5A. The
article is titled: "White House wants consumers to pay bill for better
wiretaps." According to the article, the Justice Dept. is worried that "the
widespread use of digital transmission, fiber optics and other technologies"
make it difficult for government agencies to intercept transmissions. The
Justice Dept. is proposing a bill which would direct the FCC to "devise rules
to give law enforcement agencies access to conversations for court ordered
wiretapping." Phone companies would then be required to follow the rules. The
bill would also authorize the FCC to permit the phone companies to increase
rates to cover the cost of implementing the rules.
The proposal has been discussed with Sen. Ernest Hollings, chair of the Senate
Commerce Committee which oversees the FCC.
Steve Dever
I've had a few second-order thoughts about the matter. 0) The Justice department seems to want to ensure that there is some place in the system where the signal can be easily turned into sound. It does not seem to prohibit individual people from encrypting their messages. It just means that the phone company needs to provide a tap. 1) Centralized phone tapping doesn't necessarily mean less privacy. I can imagine a huge bureaucracy at the local phone companies' tap center filled with mean clerks who would demand to see the proper forms authorizing the taps. "No, I'm sorry Officer. You didn't submit 44/22-G that authorizes the recording of conversations from another state that are forwarded to a third state by a central routing office without being delivered to the phone in your juristiction. A 44/22-F authorizes only cross-county juristiction expansion." Now each police department probably has its own set of mikes and tape recorders and can place them as it wishes. 2) I don't necessarily believe that the above will happen.
Recently introduced legislation may be of interest to RISKS readers. S. 2198,
the Intelligence Reorganization Act of 1992 and HR 4165, the National Security
Act of 1992, essentially give responsibility for all comsec to the National
Security Agency and for all information security to them also. This, of
course, would completely reverse, existing structure which has just been in
place for a couple of years, and apparently take much responsibility away from
the National Institute of Standards and Technology (NIST) in the Dept. of
Commerce and put it (back) at NSA in the Defense Dept.
If enacted, this would have important implications for export control and
crypto policy, which are of interest to many RISKS readers.
Lance Hoffman
Department of Electrical Engineering and Computer Science, The George
Washington University, Washington, D. C. 20052 (202) 994-4955
I spent the day today clearing many viruses. In the last week xxxx and I have cleared over 80 Michelangelos from .... Also, we have cleared many Cascades, New Zealands, Joshis, and others. Easily over 120 infections in the last week. You may have heard that just changing the date is an adequate defense; it is not. You may have heard that not using the computer that day is a defense; it is not. You may have learned many things; almost all of them untrue. All anyone needs to know is that Michelangelo is a very widespread virus. It is destructive. It can be removed only by using proper procedures. It is completely manageable and removable. Procedures: Detect the virus (Use any commercial or other package that is up to date) Cold Clean Boot (Turn off PC, insert DOS Startup notchless diskette, turn on PC) Copy first track into memory Copy partition table from virus (sector 1) into partition table of original (sector 7) in memory Copy original over virus in memory Zero the copy of the original in memory Write the result back to the first track. As you can see, nothing magic, just plain old careful procedure. Anyone who leaves a diskette in their boot drive by accident when they boot should have their wrist slapped.
In RISKS-13.21, jcav@midway.uchicago.edu writes about his local news station omitting to mention that the Michelangelo virus only affects MS-DOS machines. I submit that this really isn't much of a problem, for the following reasons: 1. MS-DOS users are actually affected by the virus, so in their case, the report was correct and useful. 2. Macintosh users have such a frightening virus problem already that there are very few left who don't routinely disinfect their machines. 3. Everyone else is either sophisticated enough to understand the situation, or has a MIS department to call and get straightened out by. A more serious problem is the entire area of media handling of Michelangelo. Why is this particular virus getting almost saturation-level coverage in the media? Is Michelangelo really any worse than Stoned, 1701, Jerusalem-B, or any of the other MS-DOS viruses that have been circulating lately? Even worse, will people assume that once they have scanned their disks for Michelangelo, that the threat is over? After all, the fuss has quieted down. Why should it be necessary to do it again? Internet: octogard!graham@deepthot.cary.nc.us BBS: +1 919 876 7213 UUCP: ...!duke!wolves!deepthot!octogard!graham WWIVnet: 1@9970
Here's another one for the "risks of posting to RISKS" file.
In RISKS-12.30, 11 Sep 1991, I wrote, concerning so-called beneficial viruses:
"...the idea of code roaming around in a network looking for
opportunities to do good is what we technical types call `way cool.'"
In _Newsweek_, 20 Jan 1992, John Schwartz writes, concerning virtual-
reality video games:
"When you shoot, your nemesis is blown to colorful smithereens--
a sight that is, to use a technical term, way cool."
It's just like William S. Burroughs said: "Language is a virus."
Brian Rice, DG/UX Software Quality Assurance, Data General Corp., Research
Triangle Park, N.C. rice@dg-rtp.dg.com +1 919 248-6328
Brian Randell describes how the Alpha uses imprecise arithmetic traps, and
speculates that it's a risk to program correctness. With all due respect, I
disagree. Based on my experience with imprecise interrupts on the 360/91, lo
these many years ago, I would classify imprecise interrupts as more of a hassle
when localizing faults, rather than any risk to the program's correct behavior.
That is, the interrupts — which typically signified erroneous program behavior
-- still happened, and still caused the program to abort. But it took rather
more debugging effort to figure out which instruction caused the trap. Unless
one is relying the interrupt handler to perform the appropriate fix-up — a
technique that I regard as far more risky and non-portable than imprecise
interrupts — correct programs should not behave any differently.
He also describes the barrier instruction as a ``sop to DEC's technical
conscience''. Not so. Its purpose is to help the programmer identify the
offending instruction. And compilers can (and were able to) generate such
instructions on appropriate boundaries. I recall vividly, 20+ years later,
finding that a zero- divide fault took place 11 instructions after the
offending divide, and after the divisor register had been overwritten with a
non-zero value. But it had to be that instruction; there were only two divide
instructions in the entire program, and the other referenced a still-intact
constant.
If there is a danger here, it's from the hardware design itself. Pipelined
architectures imply parallelism, of course, and that's harder to get right.
But the hardware designers seem to do a better job which such things than do
the software designers...
--Steve Bellovin
In RISKS-13.25 (Thursday 5 March 1992) Brian Randell writes about the new Alpha RISC architecture and comments on its imprecise arithmetic traps. Those of us who ever programmed the IBM System/360 Model 91 under OS/MVT (or, I'd imagine, other OSes) will recall that it, too, had imprecise interrupts, in large part because it provided (limited) pipelining and multiple issue of arithmetic instructions. I don't recall the details — it has been a long time -- but as I recall it could overlap integer and floating point compute operations, and perhaps did multiple floating multiplies in parallel. In any case, the careless programmer could easily get the dreaded 0C5 ABEND, along with a generally useless dump, when one of the parallel operations failed. IBM, in their infinite wisdom, did not provide a Trapb instruction to allow the programmer to force precise interrupts — at least, I don't recall any such instruction. Instead, if you couldn't guess what was wrong by looking at the code, you could carry it to a different System/360 model (like the Model 75) that didn't provide the parallelism and get a precise interrupt. What's neat about the Alpha design is, of course, that you can get precise traps when you need or want them, at some performance penalty, but you can go blazingly fast when you don't need that precision. Compared to other ways of addressing the problems implied by a pipelined multi-issue architecture, the Alpha approach seems rather clean and clever to me. But then, I may be biased, and I'm not an experienced computer architect. Dr. Thomas P. Blinn, Digital Equipment Corporation, Digital Drive — MKO2-2/F10 Merrimack, New Hampshire 03054 ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865
In RISKS-13.25 (so-called), Brian.Randell@newcastle.ac.uk seems alarmed at the notion of imprecise delivery of instruction exceptions. I was similarly alarmed when I first heard of them ... twenty-plus years ago, with the IBM System/360 model 91. (I'm not claiming the 91 was the first such implementation, simply that is was the first in my personal experience.) It is only sometimes useful to identify "the" instruction which blew up; usually a coarser localization will do. The imprecise-exception architectures I know of all provide an instruction which acts as a barrier, with the promise that no exception delivered after the barrier can be due to any instruction fetched before the barrier. The 360-91 used "BR 0,0": a "no-op" in the form of a pipeline-draining conditional branch. Compilers inserted this instruction at strategic locations like subroutine prologues and epilogues, or (if requested) between segments of code generated for different source statements. Imprecise exceptions make it difficult to write trap handlers which fix up the results of failing instructions. I have written such handlers, but have never found them satisfactory — the "correct" fix is too context-dependent to be dealt with by such a low-level approach. Error detection and correction work much better in the higher levels, and imprecise instructions don't make the superior approach impossible or even difficult. Eric Sosman eric@hq.ileaf.com Interleaf, Inc. / Prospect Place, 9 Hillside Ave. / Waltham, MA 02154
Please report problems with the web pages to the maintainer