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…
I read this paragraph from Wired in EDUPAGE (listproc@educom.edu) and found the implications disturbing: IRS PLANS GOLDEN EAGLE TAX RETURN The project manager for the Internal Revenue Service's Document Processing System described the "Golden Eagle" return, in which the government would automatically gather all a person's tax info and then compute the tax. "If I knew what you've made during the year, if I know what your withholding is, if I know what your spending pattern is, I should be able to generate for you a tax return. I am an excellent advocate of return-free filing. We know everything about you that we need to know. Your employer tells us everything about you that we need to know. Your activity records on your credit cards tell us everything about you that we need to know. Through interface with Social Security, with the DMV, with your banking institutions, we really have a lot of information ... We could literally file a return for you. This is the future we'd like to go to." (Wired, Dec.'94, p.174) -John Sullivan sullivan@geom.umn.edu [For info on receiving EDUPAGE, see RISKS-16.58. PGN]
The Brisbane City Council's bus service here in Australia is in the process of introducing an electronic ticketing system on all buses. The old system used a bunch of "ticket pads" of different denominations: the driver would rip off a ticket from the right pad (you'd hope! :-) ), punch a hole in it, collect your money, and then give you the ticket. The new system replaces the pads with a console which has a number of buttons for the denominations together with a printer to print the tickets. There are also two green boxes just inside the door in which commuters can insert the new magnetically encoded weekly and monthly bus tickets to have them checked. I have yet to get my first magnetic monthly bus ticket so I can see how easy it would be to reprogram it, but I'm fairly confident that with the right equipment it is doable. For purely educational purposes of course. :-) RISK #1. I'm also interested in seeing if there is any identifying information on the cards permitting tracking of a person's movements. RISK #2. The other day a schoolkid was waiting at my bus stop, and due to various stuff-ups in the scheduling, he was forced to catch my bus rather than the normal school bus. During peak hour my bus is a full fare bus, but of course the kid only had money for a half fare on him. In such cases, some drivers are complete mongrels and won't allow the kid on, but most will grumble a bit and then let the kid on for a half fare. The driver stared at his console for a few seconds and then said (paraphrased) "There is no way to override this thing. Looks like you get a free ride today" and let the kid on for nothing. The console had automatically detected peak hour and disabled the half fare ticket buttons. RISK #3 is fairly familiar: while enforcing "the rules" can be a good idea, sometimes it is necessary to override them for reasons of human kindness. RISK #4 is that if an override button was provided, the console might log the fact and the driver might get in trouble (and then again, it might not: I don't know anything about the internals of the consoles yet). At least with the free ticket, no trace is left for the bus inspectors to whinge about. :-) More information on the magnetic tickets as it comes to light ... Rhys Weatherley, Queensland University of Technology, Australia.
In order to more closely stick to a self-imposed lowfat diet, I finally
broke down and bought a bread machine — easy quick bread with no added fat.
I was so pleased with the machine that I bought my breadophilic mother one
and lugged it across the country to her house last week.
They were short on counter space in the kitchen, so they put the machine on
a side-table and plugged it into an outlet that was activated by a wall
switch that also controlled a light in the room. (I think you can guess what
is coming next, and, yes, I did warn them. They said it was only a temporary
placement and they'd remember.)
Sure enough, in the middle of the bread machine's 4-hour cycle, my
stepfather turned off the light in the room (and thus removed power from the
bread machine). I noticed this some indeterminate time later.
Problem #1: The bread machine has no NVRAM. So I had no idea whether it had
been through only its first rise, or through a first rise, punchdown ("gas
squeeze out"; this was a Japanese machine), and second rise.
Problem #2: The machine has a dough setting that will allow you to make
dough, but not bake the dough. But there is no setting that says, "I already
have dough, I just want you to bake it."
Problem #3: Neither my stepfather nor I had ever baked a loaf of bread by
hand. Not once in our lives. And bread is quite a bit more sensitive to time
and temperature than most other simple food items.
Luckily, I had also purchased a bread machine cookbook for my mother that
suggested that one make a loaf of bread by hand first to get a feel for the
process, then proceed to using the machine. I used the book's baking
time/temperature settings and ended up with an edible loaf of finished
product. But, had we not had that book....
Curtis Jackson cjackson@mv.us.adobe.com
Along with Erik Heels (The Legal List), I own a list for law students discussion law & technology (StudentLawTech). We have just weathered a particularly disturbing incident, and would like some feedback on what has been done in the past with issues like these. The facts, as near as we can tell, are these: a user set his e-mail system to refuse mail from the list. The system generated a refuse message for the sender to notify the sender that the message had not been read. Since the list was the sender, this refusal notification was sent to the list. Because the e-mail system did not stamp the message with a "mailer-daemon" or some other appropriate flag, the list did not filter it out. The refusal notification was sent to the list. Because the original user was not set to nomail (opting, instead, to do this at his level, rather than at the list level), he received the refusal notification. This notification in turn produced a notification of its own. The loop was started, and multiplied exponentially. The system was not fully corrected until Saturday night, a full three days after the loops had begun. While we can't be sure, we think the total number of these looped messages prior to the fix on Saturday was near 1000 messages to each subscriber. Needless to say, many have unsubscribed from the list. In addition, countless law students are now faced with the annoyance of having to delete mass quantities of mail. Most worrisome, of course, are those that pay for incoming e-mail. So — has this happened before? If so, what systems were involved? How was the situation remedied? What were the consequences? Any advice is very welcomed. Replies by e-mail are preferred, but I will monitor this list. Thanks for your help! Rick Klau, Co-owner, StudentLawTech@Listserv.Law.Cornell.edu
>From the September/October 1994 (Vol 9, #5) issue of "Accessability", a
newsletter that came with my most recent statement for my cell phones.
Reproduced without permission. The flyer generally contains the typical
marketing hype about ways to use your cell phone "more productively" (i.e.,
run up a bigger bill). The following anecdote is quoted in its entirety.
AIRTIME - Your Cellular Success Stories
Greg Maida
Herkimer, NY
"We are in the craft business, and we use our NYNEX Mobile cellular
phone to transmit credit card charges. This has saved us a lot of brief,
because we are able to get credit card approvals within about 30 seconds.
The cellular phone gives us the convenience of a phone at any locations and
enables us to offer more purchasing options to customers."
***
What can I say? Why worry about sending your credit card over the
Internet, when this vendor will send it out over radio waves for you!
Just to add a little irony to this whole discussion, in the very same
newsletter, on the facing page, appears the following "tip":
"Remember to lock your cellular phone! You will reduce the risk of
incurring fraudulent calls if you phone is stolen. Don't consider this
precaution an inconvenience. Lock your phone whenever you park your car
with a parking attendant. If your phone can be removed, we recommend
carrying it with you when you leave the car unattended."
The only word that springs to mind here is chutzpah!
PG
[accessability
Marcia Williams Cromer, Editor
NYNEX Mobile Communications
2000 Corporate Drive
Orangeburg, NY 10962
(c) 1994 - All Rights Reserved]
Phone systems do not exist in a vacuum, nor is restarting them as simple as flipping a switch. In this case, there'd be diagnostics to make sure that nothing actually *was* burned out. Then reloading the phone database and configuration information. The information might include special features with each phone for caller ID, forwarding numbers, voicemail options, et cetra. Next comes routing information from the various neighborhood multiplexors to the central office. Last, but not least, you have to convince any other computer system you are connected with (long distance carriers, billing computers, ...) that your system is alive and well again. >Lessons: First, this failure seems to be a perfect example of the fact that >grounding problems are notoriously difficult to diagnose. Second, I suspect >that nobody involved in the design of modern ESS systems would have guessed >that it would take 2 hours to restore service after the fault was repaired. "You get what you pay for," may be the case here. A "small" town with one system has all or nothing failures. New York, on the other hand, can shunt calls over to other offices while one is restoring. Multiple redundancy is the most common "solution" to make a system fault tolerant. These are only the technological factors... A human factors: A new system having been recently installed: how many trained technicians did they have on hand, well versed in the new system lore? There's a fair chance a technician from the system manufacturer had to race out, and this accounted for a bulk of that time. Matthew C. Wetmore — ACM, c/o CSc Dept., California Polytechnic State Univ, San Luis Obispo, CA 93407 — USA mwetmore@galaxy.CSc.CalPoly.EDU
Some years ago I received a water bill from the Village of Shorewood in Wisconsin that was about 30 times too large. In my case also the problem was due to a failed repeater that mounted on the outside of my house and was delivered an electrical pulse each time 100 cubic feet of water was registered by the actual meter in the basement. The system had been installed over ten years ago and had (apparently) been missing pulses from the very first. No one had noted the slight decrease in billing until the system finally had a hard failure and reported no water use during a quarter-year. When the new repeater was installed it was manually set to agree with the water meter in the basement (Wisconsin folks are smarter than they are in Missouri) and therefore included all of the "ticks" missed over a ten year period. They all appeared on the next bill. Since we had, in fact, used the water that was billed there was no question we should pay. What was in doubt was just how much. Water rates had increased substantially during the period because of the inclusion of sewer costs within the water bill during recent years. Negotiation with the village over the question "how much water was used when" settled the issue. What's the risk? New machinery will soon enable more and more utility billing to be done automatically. Many of these systems will depend on repeaters for their data collection with the true numbers still available on more conventional meters located on site. My hundred dollar water bill will seem small compared to the complexity of just which owner/renter used the missing electricity after failed meter systems are fixed and their meters updated. Prof. Leonard P. Levine, Computer Science, University of Wisconsin-Milwaukee Box 784, Milwaukee, WI 53201 levine@cs.uwm.edu 1-414-229-5170
This week's "Eye-to-Eye with Connie Chung" is scheduled to include a segment on radio-frequency interference risks. I was interviewed by one of her crews, demonstrating an automatic cardiac defibrillator being messed up by a public-safety band walkie-talkie. Other examples reportedly include an electric wheelchair being spoofed by a cellular phone, aircraft instruments confused by PCs, etc. I haven't seen any of the tape yet, so I don't really know whether I want to be announcing this, but it's likely to be of interest to participants of this forum. Thursday night, 1 Dec 1994, CBS, 10pm EST. Jan I. Wolitzky, AT&T Bell Laboratories, 600 Mountain Avenue, Room 3D-590 Murray Hill, NJ 07974-2070 USA 1 908 582-2998 wolit@library.att.com
[Thanks to sidney@apple.com (Sidney Markowitz) for letting me see copyrighted Newsbytes material, which I have starkly abstracted. PGN] Steve Fleming, the reporter noted in RISKS-16.58 as responsible for the article on the "hacking" of BT's Customer Service System (CSS), has admitted that he himself was the unknown Internet hacker. ``Instead of gaining unauthorized access to the BT computers, he actually worked for a lengthy period of time (three months, according to Newsbytes sources) and was required to access the CSS computer system as part of his job. "I didn't realize how sensitive the information was, but I was horrified how easy it was to get into the system," he is quoted as saying in the London Observer newspaper.'' Fleming may be prosecuted.
in re: Mathew Lodge's posting in 16.58: I was wondering if this was going to make it into RISKS. I saw a TV report on the story (a re-use of an NBC story of the BBC story, apparently). There was the mention of the Internet, there was the use of the word "hacker", but there was, technically, no security system "breaking". Social engineering, definitely. Stupidity, beyond question. Loss of confidentiality, loss of privacy, yes, and again, yes. But no hacking, cracking or phreaking. Indeed, since the original informant is still unidentified, the word "hacker", even in its most debased usage, is extremely suspect. The risks as I see it, is that once again the public is being led to believe that evil and powerful "hackers" can invade even the most highly protected inner sanctum of one of the worlds best secured telecom systems. In reality the "keepers of the keys" have simply left the doors wide open. 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
Can't speak for Intel, but at Digital, our Alpha AXP processors are tested using psudo-random techniques which do exactly that. Random testing often finds interesting problems that would never be found by just writing specific tests. (The genetic algorithm folks can give lots of data on why this is so.) To implement the random method though, you have to code a entire simulation of the results that the CPU will produce. Unfortunately, as readers of this group will appreciate, occasionally the template that describes the correct response, or limiting the range to test will be itself in error. (Comparing a transistor model to a bad software model is a good example of the first kind of error.) Even if all is set up perfectly, I've seen cases where it took several weeks to expose a bug.
The problem I have with Intel's handling of this is the use of the word "chance", as if there was a random factor involved, that a calculation will work right one time and fail the next so you can just run it again and get the right result. Of course no such thing is true, but that's the impression Intel's (deliberately?) spreading. Also, people hear about a "1 in 10^10" chance and think it refers to some statistical probability that their system will have a problem, rather than a measure of the proportion of inputs that will (consistently) produce an invalid response. For programs that require double precision calculations and involve arbitrary input the "chance" of that program hitting the bug approaches unity. Nope... Pentium Bingo isn't a game of chance at all.
The chairman of the Computer Science Department at Hope College (when I was attending, and probably still), Herbert Dershem, told one of my early CS classes that, "any idiot can write a very fast sort routine, if it doesn't have to put the elements into the correct order." (That may not be an exact quote, but pretty close.) It looks like intel has figured out that they can write a very fast floating point unit, if it doesn't have to produce the correct results! Ron
For more information on the Pentium FDIV bug, and Intel's response, take a look at our corporate presence server (www.intel.com): http://www.intel.com/about-intel/press/andy-msg.html This message was also posted on various net newsgroups. Dale R. Call, Intel Architecture Labs
Andy Grove has asked me to post the following for him. Since it is the weekend and we are out of the office, I am posting from my home system. Richard Wirt Director SW Technology Intel Corp This is Andy Grove, president of Intel. I'd like to comment a bit on the conversations that have been taking place here. First of all, I am truly sorry for the anxiety created among you by our floating point issue. I read thru some of the postings and it's clear that many of you have done a lot of work around it and that some of you are very angry at us. Let me give you my perspective on what has happened here. The Pentium processor was introduced into the market in May of '93 after the most extensive testing program we at Intel have ever embarked on. Because this chip is three times as complex as the 486, and because it includes a number of improved floating point algorithms, we geared up to do an array of tests, validation, and verification that far exceeded anything we had ever done. So did many of our OEM customers. We held the introduction of the chip several months in order to give them more time to check out the chip and their systems. We worked extensively with many software companies to this end as well. We were very pleased with the result. We ramped the processor faster than any other in our history and encountered no significant problems in the user community. Not that the chip was perfect; no chip ever is. From time to time, we gathered up what problems we found and put into production a new "stepping" — a new set of masks that incorporated whatever we corrected. Stepping N was better than stepping N minus 1, which was better than stepping N minus 2. After almost 25 years in the microprocessor business, I have come to the the conclusion that no microprocessor is ever perfect; they just come closer to perfection with each stepping. In the life of a typical microprocessor, we go thru half a dozen or more such steppings. Then, in the summer of '94, in the process of further testing (which continued thru all this time and continues today), we came upon the floating point error. We were puzzled as to why neither we nor anyone else had encountered this earlier. We started a separate project, including mathematicians and scientists who work for us in areas other than the Pentium processor group to examine the nature of the problem and its impact. This group concluded after months of work that (1) an error is only likely to occur at a frequency of the order of once in nine billion random floating point divides, and that (2) this many divides in all the programs they evaluated (which included many scientific programs) would require elapsed times of use that would be longer than the mean time to failure of the physical computer subsystems. In other words, the error rate a user might see due to the floating point problem would be swamped by other known computer failure mechanisms. This explained why nobody — not us, not our OEM customers, not the software vendors we worked with and not the many individual users — had run into it. As some of you may recall, we had encountered thornier problems with early versions of the 386 and 486, so we breathed a sigh of relief that with the Pentium processor we had found what turned out to be a problem of far lesser magnitude. We then incorporated the fix into the next stepping of both the 60 and 66 and the 75/90/100 MHz Pentium processor along with whatever else we were correcting in that next stepping. Then, last month Professor Nicely posted his observations about this problem and the hubbub started. Interestingly, I understand from press reports that Prof. Nicely was attempting to show that Pentium-based computers can do the jobs of big time supercomputers in numbers analyses. Many of you who posted comments are evidently also involved in pretty heavy duty mathematical work. That gets us to the present time and what we do about all this. We would like to find all users of the Pentium processor who are engaged in work involving heavy duty scientific/floating point calculations and resolve their problem in the most appropriate fashion including, if necessary, by replacing their chips with new ones. We don't know how to set precise rules on this so we decided to do it thru individual discussions between each of you and a technically trained Intel person. We set up 800# lines for that purpose. It is going to take us time to work thru the calls we are getting, but we will work thru them. I would like to ask for your patience here. Meanwhile, please don't be concerned that the passing of time will deprive you of the opportunity to get your problem resolved — we will stand behind these chips for the life of your computer. Sorry to be so long-winded — and again please accept my apologies for the situation. We appreciate your interest in the Pentium processor, and we remain dedicated to bringing it as close to perfection as possible. I will monitor your communications in the future — forgive me if I can't answer each of you individually. Andy Grove
Please report problems with the web pages to the maintainer