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 full text of the cited message on the Pentium II bug is at http://www.x86.org/secrets/Dan0411.html (PGN Excerpting Service).] It would appear that there may be a bug in the floating-point unit of the new Pentium II Processor, as well as the current Pentium Pro Processor. Is it real? Is it serious? It appears to be real. The observed behavior contradicts the IEEE Floating Point Specifications, and Intel's printed documentation. However, I'm not a numerical analyst, and therefore I'm not qualified to comment on its seriousness or its implications. Instead, I'll present the facts herein, and leave the determination to you. The Facts I received e-mail from "Dan" who asked if I could reproduce what he thought was a bug in the Pentium Pro processor. I wrote an assembly language program that checked into the problem. I also ran the test on a Pentium-II processor that I had recently bought at Fry's Electronics, an Intel Pentium Processor (P54C), Intel Pentium Processor with MMX Technology (P55C), and an AMD K6. Sure enough, I came to the same conclusion as Dan: it looks like a bug to me. [John's entire note is Recommended Reading for RISKS Readers (R&R?). The rest of his note is omitted here. Approximately 140,739,635,839,000 floating-point numbers are affected. The Pentium, Pentium with MMX Technology, and AMD K6 microprocessors do not appear to have this problem. PGN]
> By Alexander Wolfe, EETimes (Via PointCast News and TechWeb, 28 Apr 1997) I have no doubt that there are bad no-name motherboards out there, but these kinds of articles are usually the result of clever marketing by someone who makes 'name' motherboards and wants to spread a little Fear-Uncertainty-Doubt (FUD). The idea is to find a single defective product, and then get someone in the media to make a mountain out of a molehill. Such articles usually indicate more that the 'name' motherboard people are starting to hurt financially, rather than that there are huge numbers of bad products out there. I hate to sound so cynical, but you have to ask yourself every time you see an article like this who stands to gain from it. The recent FUD fights over which kind of cellphone harms people the most show how gullible the press really is. Henry Baker ftp://ftp.netcom.com/pub/hb/hbaker/home.html
This is not a new issue. Anyone who knows hardware knows that "ripple" on power supplies are coming dangerously close to the actual clock cycles on these CPUs. We are going into an area of instability that is just a matter of materials. All semiconductor have this "ripple" element. It's kind of like when the electrons hit that material, at first they "bounce" around and create this short and tinny spike in the voltage wave. It's a very well known electronic effect. I'm surprised that we are only NOW beginning to discuss the limitations. Power supplies always start out as AC. We have to make them DC which is no easy issue. We use semiconductor to do this and they all have that aspect of bouncing and rippling at the front edge of the wave transformation. It may look like a One and zero to a programmer or square wave but to an analog engineer it's a slope with major vibrations on the font edge. The spikes are a physics commodity that we really can't fix yet. When those electrons go from that on off state they just vibrate and make a mess of our circuits. Joan L Brewer
>FROM: Mark Stalzer <stalzer@macaw.hrl.hac.com>, RISKS-19.13:
| ... When the Vincennes downed the Airbus, the Navy admitted they
| did it, held an investigation, axed the skipper, ...
================
The following newspaper story appears to contradict "axed the skipper":
>[UK] Manchester Guardian Weekly, 29 April 1990, page 8:
> "Gulf skipper honoured"
> by Simon Tisdall in Washington
>
> The captain of the USS Vincennes, the American cruiser which shot down
> an Iranian civilian airliner over the Gulf on July 3, 1988, killing all
> 290 people on board, has been awarded the US armed forces' second highest
> peacetime medal.
>
> Captain Will Rogers received the Legion of Merit "for exceptionally
> meritorious conduct in the performance of outstanding service as
> commanding officer" of the Vincennes in the period from April 1987 to
> May 1989, according to a navy citation issued in the name of President Bush.
>
> The Vincennes' weapons and combat systems officer, Lieutenant-Commander
> Scott Lustig, who was on duty in the ship's combat information centre
> when the airliner was attacked, also won two Navy Commendation Medals.
Jonathan Thornburg <bkis@island.net> (personal E-mail)
U of British Columbia / Physics Dept / <thornbur@theory.physics.ubc.ca>
[My recollection is that the final resolution was somewhere in between
Mark and Jonathan, perhaps a virtual axe? I hope someone can clarify for
the archives, although the issue is not directly relevant to RISKS.
(At least Mark's "axed" was not Ebonics, e.g., ``the Navy axed the skipper
a question.'') See also RISKS-8.74 and many other back issues of RISKS
in volumes 7, 8, 9 and 13 for Vincennes-related items. PGN]
In most places by building and electric codes there must be a shut off. That shut off must shut off all power sources including backup power. I remember an incident where a new employee at a local computer center shut off the power to the center. The required power switch was one of the familiar red large buttons on the wall. It was protected from accidental access by a plexiglass shield that you had to reach under and up into to press the shut off. However, by code it was located next to the main exit door. The guy thought it was the door open switch. Ray Todd Stevens Senior Consultant Stevens Services R.R. # 14 Box 1400 Bedford, IN 47421 (812) 279-9394 Raytodd@tima.com
I strongly suspect that the idea that the computer will get it wrong one time in 100 000 is likely to be based on an analysis of the application software. Even if this is correct (I'll leave aside the standard issues about who wrote it, who certified it, who decided whether or not to skip an extra week of testing because the Minister had to come and open the system next Wednesday, etc), it assumes that the underlying computer system is not contributing to the overall downtime. When I read that the Maas estuary has been cut off from the world because somebody changed the rules for daylight savings time, or installed a patch to the operating system, or dropped a paperclip in the keyboard, I'll have a small smile on my face, imagining the top manager of the port management company phoning the software consultants: "Remind me again why we didn't need the manual override ?". Even if all this were optimally arranged in the computer's favour, however, the numbers seem rather dubious. According to the newspaper article, the system analyses fresh data every ten minutes. Let us therefore suppose that it takes 144 go/no-go decisions per day. At that rate we can expect a false alarm closure once every 22.8 months on average. (I don't know what the cost to the Dutch and European economy of closing "part of" the port of Rotterdam for half a day unnecessarily is, but I hope that one such closure every two years has been costed in to the system's maintenance budget.) In contrast, humans running the system would probably have to make two decisions per day (each one eleven hours before the next high tide, presumably), thus having (if they get it wrong one time in a thousand) a false alarm every 16.4 months; so even by the researchers' own (suspiciously round) numbers, the computer is only 1.39 times more reliable than the humans rather than 100 times. And to return to a favourite hobby-horse of mine: how long is the barrier designed to last ? Is the computer system expected to last as long, and if not, with what (and how) will it be replaced ? How many changes to the software will be required per year to take into account land reclamation and other civil engineering works not yet planned, which change the dynamics of the water flow in the Dutch deltas ? Nick Brown, Strasbourg, France
Geert Jan van Oldenborgh <gj@ganesha.xs4all.nl> writes: >... humans will make a wrong decision every 1000 events, whereas the >computer is trusted to fail once every 100000 decisions. ... I wonder if these researchers have taken into account how many 1000's of decision events went into the design and test of this system?? These decisions are mostly made by humans! Even if the design and test phases were made by computers, what about the decisions made when these were programmed (remember the Hubble space telescope)? Someone should point out to the general press that only a *fully debugged* decision system may be 100 times more reliable than humans (if indeed it is), but that such an animal doesn't really exist. Amos Shapir nSOF Parallel Software, Ltd. Givat-Hashlosha 48800, Israel amos@nsof.co.il +972 3 9388551
I can well understand the astonishment caused by the US$345 fine. The reason, I believe, is that there is a bigger issue involved: What crime does a person in one country commit when the criminal activity is noticeable only in an other country. We don't have a legislation in this area (yet) and the court couldn't fine the phreaker for more than a minor offence. There are a number of interesting questions involved, such as 1 Which law book is applicable? 1a The law in the country the offending person performed the crime? 1b The law in the country affected by the crime? 1c The law in countries used to pass the criminal behaviour? Quite interesting questions, until (?) we have a common law on earth. Kurt Fredriksson, KFRE-konsult
Maybe you'll get a few hundred similar messages, but just in case I am the first: today I sent a message to a colleague X with an address of the form X@acm.org; the message bounced. I forwarded it to the contact at my Internet Service Provider: > I find the following bounce strange, since acm.org is a very famous and > widely used host. In fact, whois knows about it: [...] > I have no idea what this can be: a problem at acm.org, a problem at > [the ISP], a problem in-between, some general temporary problem on the > Internet? The ISP's answer: !!! Here's the problem (from the "whois acm.org" output): !!!> Domain Name: ACM.ORG !!!> Domain Status: On Hold !!!> They didn't pay their Internic bill, so the domain was shut off for !!!> non-payment... Not much anyone (except the holders of the acm.org !!!> domain name) can do about it, sadly. So here it is: the oldest computing society in the world, associated in the minds of many people with names such as von Neumann, Eckert, Mauchly etc., gets kicked out of the Internet for failing to pay a yearly fee which, unless I am mistaken, currently amounts to $50. The other possible explanation is that Internic is the culprit. Given some of what I have read in the press about the management of domain names, that is not impossible. Again unless I am mistaken, lots of people, including some very well-known computer scientists, choose X@acm.org, for some X, as their e-mail address. In fact a friend Y from Australia just wrote to me that since he would likely be changing jobs once or twice in the next few months he was using Y@acm.org as his "permanent" address. -- Bertrand Meyer, ISE Inc., Santa Barbara, <Bertrand.Meyer@eiffel.com> [The ACM HQ folks seem to be off on retreat this week, so I could not get an official comment, but my e-mail later in the same day went straight through to acm.org. Perhaps Bertrand expects e-mail to be reliable? (What a joke!) I sometimes get *SEVERAL HUNDRED* transient bounces on a single mailing of RISKS, many hard bounces that are only temporary, and many more new cases of "address unknown" just since the previous issue. It sure makes moderating a newsgroup a lot of fun (not to mention the recent day in which I had to field over 40 spam messages as well). PGN]
I just received a junk e-mail inviting me to submit my signature, on paper, to an outfit who claim they will turn it into a Truetype Font so that I can include it in documents. Payment is, of course, by credit card. The risks seem pretty obvious...... John Elsbury (elsbury@ibm.net, jelsbur@clear.co.nz). [Several folks remarked on this. I received four copies of that one myself. But this type (!) of operation has been around a long time. Another company was hustling similar stuff early this year. PGN]
At another place, I work for another company answering Technical Support telephone calls for an Internet Service Provider. We allow people to register for the service by loading an automated installer program, which then, when finished installing the software, allows them to dial into the registration server to choose their username and password. I got a call from a woman who is not a user of the service, but a victim. In order to explain the entire situation I have to give almost the full number, however I have changed the number here - and not giving out her area code - in order to protect her privacy. The woman called, not because she is trying to use the service, but because people trying to use the service are calling her! Or rather, their computers are calling her, virtually any hour of the day or night. The woman's number would be something like 701-8001 in this example. Apparently, people's computers are calling this woman's number instead of our registration server. This doesn't make any sense, because in order to register for the service, a user's computer will connect to the registration server by dialing a toll-free number. For the purposes of this demonstration, I'll pretend the registration server's number is 800-123-4567. Had her number been the same as the last 7 digits of the number I could understand that it's somehow missing the 1-800, but her number is completely different from the number of the registration server even without the area code. The software to set up registration is fairly telephone savvy, allowing people to pick things like whether they have tone or pulse, if they dial a number such as "9" to get an outside line, or if they have to disable call waiting. If they select "disable call waiting", it is smart enough to give them the *70 code and even allowing them to change it if, for example, they have pulse dial. That's when it hit me. Consider the registration server's number with a cancel call waiting code, only don't put in the star, and you get 70-1-800-1 which is the woman's number. (The rest of the 800 number, which in this fictitious example is 234-567, would be ignored by the dial switch.) The *70 code for cancel call waiting, followed by the 1-800 number being dialed, only the star key got lost! As a result, some people are using the cancel call waiting code but somehow the star is not included. The woman felt a little better when I explained to her why she was getting these calls, and I said we would look into the problem and try to fix it. But it's interesting how a small and tiny error can cause someone major headaches. Or in this case, some poor woman whose number matches a misdialed call waiting code and a computer 1-800 number becomes, in effect, 'road kill' on the 'information superhighway'. Paul Robinson <foryou@erols.com> (formerly PAUL@TDR.COM)
In catching up on my overbloated mailbox last week, I found a message from one of the larger e-mail address database companies. I'd registered myself there, and found an old friend through their system. This message was a newsletter; the usual kind of thing, talking about itself and attempting to be useful. One little article talked about how I'd "never have to use my password again" with regard to their site. My ears went up; I continued on. It said that with the simple URL included, I wouldn't have to enter my password any more. No password? The example URL for their site was standard HTML hieroglyphics, *with my password right in the example URL*. It suggested that if I bookmarked it I could use this and not have to worry about my password ever again. ...After climbing back into my chair, it occurred to me that they really hadn't a clue about things: - They sent my password IN CLEAR TEXT over a completely unencrypted communications protocol. - They *knew what my password was*. It wasn't stored in any safe form--it's quite probably in raw ASCII in their database along with the other information about me. The RISKS here as I see them: 1) Don't make the assumption as I did (but won't any more) that when ou offer a service a password they'll know how to take care of it. 2) That the entity you're using will understand proper security measures in general.
I overheard this in my local Blockbuster video store:
Assistant: "John, tell me your password so I can log you on".
John: (shouting halfway across the store) "One Two Three".
I suggested John change his password ASAP. What's the betting it is now 321?
Mike Wilson Reading, Berkshire, UK REA03 mrw@oasis.icl.co.uk
at home: mrw@plexus.demon.co.uk http://www.plexus.demon.co.uk
[I'd bet it is STILL 123. THEY probably don't care. It's YOUR information
(credit card, rental records, etc.) being protected, not THEIRS. PGN]
If you are thinking that far out, there is the 2106 problem. Sometime in January 2106 the UNIX epoch ends. This is because 2^32 seconds from 1970 is 2106. Some UNIX systems are even worse off, they use a signed integer for time meaning that they fail in 2038. The sliding window approach is the one I adopted back in 1983 when I last worried about the millennium bug. The software in question was being asked to do long range forecasts. The database formats were pretty much cast in stone. The cost of the hack was a couple of days of my time, the cost of the perpetual solution probably a man year of effort. It would be better use of my time to port the database to a new platform altogether which is what I suggested. This cause problems as the client did not like my benchmarks that revealed that their mainframe database was using bubblesort and that the database schema could be converted to dBase3 format. Phill [The Unix expiration (Mon Jan 18 22:14:07 2038 EST) has been noted previously in RISKS-16.71,77,78,79,84. PGN] ADDED LATER BY Phill: It's an easy fix to convert to use unsigned integers for time and this can be automated. Thus, the 70-odd year extension is not too difficult to obtain. But changing the word size is a very different matter. Some of the cobol Y2K firms spend their time simply eking out an extra 60 years by making the MSB of the field a hex digit rather than a decimal. It's cheesy, however. HTTP has a deca-millennium bug which cause the cache scheme to fail in 9999. I don't think we need worry too much about this.
ISESS 97 WORKSHOP ON COMPUTER RELATED
STANDARDS AND SAFETY
Conference webpage : http://nssc.llnl.gov/SESI/ses97
Workshop webpage : http://www.dcs.qmw.ac.uk/~victoria/isess97prog.html
Draft Programme [breaks and breakouts omitted for RISKS]
Monday June 2nd, 1997
* 13:30 V. Stavridou, Introduction.
* 13:45 D. Lawrence, Keynote address.
* 14:15 H. Daniel, Software, Safety, Security: Separate Communities!
Common Concerns?
* 14:45 H. Gecht, Software Safety Standards in a Quality of Service Framework.
* 15:15 Panel: Software vs System and Sector Specific vs Generic Safety
Standards.
Tuesday June 3rd, 1997
* 8:30 R. Bell, Presentation on 1508
* 9:00 V. Stavridou, UK DefStan 00-56 Update
* 9:30 Panel: Evaluation, Proliferation and Harmonisation of Emerging
Standards, R. Brill, Chair
* 11:00 J. Gill, How to Execute and Effective Software Safety Program
across the IPT
* 11:30 M. Joseph, Role of Software Development Assurance in the
Development of the US Oceaninc Automation System
* 13:30 J. Halvorsen, Software Safety = Safe Medical Products
* 14:00 J. Voas, Software Fault Injection: A Crystal Ball for Software
Risk Assessment
* 14:30 Panel: Testing Safety Related Computing Systems in Existing and
Emerging Standards, H. Hecht, Chair
Victoria Stavridou, CS, Queen Mary and Westfield College, University of London,
London E1 4NS, United Kingdom (+44) 171 975 5242 victoria@dcs.qmw.ac.uk
Second International Workshop on
Formal Methods for Industrial Critical Systems
ERCIM - FMICS; UNIVERSITY OF BOLOGNA; CNR - AREA RICERCA PISA
CNR/CNUCE CNR/IEI; CPR/PDCC; SASIB Railways
CESENA (Italy)
4-5 July 1997
PRELIMINARY PROGRAMME AND CALL FOR PARTICIPATION
The Second International Workshop on Formal Methods for Industrial Critical
Systems will take place in Cesena, close to Bologna (Italy) as a Satellite
Workshop to the 24th International Colloquium on Automata, Languages, and
Programming, ICALP '97.
The aim of these workshops is to provide a forum mainly for, but not limited
to, researchers of ERCIM Sites, interested in the development and use of
Formal Methods in the Industry. In particular, these workshops should bring
together scientists active in the area of formal methods and willing to
exchange their experience in the industrial usage of these methods. They
also aim at promoting research and development for the improvement of formal
methods and tools with respect to their usage in/interest of industry.
Please notice that the workshop will be held in conjunction with the Second
International Workshop on Advanced Intelligent Networks (AIN'97)
WORKSHOP http://fdt.cnuce.cnr.it/~latella/FMICS/WS/Cesena97/workshop.html
REGISTRATION http://www.cs.unibo.it/icalp97/Icalp_registration.html
HOW TO REACH Cesena http://poseidon.csr.unibo.it/ain/
The full text of the two-volume Presidential/Congressional Commission on Risk Assessment and Risk Management final report is available at http://www.riskworld.com, the Internet address of the on-line publication RiskWorld. The commission's long-awaited report is expected to have a major impact on how the federal government uses risk assessment and risk management in regulatory programs. To access the report's HTML or PDF versions and other information relating to the commission, including its mandate, a list of commission members, the draft report, and seven supporting reports, open http://www.riskworld.com, click on "front page," and click again in the box labeled "Commission on Risk Assessment and Risk Management." Launched in November 1995, RiskWorld provides on-line news and views on risk assessment and risk management. Examples of current postings in RiskWorld include: --the testimony of Harvard Center for Risk Analysis Director John Graham before the National Transportation Safety Board on the results of his most recent cost-benefit analysis of vehicle air bags that found serious problems with passenger-side air bags, --abstracts from the combined 1996 Society for Risk Analysis and International Society of Exposure Analysis Annual Meeting and from the SRA-Europe 1996 Annual Meeting, --job openings in the risk community, --a calendar of risk-related events, --a listing of risk-related courses and workshops, and --a listing of risk-related web sites. To request information or to contribute suggestions or information to RiskWorld, please contact RiskWorld Editor Lorraine Abbott by e-mail abbott@usit.net, telephone (423) 691-0176, or fax (423) 691-0229.
Please report problems with the web pages to the maintainer