>From "Glitches of the Week", http://www.currents.net/newstoday/98/01/27/news1.html >Man Jailed Because of Computer Glitch > Tony Ninness of Agnes Waters, Australia, was jailed for six hours for > failing to pay a traffic fine, even though it turned out he had paid the > fine five years ago. Last month, police came to Ninness' residence with > outstanding warrants for his arrest. He was held in custody at the Agnes > Waters police station until the friend paid the police $1350. The next > day, courthouse staff confirmed that Ninness had indeed paid off the fine > long ago, and issued him a refund check. But then the police contacted > him and said they had issued too large a refund, and said he would be > jailed again unless he returned $114.60. "It sounds like a load of > rubbish to me," Ninness told the Sunday Mail newspaper. "Why should I pay > it? It's not my fault." Police officials blamed computer glitches for > the problems. Unfortunately, the article doesn't make it clear if the "excess amount" was on top of what the friend paid in "outstanding" fines, or if the check was for $1350 and the police demanded incarceration charges similar to those becoming common in the United States. Bear Giles email@example.com
*The Washington Post* (29 Jan 1998) reports that the state of Virginia has been cracking down on noncustodial parents who have fallen behind on child support payments. About 15,000 people have paid $15 million. But 2300 other people were incorrectly identified as delinquent and were sent notices revoking any hunting and fishing licenses they have. The incorrect notices were caused by "a computer programming error". The state official responsible for child support apologized and said that safeguards have been put in place to avoid it happening again.
I'm having an interesting encounter with one of the major Canadian banks right now over RRSP (registered retirement savings plan) receipts. It smells vaguely Y2K-ish. Here's the scenario. In August of 1997, I purchased 11 $1000 GICs (guaranteed investment certificates) laddered at 4 months increments with the farthest out one coming due in 5 years (or 2002-09), the earliest would come due in 1 year, 8 months (1999-05) (the actual maturities are 1999 5, 1999 9, 2000 1, 2000 5, 2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). In December, I received a receipt for $2000. The bank usually accumulates up all of your contributions for the year and then sends one receipt. In my case, I should have received a receipt for $11,000. I thought this strange, so I phoned their call center and was told that a receipt for the rest of the amount would be coming. So I made a note in my daytimer, and let it sleep. So today (end of January, 1998) I phoned my branch and talked to a rep I know there about my account. She checks the records and they show that I was to receive only a $2000 receipt (not $11,000), although, there are 11 different GICs in my account all purchased in August! Fortunately, I still have the temporary, no good for taxes, receipt. So now she's investigating and I did some thinking. Of the 11 GICs I purchased, 2 came due before 2000, (in 1999 5 and 1999 9), the rest came due in (2000 1, 2000 5, 2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). Hmm... $2000 receipt... for the ones maturing before 2000? Where did the receipt for the rest go?? ;-) The hypothesis: If you buy a GIC that matures after 2000-1-1, the receipt program breaks, and ignores the amount. You don't get a receipt mailed to you. Has anyone else had this experience with a Canadian bank? Andrew Walduck
The treatment of null values is arguably reasonable once it is understood - null values simply fail all comparisons with non-null variables. This means that if you ask if x(null) < y(non-null), you will be told "no". The same thing will happen if you change the operator to ">". Not too bad so far. However - I found the result of "<>" deceptive. It fooled me into writing a statement that did the exact opposite of what I expected. Behaviour like this in a language is dangerous, because many people will fall into the trap, and some of them will bring down national telephone systems. The following code snippets are NOT equivalent: if x=b then print "Equal" else print "Not equal" endif and if x<>b then print "Not equal" else print "Equal" endif The latter is perverse and non-intuitive. It says the two variables are equal when one of them is null and the other isn't. Think very carefully when you use the "<>" operator!
It seems MS/IE makes it easy to steal private keys: Microsoft Product Flaws Make Net Dangerous, Experts Say By Douglas Hayward, TechWeb (23 Jan 1998) <http://www.techweb.com/wire/story/TWB19980123S0007> Joseph Bergin, Professor, Pace University, Computer Science, One Pace Plaza, NY NY 10038 firstname.lastname@example.org http://csis.pace.edu/~bergin/ [The beginning of the text is excerpted below by PGN Stark Abstracting:] Flaws in the security of Microsoft's Internet products allow malicious hackers to steal users' private encryption keys and impersonate their victims, security experts said. [...] A security advisory note circulated this week by Peter Gutmann, a security expert in New Zealand, said that private encryption keys can easily be stolen from the hard disks of machines whose users are surfing the Web, thanks to flaws in several Microsoft products, including the Internet Explorer browser and the Internet Information Server package. "I would say it was a fairly important security flaw," Gutmann told TechWeb. "At the moment there is no defense against the problem."
On 20 Jan 1998, NTT Central Personal Communication Network Inc. announced an experimental service of providing the estimated location of a PHS (Personal Handy-phone System) terminal through a FAX machine. The service will be provided in Tokyo from February to April. The location information is accessible by any FAX machine with the phone number and the access PIN of the PHS terminal. The information is given by a circle on a map, with the radius of 100 to 500 meters (or 328 to 1640 feet) range. The company has been field-testing the service since July 1997, and will provide the same kind of experimental service for The coming Nagano Olympic Games too. The risk is quite obvious; anyone who has a PHS terminal is technically traceable, without the consent or knowledge of the owner. I found a similar service was being developed by British Telecom too. PHS is quite popular in Japan. The number of PHS service subscriber in Japan was 6,992,000 as of December 31, 1997, according to the report of Telecommunications Carriers Association. References:  "Spy phones trace cheating husbands — and employees", RISKS Forum 19:35.  http://www.teleserve.co.jp/tca/whatn/whatn_e.html Kenji Rikitake <email@example.com> <URL:http://www.k2r.org/kenji/>
A draft ("consultation version") of a report by the European Parliament's Office for Scientific and Technological Option Assessment (STOA) entitled "AN APPRAISAL OF TECHNOLOGIES OF POLITICAL CONTROL" has been submitted to the EuroParl's Civil Liberties and Interior Committee. Several IT-relevant excerpts are now available at John Young's widely respected crypto-politics website: <<http://www.jya.com/atpc.htm> (STOA regs apparently require a document to be distributed only on paper while it is a "working document." Quaint, huh? A hardcopy can be ordered by e-mail from the office of British MEP Glyn Ford <
Crash of A-320, Strasbourg"SINIAKOV ALEXANDRE" <firstname.lastname@example.org> Fri, 23 Jan 1998 20:38:24 +0300About the cause of air accidents and crashes of * Boeing-747, Flight 826, 28 Dec 1997 (Tokyo-Honolulu) * A-320, 20 Jan 1992 (Mont Saint-Odile, France) * A-310, 22 Mar 1994 (Novokuznetsk, Russia) * Tu-154, 6 Dec 1995 (Habarovsk, Russia) Computer researches show,that Local Geophysical Resonance was primary cause of these air accidents (B-747) and crashes (A-320, A-310, Tu-154). This is a previously unrecognized natural phenomenon, connected with the resonance characteristics of both the solar system and outer space. LGR arises from the interaction of the planets of the solar system and is a cause of an excitement of space-local sones. In such cases natural and technical catastrophes take place. Specifically, under certain conditions at a moment of LGR, aircraft flight-safety-critical whirlwinds (tornados) arise. The whirlwinds are the common cause of these incidents.
Re: TCAS near-miss (Bellovin, RISKS-19.55)Nancy Leveson <email@example.com> Wed, 28 Jan 1998 06:11:30 -0800> ... Someone on the ground switched on a transponder; the TCAS system on > the plane overhead decided that an aircraft had suddenly appeared 3000 > below it, and suggested that the pilot climb. This didn't make any sense to me. TCAS recognizes transponders on the ground and ignores them. It also only issues alerts near the ground when an aircraft is within 750 feet (not 3000) and even at high altitudes the max is 950. As usual, what you see on the net has been garbled. The FAA is still investigating, but apparently the radar data shows that the actual separation between the two aircraft was much greater than reported by the media (in fact, the media has exaggerated the whole event). What seems to have happened is that a maintenance shop on the ground was testing the altitude reporting capability of the transponder and the transponder was reporting an altitude above ground level. The FAA has guidance to perform such tests with the transponder antenna shielded so that these events will not occur. They are still investigating why the shielding did not occur. Where the media got the number "3000 feet below it" is unknown but was probably a garbling of the Southwest Airlines plane's climb rate of 3000 feet per minute. [It would indeed be helpful if would-be RISKS contributions gave specific sources of information. To satisfy that desideratum in this case, I note that Nancy's information comes from the head of the TCAS program at the FAA and the AIRINC investigation report of the incident. PGN]
Re: robots.txt (Meyer, RISKS-19.57)Bertrand Meyer <firstname.lastname@example.org> Fri, 30 Jan 98 00:23:26 PSTI have received a flurry of responses to my article describing the risks associated with the `robots.txt' convention for excluding search engines from indexing parts of a Web site. I apologize for not responding individually to all the people who wrote to me. I have put, however, all the answers in a Web page, for the benefit of anyone who cares to consult them: http://www.eiffel.com/private/meyer/robots.html (available Saturday, Jan 31st, 18:00 California time). The common theme of the answers can be summarized as follows: I was wrong to criticize the robots.txt design because it is not meant to protect pages, simply to keep search engines away from pages that are not *worth* indexing, e.g. because they are of temporary values. To quote one correspondent, Osma Ahvenlampi <email@example.com>: > Robots.txt is a way to protect your web server from being overloaded by a > dumb robot in a cgi loop, not a security tool. This much should be obvious > to anyone capable to be in charge of web site administration. or, according to Chris Cheyney <firstname.lastname@example.org>: > Anyone stupid enough to leave a network open and count on the optional > robots.txt robot exclusion de-facto standard for security gets (and should > get) what he deserves. Among the people making similar points: Thomas Andrews <email@example.com>, Nelson Minar <firstname.lastname@example.org>, John R. Levine <email@example.com>, Jeremy Nelson <firstname.lastname@example.org>, Barry Margolin <email@example.com>, Laurentiu Badea <firstname.lastname@example.org>, Klaus Johannes Rusch <KlausRusch@atmedia.net>. Again, see the Web page for the details of their comments. I stand by my original assessment: 1. If every facility was always used as its designers intended, the RISKS archives would be noticeably slimmer. Here the possibility of misuse seems rather considerable. If you are just a bit absent-minded, isn't it natural to use this mechanism to exclude stuff from being indexed and hence believe no one will find it? "Stupid", maybe — but not unlikely. After all, the designers of the Mercedes A-Class car could also say "anyone stupid enough to swerve violently when an elk crosses the road gets (and should get) what he deserves". Unfortunately for them, and probably fortunately for most of us, that doesn't pass muster. 2. For anyone who thinks this is just a hypothetical possibility, here is the robots.txt file of the site of a major communications company: robots.txt User-agent: * Disallow: /bug-navigator # Bug Data Disallow: /warp/customer # Registered Users Disallow: /kobayashi # Navigation for registered Disallow: /cgi-bin # no programs Disallow: /pcgi-bin # no programs Disallow: /univ-src/ccden # will get content through /univercd Disallow: /cpropub/univercd # obsolete The first two lines at least suggest to me that this is stuff that the company doesn't want publicized — for security reasons, not because it is of temporary value. Were I a "hacker" in the bad sense of the term, I would revel in such information, as it would direct my efforts to the really juicy bits. Here is an extract from another page — I'll let you guess the URL: # o Created this file to prevent indexing of one # SME directory. User-agent: * Disallow: /sparc/SPARCengineUltraAX/oem/ Disallow: /microelectronics/SPARCengineUltraAX/oem/ Disallow: /javachip/SPARCengineUltraAX/oem/ Disallow: /javachips/SPARCengineUltraAX/oem/ Disallow: /sparc/SPARCengineUltraAX/download/ Disallow: /microelectronics/SPARCengineUltraAX/download/ Disallow: /javachip/SPARCengineUltraAX/download/ Disallow: /javachips/SPARCengineUltraAX/download/ I can't say for sure, but doesn't some of this look a tad like proprietary information? 3. So even if the respondents are right that it is "stupid" to use robots.txt in that way, my posting at least draws attention to the risk. If it succeeds in making just one Webmaster a bit more careful, it will not have been useless. 4. Of course designers cannot always be blamed for misuses of their mechanisms. But they should minimize the possibility of misuses. In the robots.txt case it seems to me rather wrong to have a conspicuous world-readable file that draws attention to *excluded* information. (Reminds me of programming languages which implement information hiding by making the author of each module list conspicuously, as the first thing you read in the module's text, those features which are *not* exported!) This draws attention to what should not attract attention. I think that a more effective convention would have been to include a special marker (META tag?) in HTML files that shouldn't be indexed, and a special file (exclude.txt?) in the directories that should not be explored at all. Then you would only be able to find that information if you already knew where to look. The robots.txt mechanism is a godsend for Peeping Toms in search of possible secrets. (Thanks too to Marc Horowitz <email@example.com> and Rik Moonen <firstname.lastname@example.org> for their comments.) Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel <Bertrand.Meyer@eiffel.com>, http://www.eiffel.com
4-Letter words, re: CyberSitterDevon McCormick <Devon.McCormick@bankerstrust.com> 27 Jan 1998 13:43:51 -0500[I wrote an article on the ramifications of binary data as "bad words" for our local New York APL (A Programming Language) newsletter. I think you can get the gist of it without the special font you need to read the APL code properly. Devon] I was thinking about the CDA (Communications Decency Act) the other day, about how much more important it is to protect our children from bad words than from bad laws, and I wondered what I could do to help make the 'net as bland and harmless as television. One danger no one has pointed out has to do with another fine U.S. government initiative, the Clipper chip (or whatever name it's disguised under right now). It occurred to me that any good encryption routine, and the NSA promises that Clipper is real good, effectively turns its input into an output that appears random. This raises the dismaying possibility, in fact certainty, that an encrypted datastream will contain dirty words! At first glance this seems to be simple enough to remedy: we can scan the encrypted stream for dirty words and replace them with some equivalent string then convert them back at decryption time; in fact, someone has already written software to do this using names of U.S. senators as the dirty word equivalents. However, this is not as simple as it seems. Consider that a dirty word may be written in upper-case letters, lower-case, or a combination of the two. Also, there is the concern of performance degradation. Pondering these difficulties, I realized that since most dirty words are 4 letters (bytes) long, and that most computers do well with 4-byte (integer) conversions and comparisons, there is a good solution: consider only the equivalent "dirty" numbers! Once I had had this insight I leapt to my keyboard to answer the question that must now be burning in your mind the way it was then in mine: just what are these dirty numbers and what can we do with them? The following Dyalog APL session explores some of the possibilities. One advantage dirty numbers have over dirty words is that you can do things like find the "average" dirty word: this could lead to a whole new class of forbidden words (albeit largely unpronounceable ones). ½BADWORDS 7 4 Apologies to George Carlin. BADWORDS[;0],'*','*',BADWORDS[;,3] F**K S**T Q**M C**T F**T D**N P**S © Or, for the more squeamish: BADWORDS[;,0],7 3½'*' F*** S*** Q*** C*** F*** D*** P*** ALPNUMAV OK, let's see what the all-upper-case dirty numbers look like: (½ALPNUM)³ALPNUM¼BADWORDS 302078184196 357695050756 349323218180 289194005508 301743625220 293153361412 344827581188 Account for all possible upper- and lower- case combinations by expanding the upper-case versions with all 4 digit boolean combinations (so "1 1 1 1" maps all-upper to all-lower, "1 0 0 0" maps all-upper to initial upper-case letter only). VARBW(-/AV¼'Aa')×(³(4½2)¼16) © Assumes upper and lower alphabets are each contiguous. ½¨ALLBW¨(VARBW)+¨¨ALPNUM¼BADWORDS 16 4 16 4 16 4 16 4 16 4 16 4 16 4 BADWORDS-ALPNUM[¨¨ALLBW] © Check that we have what we think we do 1 ½BADVARIANTS(½ALPNUM)¨³¨ALLBW 7 16 BADVARIANTS 1179992907 1179992955 1180005195 1180005243 1183138635 ... 1397246292 1397246340 1397258580 1397258628 1400392020 ... 1364543821 1364543869 1364556109 1364556157 1367689549 ... 1129664084 1129664132 1129676372 1129676420 1132809812 ... 1178686036 1178686084 1178698324 1178698372 1181831764 ... 1145130318 1145130366 1145142606 1145142654 1148276046 ... 1346982739 1346982787 1346995027 1346995075 1350128467 ... © So, the average of each bad word variant is: ALPNUM[³(4½½ALPNUM).5+(+/BADVARIANTS)÷16] .Ò $Ã ÏÁÐ ÍÒÁÈ $ÒÊÐ .YÎÐ %YÈÊ ÌÁÏÏ © And the average variant bad words are: ALPNUM[³(4½½ALPNUM).5+(+BADVARIANTS)÷7] JÕêñ JÕêµ JÕ"ñ JÕ"µ J<êñ J<êµ J<"ñ J<"µ õÕêñ õÕêµ õÕ"ñ õÕ"µ õ<êñ õ<êµ õ<"ñ õ<"µ © And the overall average bad word is: ALPNUM[,(4½½ALPNUM).5+(+/,BADVARIANTS)÷½,BADVARIANTS] ÂÖ¹¼ © So, ÂÖ¹¼ the CDA!
Re: Possible Netscape source code risks (Wilson, RISKS-19.57)Dale Martin <email@example.com> 28 Jan 1998 16:32:38 -0500This possibility exists with ANY software project. Personally, I feel better about source code that's being looked at by thousands of developers rather than a few in a company, at least with regards to "slipping nasty things in so-called bugfixes". Dale E. Martin | University of Cincinnati Savant Research Laboratory firstname.lastname@example.org http://www.ececs.uc.edu/~dmartin
Please report problems with the web pages to the maintainerTop