Did you hear about the problem that occurred when a leap second was added at midnight on New Year's Eve. Apparently, because of a mistake somewhere along the line, the leap second was added but the date was also inadvertently advanced to Jan. 2. I heard from a source at AP radio that the synchronization of their broadcast networks depends on the official time signal, and this glitch affected their operations for several hours until the problem was corrected.
You can't even count on the national timekeepers to get it right all the time! And the year 2000 is coming up fast.Ivars Peterson, Math/Physics Editor, Science News, 1719 N Street, NW Washington, DC 20036-2888 email@example.com 202-785-2255 Fax: 202-659-0365
The Cobb Group publishes INSIDE MICROSOFT OFFICE, a monthly newsletter for users of Microsoft office products. In their January 1996 issue, they address a problem already discussed at some length in the Risks Forum --- floating point expressions in spreadsheets like Excel 5.0 that do not evaluate properly. They say the problem isn't an Excel bug, it's a consequence of the IEEE floating point standard 754. Many numbers with exact decimal representations do not have exact binary representations; arithmetic operations on the binary approximations may not give the same results as the same operations on the decimal numbers. They suggest a "workaround" — wrap your floating point expressions in the ROUND() function — e.g., ROUND(0.3-0.2-0.1,5) will yield 0 rather than -2.8E-17.
This analysis, while helpful to spreadsheet users worried about the accuracy of calculations, is somewhat misleading. The IEEE 754 standard is an innocent bystander because the real problem, finite binary representations of decimal numbers, will happen with ANY binary floating point standard. The ROUND() function does not eliminate the problem, it only masks it behind a larger approximation error at the decimal level.
Modern spreadsheets are so powerful that any user can set up numerically intensive computations and invoke all the problems that specialists have spent years to learn to avoid. For example, if you are doing a capacity study of a client-server system, you are likely to want to solve balance equations of the form x=Ax, where x is a vector of unknown numbers and A is a matrix. It is easy to set this up on a spreadsheet and utterly amazing how difficult it is to get the spreadsheet's iterative calculation algorithm to converge to a meaningful answer. This one can't be helped by the ROUND function. A far better answer would be for the makers of spreadsheets to offer numerical libraries that contain numerically stable algorithms for various problems, and urge users to select those packages rather than attempt their own, homegrown solutions.Peter Denning
[What comes ROUND goes ROUND? PGN]
I tried to finger someone at Carnegie Mellon University, and got the following reply:
finger: No names match "jwebb" , 1 nearest match is:
Hooman Yaghoobi (hooman)
This was not done on April 1st, and I don't think that I connected to the Monty Python server by mistake.
I was quite impressed that the finger program considered this a 'match' at all, and am at a total loss as to what metric it could possibly be using. CMU CS department has a large number of people in it, so the chances of getting this match instead of some other would normally seem to be quite remote.
(BTW, Jon Bentley did his thesis on best matches using a Euclidean metric at CMU if I recall correctly, although I doubt that CMU 'finger' is using his algorithm. :-)Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html Copyright © 1996 by Henry G. Baker. All rights reserved.
[Well, at least "JWebb" and "Hooman Yaghoobi" have the letter "b" in common! Close enough for some purposes? PGN]
Peter Neumann's book "Computer-Related Risks" discusses some examples of problems with reproducibility and validation of computer simulations used to assess the safety of nuclear power plans. A story ("Maine reactor probe widens") in *The Boston Globe*, 23 Dec 1995, p. 17, adds some new twists. The story uses the phrase "it became clear that Maine Yankee had made widespread use of an allegedly inaccurate computer code to simulate accidents." The story gives me the impression that the charges are credible enough to have spurred action by the NRC. They are attributed to an anonymous whistleblower writing to Robert Pollard of the Union of Concerned Scientists, an organization to which I donate which can be vaguely characterized as "antinuclear."
The whistleblower alleges that "in 1983, Maine Yankee officials developed a computer code that help predict the plant's emergency core cooling systems would be `grossly inadequate' in the vent of a pipe break. Maine Yankee `refused to even discuss the
possibility' of upgrading the emergency safety system, and did not report the results. Instead... plant officials repeatedly modified the computer code over the next four years, but each `reasonable' computer-simulated accident had the same result: the
fuel got too hot to meet NRC standards... finally in May 1989, Maine Yankee told the NRC that their new computer code, known as RELAP5YA, showed the plant could withstand a pipe break without a serious accident... Pollard said the NRC's [resulting]
approval looks particularly bad because the agency had evidence
in 1989 that RELAP5YA was not a reliable computer code."
The RISK here is the popular presumption that anything that comes out of a computer is authoritative and objective, which made it easier for Maine Yankee, with the complicity of a lenient NRC official, to evade the purpose of the regulations requiring computer simulation. In addition, it appears from the story that Maine Yankee was in effect able to stall the NRC for at least five years by "claiming they were still working on the more sophisticated computer projection." When regulations are tied to the completion of a computer-related project it may be hard for officials to enforce deadlines because they recognize that big software projects are never completed on time.Daniel P. B. Smith firstname.lastname@example.org
Last Friday (December 30,1995), a Bavarian State Attorney sent police to Germany's CompuServe offices to close down any German access to the Internet via CompuServe for services offering child pornography. The legal prosecution was based on paragraphs forbidding distribution of child pornography. As CompuServe felt (technically?) unable to close such access exclusively for its (about 200,000) German customers, they decided to close such services IN GENERAL, also affecting its 3,800,000 customers world-wide. No other German provider of Internet access (e.g. T-Online, a service of German Telekom) were NOT prosecuted (their headquarter is NOT in Munich).
Following discussions in diverse newsmedia suffered from evidently missing knowledge about Internet in general and issues of responsibility of service providers. Though such aspects were internationally broadly discussed recently (e.g. the difference between responsibilities of a moderated group versus unmoderated ones), Bavarian police seemed rather unaware about such intricacies.
Apart from the risk of living in a country with censorship-friendly bureaucrats, a UNIVERSAL RISK derives from the fact that NATIONAL LAW is applied in a way to influence the UNIVERSE. As countries with different cultural values and legal principles handle "freedom of information" (FOI) aspects differently, laws of countries with strongest restrictions in FOI may dominate more liberal ones :-). This may also apply to Germany itself, being a federal state with hardliners (such as Bavaria, which even did not sign the Federal Constitution 50 years ago :-) and more liberal countries (esp. those where some national service providers reside :-) Moreover, some lawyers doubt that the ancient paragraphs concerned with distribution of child pornography may apply to electronic distribution.Klaus Brunnstein (Jan.2,1996)
Compiled from various wire services extracted from CompuServe's Executive News Service:
Cyberspace wiretap leads to arrests
UPI Northeastern US 29/12/95 14:46
By TRACEY L. MILLER > NEW YORK, Dec. 29 (UPI) — The G-men have started bugging cyberspace. > The U.S. Secret Service announced Friday that a court-sanctioned > wiretap on the Internet has led to the arrests of three people who > allegedly advertised the sale of illegal electronic surveillance devices > through the on-line service, CompuServe. > "These arrests offer a glimpse into what crime and law enforcement > will look like in the 21st century," Brooklyn U.S. Attorney Zachary > Carter said at a Manhattan news conference. "Criminals are adjusting to > new means of communications in the same way we are."
> The Department of Justice and the U.S. district court gave > investigators authorization to monitor the trio's outgoing and incoming > CompuServe E-mail messages, the first time permission for such a wiretap > over the Internet has ever been granted. > "This authorization was critical, since Bernhard and Rachel Bowitz, > and Gregory Brooks, perhaps believing that Internet communications were > immune from interception, spoke relatively openly in their E-mail > communications," said Brian Gimlett, who heads the Secret Service's New > York Field Office.
> "The significance of this case should not be minimized," said > Gimlett. "This case has substantially impeded the spread of technology > that would undercut law enforcement's ability to conduct effective > electronic surveillance, endanger the telecommunications and > international business community and intrude upon the public's right to > privacy."
> "The Internet has become the new battleground for law > enforcement to fight crime," said Gimlett.
While not life-threatening, this situation is definitely sanity-threatening when one is in a hurry.
I recently had to go to a local Star Market grocery store to purchase chicken stock. It turned out that the store was having a sale on chicken stock that day. Normally you might expect this would be a good thing from my point of view, but it added more than 5 minutes to my wait in the express checkout lane. Here's why:
As with most large supermarkets, Star has UPC scanners connected to price databases to speed checkout. They also print weekly circulars with coupons. They recently started a program called Star Advantage which uses a scannable card instead of coupons. You present the card to the cashier, and when the bill is totalled the system automatically applies any of the weekly coupons for items you bought.
[You're encouraged to present your card for all purchases, because you don't
always know if something has a coupon or not. The subject of the store building up a database of what you buy, when, and how you pay for it is a privacy RISK for a separate article.]
The checkout procedure has provisions for buying a large quantity of items at once. People often buy a case of something on sale, the cashier scans one item followed by "quantity 36" for example. People purchasing one or two cases of something often go through the express lane because the checkout is as fast as buying one or two single items.
Coupons must always be entered and printed one at a time, however. Herein lies the problem. The two people ahead of me in the line both purchased two cases of the chicken stock, and both used Star Advantage cards. It took only a few seconds to scan one can of stock and hit quantity 72. When the purchase is totalled, the computer applies 72 coupons to the sale. But the software knows it has to print all the coupons individually, so it starts cranking out 72 or 144 lines (coupons might require two lines) on the receipt. The register printers are fast enough to keep up with items being scanned individually. But at a second or so per line of text, it's a long wait for the cashier, the customer, and everyone in line when it's printing the coupon information.
This is an example of adding a feature without thinking through how it will be used. In the past, no one would pick up 36 circulars and tear out 36 coupons. Or if they did, they wouldn't consider going through the express line like that.
Using systems for something other than what they were originally designed for is one of the stock RISKs we see here. What seemed like an idea that would help customers could end up leaving a fowl taste in their mouths if they wait too long in the express lane. I'm almost chicken to submit this for fear of seeing what commentary PGN will add to this "Case of the Delayed Customer."-michael j. zehr
[Zehr gut, Michael, although if it were an Oriental chicken in Germany, my *stock* answer would be that you might have a Hahn Dynasty or Huhn-Nohs-Wat?, depending on its gender. We are Soupernuts? PGN]
At home I have a Unix workstation which I connect to the Internet using PPP from a service provider that gives me a dynamically assigned IP address. Yesterday when I connected I noticed that I was getting large amounts of incoming data over my low-bandwidth phone connection. I couldn't do anything through the connection.
After checking some log files, I found out that my machine was receiving dozens of mail messages. All of the messages were addressed for a machine called XXXXX.org [I put X's in place of the real name]. I did a DNS lookup on this XXXXX.org and found that its IP address was the same as my assigned address.
So my home machine was being sent mail messages from mail servers that thought my machine was XXXXX.org. To make it worse, since my machine knew it wasn't XXXXX.org, it would pass the mail onto a mail-relay host, but that mail-relay host would pass the mail right back since it still thought my machine was the right one.
Each piece of mail that my machine received for XXXXX.org would be passed back and forth 18 times, and on a slow phone-line this essentially stopped me from doing anything else.
The only thing I could do was drop the connection, reconnect with a new IP, and send some mail to a few sys admins.
This problem could have gone unnoticed for a while, since most people connecting with dynamic IPs are probably not running mail server software, so their machines would just refuse the connection and the mail would just stay spooled on the mail servers waiting for a machine that will accept a mail connection.
Another problem is that this could be used as a denial of service attack. You could send large amounts of mail to addresses you know are dynamic, and the next person to connect could be deluged.
I think the biggest risk from this is that I was receiving dozens of possibly private messages intended for someone else. Mistakes in configuring name servers or assigning IP addresses could cause anyone's mail to be misdirected.
I have spent some time trying to maximise the ability of a of a unix system to self-diagnose impending or actual insanity. Not a risk (or is it? ;)) but I thought risk readers might be interested in this software.Julian Assange EMAIL: email@example.com FAX: +61-3-9819-9066 - - - - - - - - - - - - - - - - - - - - - - - -
This is the first public release of LoadDog!
Please read the man page below for implementation and archive location details.
LOADDOG 0.90b(8) LOADDOG 0.90b(8)
NAME loaddog - system crash detection dead man's switch
SYNOPSIS loaddog [-d] [-l loadavg] [-m bytes] [-r retries]
loaddog monitors system vital functions and if they repeatably fail shuts the system down (if possible with one minute warning) and reboots. Nearly all possible fail- ure points within loaddog itself due to serious system malfunction are handled, from file system unmounting and syncing requests hanging to loaddog suffering from segmen- tation violations. Currently the following vitals are tested every 60 seconds:
system can create new processes
system can execute new binary images (/bin/date is used as the test program)
system can create new file descriptors
system can create new tcp sockets
system load average over the course of the last 15 minutes is within reason
system is scheduling correctly
system can allocate new virtual memory
If running under Linux-1.3.51+ Loaddog also supports Alan Cox's in-kernel software deadman's switch /dev/watchdog which will perform a hard (nasty) reboot should the system become so unusable that even the Loaddog daemon can't run.
OPTIONS -d Detach from the controlling tty.
-l loadavg The highest acceptable 15 minute loadavg. Defaults to 10.0.
-m bytes The minimum acceptable quantity of free virtual memory. Defaults to 2 Mb.
-r retries Do not consider the system terminal until retries consecutive vital failures have occurred. Defaults to 3 - that is three consecutive failures over three minutes.
loaddog -d -l 6 -m 2097152 -r 2
Julian Assange (firstname.lastname@example.org)
The latest version of this program can be obtained from the Suburbia archives at ftp.suburbia.net or ftp://suburbia.net/pub/proff/original/loaddog.tgz.
The timing attack presented by Paul C. Kocher in his extended abstract of the paper "Cryptanalysis of Diffie-Helman, RSA, DSS, and Other Systems Using Timing Attacks" (ftp://ftp.cryptography.com/pub/kocher_timing_attack.ps) is really worth consideration, however I would like to stress there is no need for panic, mainly for two reasons:
Let R = 1.
Let A = 1.
Let z = y.
For i=0 upto (bits_in_x-1):
If (bit i of x) is 1 then
Let A = (R*z) mod n
Let B = (R*z) mod n
Let y = y^2 mod n.
Let R = A.
to be resistant to timing attacks.
...and here's the explanation:
> From email@example.com Fri Dec 22 23:18:47 1995
> Date: Sat, 23 Dec 1995 00:14:02 -0600
> To: (TI&ME users)
> From: TI&ME Internet Information Service <<a href="mailto:firstname.lastname@example.org">email@example.com</a>><br /> > Subject: E-mail on TI&ME Internet Information Service
> Last night, Texas Instruments sent out a short one-time announcement of
> changes to the TI&ME Internet Information Service. The objective was to
> simply inform you about service improvements. TI sent only one copy of
> this e-mail to each user who had registered for this service.
> Unfortunately, a few users sent back an e-mail reply and also copied
> the mail list address. We did not anticipate that anyone would do this
> so we did not take the proper precautions to keep these replies from
> being forwarded to the entire mail list. We deeply regret that this
> caused you to receive extraneous e-mail as these responses were
> forwarded. We were able to pull the plug on sendmail this morning and
> stop the blizzard of e-mail.
> If you sent a reply requesting to be unsubscribed, we will honor that
> request. The TI&ME announcement we sent last night also contained
> instructions on how to do this yurself via http://www.ti.com. We wish
> to provide information via e-mail only to customers who request it.
> We sincerely apologize for our mistake that allowed you to receive
> multiple e-mail replies. We will take action to prevent this from
> happening again.
> Texas Instruments' Webmasters
>Convoluting matters further, in the Canadian and British militaries,
>lieutenant is pronounced 'lef-tenant' yet spelled the same. And the AF
>equivalent of a captain is a colonel, which is also not pronounced as it
>sounds because of a horrific entomological journey from Italian via French
>to English. ^^^^^^^^^^^^^
I think the intended word was "etymological", the study of of historical linguistical change. "Entomological" relates to the study of insects. Should we call this a "bug" or should we blame it on an overenthusiastic spellchecker (and not a spell checker). :-)Jake Livni firstname.lastname@example.org
[Yes, the error did seem quite suitable for RISKS. Correct spelling is a tough roach to haugh. PGN]
Sean Matthews <email@example.com> writes:-
> While this particular project may be a hoax, the inspiring idea is certainly
> not. Prof. Robert Kowalski at Imperial college in London is/was closely
> associated with a project to encode UK immigration law (so far as I
> remember) as an expert system of logic program clauses.
As a junior executive officer in the UK Civil Service (Home Office, Immigration Department) many years ago, my first wife had the job of responding to enquiries from abroad regarding immigration.
Her work consisted of reading each letter, selecting from a set of trays one of around 50 standard pre-typed replies, clipping the reply to the letter, and placing it in the out-tray from where it was taken to be checked by a more senior officer before being signed and posted.
It seems like *exactly* the sort of task that could be computerised, and would not even require a particularly "expert" system. In fact, any system with any real intelligence would probably do what my wife did after three days: crawl up the wall screaming and hand in her notice!Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422, Fax: +44 (171) 477-8585
Please report problems with the web pages to the maintainer