*The Washington Post* 13 Sep 1996 reports that a software error caused the wrong lottery numbers to be distributed to the state's 3,800 outlets. More than 22,000 people successfully bet on one or more of the numbers, but threw out their tickets thinking they lost. Others mistakenly thought they had won. Getting one or two numbers right gets people $1-$5, although two people bet numbers entitling them to $5000 in this six-state lottery. The firm, which recently won the contract to run Maryland's lottery games, stated that the numbers were correctly entered, but two of the six numbers were altered in the transmission process. A spokesman said, "To the best of our knowledge, it was a software error." The Post noted that the firm recently lost its contract in Arizona due to computer problems. Evidently, one of the RISKS is getting bad press. Scott Lucero
Courtesy of Associated Press via CompuServe's Executive News Service: Engineer Killed <> HUNTINGTON BEACH, Calif. (AP, 13 Sep 1996) — A spider may have <>tripped a motion-sensitive alarm, and a police dog was out sick. <>Authorities say the combination led to the accidental killing <>of an elderly man. <> On another night, a police dog instead of an officer with <>pistol drawn would have searched the darkened manufacturing <>business where 77-year-old Theodore E. Franks was shot and <>killed Wednesday. o Dogs normally check our burglar alarms, but police were down to one dog, and that dog was sick. o Third alarm in seven months, second in 48 hours. o Franks living inside the company so he could work during the hours he otherwise would have been commuting. [DMK: Inverse telecommuting?] o Police officer checking building found Franks unlocked room, entered, was startled by Franks and accidentally shot him in the leg. Shot him in the femoral artery. Franks died of exsanguination before he could reach the hospital. <> "After hearing the facts, I think it's pretty obvious this <>was an accident," Wayne Franks said after visiting the office <>where his father was shot. <> [Alarm Company] checked the alarm system Thursday, <>telling company owner [name deleted] a spider probably set it off, <>The Orange County Register reported Friday. <> "I feel bad. It was my alarm," [name} said. "That damn spider." Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
According to an interview with Margot Kidder in People Online, a computer virus was the last straw leading to her nervous breakdown. The virus (not identified) on her computer destroyed files, including the book she had been working for three years. Having, apparently, no backup copies, the entire work was lost. This loss triggered her widely reported nervous breakdown. Must go and back up this message before I post it.... Donald Mackie FANZCA FRCA, Middlemore Hospital, Private Bag 93311, Otahuhu, Auckland, New Zealand ph +64 9 276 0000 email@example.com
The primary network that serves Minnesota (the Minnesota Regional Network) was cut off from the Internet for 12 hours today [15 Sep 1996]. (My understanding is that *all* major nets and systems, private and public, in Minnesota ultimately get their connection to the rest of the world through MR.Net.) Following are the initial announcement that they had discovered they had been cut off and the final announcement indicating service had been restored: > Date: Sun, 15 Sep 1996 10:35:22 -0500 (CDT) > To: all@MR.Net > Subject: NET-DOWN: MRNet isolated from rest of Internet... > > Greetings, > > MRNet has become isolated from the rest of the Internet. The T3 line to > InternetMCI is up, but we are not receiving the routing table. We have no > details on what happened, or the extent of the problem. InternetMCI is > working on the problem, currently they do not have an estimated time to > repair. According to MRNet's network monitoring we have been isolated > since about quarter to 6 this morning (Sunday). > Date: Sun, 15 Sep 1996 19:28:36 -0500 (CDT) > To: all@MR.Net > Subject: NET-UP: Routing restored from MCI > > Greetings, > > MCI routing was restored at 19:15 today. Downtime was over 12 hours. > MRNet will be checking routing tables to see that we are getting most of > the routes we should, and will be spot checking networks to make sure that > our routing announcements are getting out. > > There has been no official word from InternetMCI as to the specific cause of > this outage, or why it took more than 12 hours to fix. MRNet will be > following up with InternetMCI to get an explanation on Monday. FURTHER MESSAGE FROM TED: Date: Mon, 16 Sep 1996 16:53:53 -0500 >From: tmplee@MR.Net (Theodore M.P. Lee) Subject: Minnesota Cut Off From the World For 12 Hours! This morning's paper [16 Sep 1996] here in Minneapolis had a bit more on it -- the head of MR.Net said he had heard of problems as far away as Seattle and Atlanta. I was out all day and if there has been an explanation MR.Net hasn't sent it out. Probably no point to adding this to the RISKs item until an explanation is forthcoming. >Yesterday, the Downers Grove node of CICNet (much of the Big 10, plus >Notre Dame, the University of Chicago, and other schools) was also cut >off from the outside world by InternetMCI... perhaps it was a related outage. > >John R. Grout Center for Supercomputing R & D firstname.lastname@example.org >Coordinated Science Laboratory University of Illinois at Urbana-Champaign
I was looking at VeriSign's web page, in particular their Certification Practice Statement (CPS). <URL:https://www.verisign.com/repository/CPS> Buried among the legal gobblygook, I found the following: "the certificate is being used exclusively for authorized and legal purposes, consistent with this CPS," from Section 7.2.(v), Representations by Subscriber Upon Acceptance, and "By accepting a certificate, the subscriber assumes a duty to retain control of the subscriber's private key, to use a trustworthy system, and to take reasonable precautions to prevent its loss, disclosure, modification, or unauthorized use." from Section 7.3, Subscriber Duty to Prevent Private Key Disclosure. I do not understand what Section 7.2 is supposed to mean. Authorized by whom? Legal according to which country's laws? Section 7.3's requirement "to use a trustworthy system" would seem to eliminate about 99.5% of the market: almost all computers are not trustworthy, even if they are (in practice) trusted. RISKS: Although you agree to all of this (and that you've read it) before you receive your VeriSign certificate, it is not reasonable to expect people to wade through a 13-chapter work. If almost nobody meets the requirements for using VeriSign, what good is it? Who accepts the risk of something going wrong, when the conditions for use are not met, and VeriSign issued a certificate knowing that these conditions are not met? A false sense of security can be worse than no security.... Drew Dean
Newsgroups: sci.aeronautics.airliners Path: sq!fastlane.ca!n3tor.istar!tor.istar!east.istar!news.nstn.ca!newsflash.concordia.ca!newsfeed.pitt.edu!news.duq.edu!newsgate.duke.edu!agate!news.Stanford.EDU!unixhub!ditka!bounce-back >From: Dewayne Matthews <email@example.com> Subject: Re: Can't use GPS on Alaska Airlines References: <firstname.lastname@example.org> <321E425F.70C0@macromedia.com> <321F5320.CC0@mail.wwd.net> <airliners.1996.1750@ohare.Chicago.COM> <airliners.1996.1778@ohare.Chicago.COM> Organization: University of Colorado at Boulder Date: 13 Sep 96 03:03:33 In article <airliners.1996.1750@ohare.Chicago.COM>, > Dave Benjamin <email@example.com> wrote: >It seems incomprehensible that aircraft avionics that MUST frequently >fly over high-powered radio transmitters could be so susceptible to stray >onboard RF. My understanding is that the restrictions on in-flight use >of electronic devices is based entirely on unsubstantiated anecdotal >evidence. Well, here's some anecdotal evidence. About 3 years ago, I was in seat 1D on a Delta MD88 flying at cruise altitude over NE New Mexico on a clear summer afternoon. A flight attendant came out of the cockpit (fightdeck?) and with a clear sense of urgency made a PA announcement to turn off all portable electronic devices and instructed the other FAs to check all the passengers. They quickly reported that the only device in use was a laptop in seat 2C (right behind me) and this guy was having trouble saving his file so he hadn't turned it off yet. The first FA said "I'm sorry sir, but you have to turn it off NOW!" He did. She went back into the cockpit, and came out about two minutes later. She went over to the guy in 2B, apologized, and said that when the captain called her into the cockpit the first time (this is an exact quote) "All the gauges were black." (The MD88 has a "glass" cockpit.) She said that they were just now coming back on. She then said (I'm not making this up) "The captain wants to know if you have a Compaq computer." He said, with surprise, "Why, yes, it IS a Compaq." It was a older one with an external mouse. I told them that I had read somewhere that external mice greatly exacerbated the problem. I then had another cup of coffee. It made a true believer out of me. Dewayne Matthews
Dick Mills <firstname.lastname@example.org> writes: > Mr. Dorsett expands on that theme when he says "It's a political world, not > a technical one." I say no, never. Mixing demagoguery and science is > irresponsible. It must never be tolerated. OK, let's be more blunt. The Federal Aviation Administration has long been criticised for its dual charter of both enforcing safety and encouraging the development of air commerce. The two roles are contradictory, representing an inherent conflict of interest. This does not reflect upon the character of the many skilled and motivated individuals that work there. But the agency's existence and function is based upon constraints that are often defined by external parties, and the people that make up the FAA must work within those constraints. Just to make it clear, those constraints are "political," not "scientific." In the specific case you find "deplorable," actions taken to challenge the operation of the ATR-72 in the US, the author makes credible points that external influences--namely, the ramifications of a bilateral accord, in which the US is obligated to accept the findings of the European airworthiness authorities; economic events which had nothing to do with the certification process; and French threats of reprisals against US aircraft--were factors in the FAA's action (or inaction). Faced with such heavy-duty forces, the author exploited media interest in the October 1994 crash to point out what his concerns (as a pilot) were. He initially gave a public interview on a daytime talk show, and, eventually, churned out the book. He states he did so out of concern for the safety of the flying public. It is arguable that the media attention influenced the political climate. No bureaucracy wants to be seen as fallible, and it is equally arguable that ongoing pressure forced action on the issues. I fail to see why this is unacceptable. Particularly given the criteria that you yourself have laid out, namely that it is an expert attempting to manipulate the system in his favor. If we lived in a science-fiction world in which some mysterious quantity called Truth were feasible and easily obtained, then, yes, I suppose we could live in a quasi-fascist society in which the anointed protect the unwashed masses from the ambiguities of life. However, we do not live in such a world. In our world, issues often reflect the vested interests of multiple parties, all of whom may be "in the right," but who may nonetheless have conflicting agendas. There are many checks and balances in such circumstances. The government has competing agencies (e.g., NTSB vs. FAA) to ensure that institutional cultures do not get out of hand. The public can comment via its elected officials and the free press. The victims' families can react via their lawyers. If information is suppressed and kept in the province of "experts," the system stops working. Creating star chambers is not the answer, particularly when it affects operations in such a huge industry, in which MANY qualified individuals are in credible positions to comment, and, especially, in a situation when SO many peoples' lives can be put on the line. I concede that investigation teams need room to work. The NTSB freely concedes that it must make periodic reports on the status of its investigations. It does not issue a probable cause statement until the final report is issued. However, your model implies that no discussion whatsoever should take place until that final report is released. That's just unrealistic, in my opinion. It is contrary to safety and even ignores the interests of the affected parties--particularly the traveling public. Robert Dorsett <email@example.com> Moderator, sci.aeronautics.simulation firstname.lastname@example.org ftp://wilbur.pr.erau.edu/pub/av
Just got my brand new AT&T residential long-distance statement. Of course, I pay "electronically". The quotes mean that I do it through my fancy computer with Internet connectivity. And then the check gets printed out on wood pulp, physically hauled in a mail sack to AT&T's post office box, removed from the envelope, and then some clerk (automated?) keys it in and credits it to my account. As error-prone as this process is, it sort of worked since the account number had a check digit which gave some hope of correctly crediting the account. My new account number no longer has the additional digits which, I'd assumed, were a combination of unique code and check digit. Now a single slip of a keystroke and my check gets credit to another's phone bill. But at least, the new bill is pretty with an Olympic logo and AT&T's corporate logo. Who cares about the data. To be honest, it isn't clear that companies really used the check information anyway. The attitude, as with credit card companies, seems to be deposit and, if someone complains, and verifies by showing the back of a physical check (which banks try to not provide any more), you might convince them that you really paid and they just miscredited it. One day, in the far far future, there may be a course in "data integrity" as part of the accounting or MIS curriculum Until them, may your checks find the right home more often than not.
In RISKS-18.44, Edward Reid explains how Word saves files. But it's worse than what he describes. I'm working on a Word 6 document (under Windows 3.1), trying to excise some references to obsolete terms. I searched for and deleted all of the references, and did a "Save As" to ensure that I'm creating a new file without any "leftovers" from earlier versions. Doing a search doesn't find any references to the deleted terms, but the "Find File" option (and utilities such as Norton Desktop's SuperFind) still locate the supposedly deleted text. So I presume they're somewhere in the file, which gives me very little confidence in the safety of handing someone a Word file. The difference between this and previous discussions of the topic (I believe) are that others have indicated that doing a "Save As" or disabling the "Fast Save" option would avoid this behavior. That's clearly not the case, for at least some versions of Word.
Aside from the gratuitous insults, the below RISKS posting is also factually incorrect in a number of places. The resource modification done below is *NOT* a modification to the file on the disk. It is done via a copy-on-write mechanism. The page containing the modified resource is written out to the paging file, not back to the original image. So there is no difference in the exe and whatever you ship to production IS THE SAME AS THE ONE THAT WAS TESTED. Writing to a read-only resource does not cause a crash for the customer. The default unhandled exception filter for any Win32 application handles access violations caused by writing to a resource by changing the protection on the page from read-only (the default for resource sections) to copy-on-write and restarts the instruction. It will now succeed, but the modified page is written to the paging file instead of back to the original image. For more gory details, see KB article Q126630 "Resource sections are read-only" at http://www.microsoft.com/kb/developr/win32dk/q126630.htm There are two reasons this behavior will cause you pain. You will see a first-chance exception if you are running under a debugger and have the debugger configured to handle first-chance exceptions for access violations. If you don't understand the difference between first-chance exceptions (exception filter functions have not executed) and second-chance exceptions this can be confusing. http://www.microsoft.com/kb/developr/win32dk/q105675.htm should help you out here. Second, if your code has a filter function that handles this exception before the top-level exception filter sees it, the right thing is not going to happen. This is a RISK you always take when your exception filter handles exceptions it doesn't know how to handle. -John
Microsquish Stealth Bug Insertion Technology While I'm kind of dismayed by the "if you can't innovate, litigate" philosophy so often applied to Microsoft, this is a particularly lethal little gem from their MFC team. In many development environments, this problem will almost certainly guarantee that your app will crash the first time it is executed on customer machines, but the crash will only happen once, and will mystify tech support. The problem arises in the use of property pages, otherwise known as tabbed notebook dialogs, as they are designed and implemented in the Visual C++/MFC environment. VC allows the developer to use interactive resource editors to design the property pages, but IT ONLY DOES THE FINAL STEP OF THE PROCESS IN EXECUTING THE APPLICATION, not in the development cycle. This step, where the style of the page is changed in the resource will cause most machines to abort the software as it is attempting to change a read only resource. What really concerns me from a risks perspective is that the traditional development model is to release an exe to the test/qa group, and then to ship this exe to production when it receives a blessing from test/qa. This means that the exe shipped to production IS NOT THE SAME AS THE ONE THAT WAS TESTED, because the tested exe has been executed, and the one sent to production has not. Hence, every customer who launches the app for the first time will be rewarded with a crash, which can never be reproduced. Yes, you can get around it with careful use of filtered exceptions. The problem is that this is rather insidious, and outside the realm of thinking of most developers, who view an exe as the final product of the development process. In this case, the final product is an executed exe. Personally, I feel this is a lot like the Monty Python "Frog chocolates" sketch. VC too should have a great big warning sticker on it saying "An EXE from the linker is NOT A PRODUCT. YOU MUST EXECUTE IT TO MAKE A PRODUCT." — -- — -- — -- ORIGINAL MICROSOFT DOCUMENTATION — -- — -- — -- Applies to class CPropertyPage, specifically the DoModal function that causes the page to be presented on the screen. virtual int DoModal( ); [... standard usage documentation deleted...] [HERE IS THE INTERESTING BIT!!!] Note. The first time a property page is created from its corresponding dialog resource, it may cause a first-chance exception. This is a result of the property page changing the style of the dialog resource to the required style prior to creating the page. Because resources are generally read-only, this causes an exception. The exception is handled by the system, and a copy of the modified resource is made automatically by the system. The first-chance exception can thus be ignored. Since this exception must be handled by the operating system, do not wrap calls to CPropertySheet::DoModal with a C++ try/catch block in which the catch handles all exceptions, for example, catch (...). This will handle the exception intended for the operating system, causing unpredictable behavior. Using C++ exception handling with specific exception types or using structured exception handling where the Access Violation exception is passed through to the operating system is safe, however.
> I clicked on "Cancel" in the dialog box and ... I was granted access. The system could have been configured so that it would have been difficult for you to do anything as a default user (in particular, it could have logged you off immediately). Windows 95 security may not be its best aspect, but even a certified secure product is only secure with respect to its security claims and only then under certain conditions - eg, the procedures in the accompanying Trusted Facility Manual must be followed. You have just seen an insecure default configuration - basically what many Unix suppliers have provided for years. Dirk Fieldhouse, Logica UK Limited, 75 Hampstead Road, London NW1 2PL UK email@example.com +44 (171) 637 9111
> In the Supreme Court decision, the Court said that our right to be > bothered does not justify limiting First Amendment rights. However there's an interesting interaction between US and UK laws here. We have a Computer Misuse Act which makes it an offence to alter any data on any computer without proper authorisation. If I declare that unsolicited e-mail advertising to this node is unauthorised (and this I hereby do) then anyone sending such mail to me is committing a criminal offence. The US telephone service is required, under international treaties, to prevent this. Bernard Peek firstname.lastname@example.org I.T and Management Development Trainer to the Cognoscenti
In all the discussions on junk snail mail I see, there are many comments about the time required to sort through it (which may or may not be the basis for a legal case), but I've seen few comments about the direct cost of throwing away the junk mail. If we can enact a junk fax act on the basis of direct cost, we can probably do so for snail junk as well. Aahz (@netcom.com)
Having tried to quash this theory repeatedly, I'm discouraged to see it re-emerge yet again in RISKS. The fact is that courts are not going to read TCPA as applying to junk e-mail. Most of the reasons are set out in the NetGuide article whose URL I gave in my previous message. I won't repeat those arguments here, but here are two I didn't have room for in print: 1) Section 227(d)(1)(B) of Title 47 makes it illegal to use a computer or other electronic device to send any message via a telephone facsimile machine unless such person clearly marks, in a margin at the top or bottom of each transmitted page of the message or on the first page of the transmission, the date and time it is sent and an identification of the business, other entity, or individual sending the message and the telephone number of the sending machine or of such business, other entity, or individual. Note this section applies to noncommercial messages as well as commercial ones. If a computer equipped as described by Dan Franklin were really a TFM for purposes of the TCPA, then almost every Usenet post (and a vast amount of e-mail) would be illegal, since it is highly unusual for senders to put their telephone numbers in the headers. (I leave aside entirely the problem of what a "page" is in an e-mail message, other than to observe that this is further evidence that Congress had only conventional faxes in mind.) BTW, it is not an adequate response to say "oh, but 'telephone number' here just means your correct e-mail address." If you're not willing to read "telephone number" literally, why on earth should anyone adopt a hyperliteral reading of the definition of a TFM in sec. 227(a)? 2) Suppose someone in your company sends e-mail to the two dozen people in his/her working group advertising a bake sale or yard sale. Assume further that a single recipient reads this e-mail on a networked PC equipped with a modem and printer. Under the proposed broad reading of the TCPA, this would be illegal. Is that what Congress intended? (The legislative history certainly doesn't offer any support for it.) FWIW, there are no cases addressing this question of whether junk e-mail is covered by the TCPA. Frankly, I think the issue will be moot before very long; this is too hot (and vote-getting) an issue to be ignored by Congress, which has been more than willing to legislate rules for the Internet this year. Mark Eckenwiler email@example.com
Please report problems with the web pages to the maintainer