Subject: RISKS DIGEST 17.89 RISKS-LIST: Risks-Forum Digest Tuesday 12 March 1996 Volume 17 : Issue 89 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** ***** THAT LAST ITEM HAS BEEN MODIFIED. PLEASE REREAD IT CAREFULLY. ***** Contents: [Thanks for all the e-mail! Perhaps we can slow down a little?] Graduate Record Examination screwup (George Janczyn) "What's new" in web pages is not necessarily reliable (Mordechai T. Abzug) Digital Flight Control Systems help the U.S. Navy (Peter Ladkin) Re: CIA & NSA run remailers (Jim Thompson) Re: Rail safety controlled by satellite (Don Root) Re: bleep-year (Bear Giles) Re: UNIX struct tm (Keith Neufeld) Re: COBOL Dates (Owen Leibman) Re: Teen `convicted' by computer (Richard Cox, Phil Herring) Lotto computer errors (Tim Pietzcker) Risks of automatically publishing Risks newsletter to the Web! (Jennifer Hunt) Re: Netscape's too-lenient syntax checking (Jonathan Kamens, A. Padgett Peterson, Eric Tilton, Torrey McMahon) Re: Yet another Trojan horse in Netscape 2.0 (David Wood, Stanton McCandlish, Jon Reeves, John Mainwaring) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 12 Mar 1996 08:19:11 -0800 (PST) From: George Janczyn Subject: Graduate Record Examination screwup An acquaintance of mine who is visiting from Russia was in Boston a few weeks ago to take the Graduate Record Examination. The examination is taken solely on a computer. No doubt you can see what is coming. When the computer display asked my friend whether she would like to see test results, she answered "yes" but nothing happened. She asked a staff member for assistance, but was told not to worry, because the test results "will be mailed to you." Yesterday's mail brought a form letter from GRE stating that her test results had been "cancelled at your request." My friend called to ask what this meant, and was told that there had been "some problems" during the snowstorm, that all information about her test was "gone", and she would have to retake the examination. The RISK? Perhaps it is unwise to schedule a GRE in Boston in the winter. George J. Janczyn University of California, San Diego gjanczyn@ucsd.edu ------------------------------ Date: Mon, 11 Mar 1996 22:24:27 -0500 From: "Mordechai T. Abzug" Subject: "What's new" in web pages is not necessarily reliable I have a little web robot running to keep track of changes to web pages. This came in very handy this semester, as I have an instructor who puts all assignments on the web: instead of having to check manually when the instructor put up the assignment, I just set up to monitor his "What's new" page and get mailed within 25 hours of a change. This worked for a while ..., then a homework assignment was added to a different page without being mentioned in the what's new. Oops. He was very understanding, but this class of problems is something robot users -- as well as people using netscape 2's update feature -- will want to keep in mind. Mordechai T. Abzug http://umbc.edu/~mabzug1 mabzug1@umbc.edu ------------------------------ Date: Tue, 12 Mar 1996 12:08:12 +0100 From: ladkin@TechFak.Uni-Bielefeld.DE Subject: Digital Flight Control Systems help the U.S. Navy While many of us may be concerned about the consequences of increasing computerisation of aircraft systems, one must not forget the other side. Digital flight control can sometimes unequivocally improve safety. Flight International, 13-19 March, p9, reports that the USN is upgrading the F-14 flight control system with a digital system developed by GEC-Marconi Avionics of the UK. "Three accidents within a month have prompted [.. the] upgrade [..] to prevent flat spins and improve carrier-approach handling qualities". The DFCS [..] has been flight-tested by the USN [..] and a production contract awarded to upgrade 211 aircraft [..]." Peter Ladkin ------------------------------ Date: Tue, 12 Mar 1996 10:48:26 -0600 From: jthompso@netcom.com (Jim Thompson) Subject: Re: CIA & NSA run remailers (Raph Levien, RISKS-17.88) >Even if governments were running remailers, the use of a >chain of remailers, rather than just one, protects against compromise of >identity even if one or more remailers are compromised. It suffices that one >of the remailers in the chain is honest. Unless I completely misunderstand remailers (I don't use them), one honest remailer in a chain is sufficient only if you want to hide your identity from the ultimate recipient. However, if you also wish to hide from government-run remailers, then it's necessary that the *first* remailer in the chain be honest. The first remailer has access to all your message's original header fields. Jim Thompson, jthompso@netcom.com ------------------------------ Date: Tue, 12 Mar 96 00:48:34 PST From: der@oes.ca.gov (Don Root) Subject: Re: Rail safety controlled by satellite (RISKS-17.88) Anyone trying to implement GPS as a means of collision avoidance for trains will have their share of 'features' to work out. The possibility of trains operating on parallel track (such that they will pass each other), or operating on rails that cross each other (grade separation) suddenly going into "collision avoidance" may be accented by the known "dither" factor found in commercial GPS equipment (a concept that wobbles the mind). ------------------------------ Date: Tue, 12 Mar 96 12:48:57 EST From: byrnes@escmail.orl.mmc.com Subject: Re: Rail safety controlled by satellite (RISKS-17.88) As someone who has worked for the railroad, I find it is scary to see this type of technology touted as a "cure-all". Most railroad collisions do not involve "train vs. train", they involve train vs. "some other vehicle that has crossed the track". And most train vs. train incidents occur because of driver error or signal failure. (Will satellite failure soon cause a rash of high-speed train wrecks?) The railroads call their train drivers "Engineers" -- yet many (most?) are not degreed or even trained in much more than an apprentice type program. It is a boring repetitive job, and the railroads drive to reduce costs, by reducing crew numbers, may have as much or more to do with rail safety than any other factor. If my computer crashes, (even on a leap/non year) I may have a little "clean up" to do. But a 5-mile-long multihundred-thousand-pound piece of technology crashing can really mess up your day. :-) Arthur J. Byrnes ------------------------------ Date: Tue, 12 Mar 1996 04:12:53 -0700 From: Bear Giles Subject: Re: bleep-year (Mulligan, RISKS-17.88) > ... Perhaps the major software firms could mutually agree that stock > options awarded during the next two years be exercisable on, and only > on, 29 Feb 2000. While this was written in jest (hopefully), this is an extremely common perception which is going to bite software professionals in the very near future. Anyone who subscribes to any Y2K discussion for more than a few days will be struck by the large number of people desperately seeking any viable solution to a problem which (most) upper management steadfastly denies exists. Or upper management will accept that it might be a problem, but _their_ bonus comes through with good returns this fiscal year and it's easier to cut costs by eliminating "incompetent" employees whining about how a problem in their own department will jeopardize the company years from now. Besides, if everyone is in the same boat what's the harm if the worst happens -- the company's competitors will be just as screwed up! It's time people recognize that Y2K isn't a technical problem, it's a management problem. Technical people know that losing source code is a Bad Idea. Technical people know that compilers change, and that new compilers (e.g., a COBOL compiler which can return CCYYMMDD instead of only YYMMDD) may break other parts of the system. Technical people know that it's penny-wise, pound-foolish to toss away information (and that the reason experienced analysts can command high salaries is they know what you can safely toss, and what you need to keep even if that means buying another disk and/or tape drive... and they know to keep an eye open for changing technologies.) Finally, technical people know that it's ____________F_____A_____R_____________ cheaper to fix that bug today than to wait even a month. If we're serious about fixing the Y2K problem, we need to address this as a business/management problem, not a technical problem. If a large company loses $2/share overnight because an auditing firm announces (and the networks carry the story) that the company isn't ready for Y2K, we'll see action. Unfortunately, the first action will probably be to fire the current technical people for letting the company get into this situation despite repeated pleas for adequate resources being ignored for years. :-( The RISKy moral of Y2K: software developers are like backcountry guides -- you tell them where you want to go and what you want to see and they'll take you there _and back_ safely.... It might be expensive, but it's a heck of a lot less expensive than talking a wrong turn and being stranded in the wilderness with a broken leg. But upper management is often like the legendary idiot from the big city who hires a professional guide and then insists on the guide doing it like he saw "in a movie once" instead of trusting the guide's experience and training... and then complaining to everyone back home how the guide wasn't any good since everything took twice as long and he only got to see a third of what he was promised. Bear Giles bear@indra.com ------------------------------ Date: Tue, 12 Mar 1996 13:59:42 -0600 (CST) From: neufeld@fast.pvi.org (Keith Neufeld) Subject: Re: UNIX struct tm (Urlichs, RISKS-17.88) > UNIX holds the time internally as the number of seconds since 1970-01-01. > "struct tm" is just a library abstraction. IMHO, if the library is changed > to return a four-digit date instead of modulo 100, not much will break -- > typical Unix software frequently says "if year < 1900 year += 1900" or some > such. [I think Matthias meant "since 1900", as already noted by Steve Loughran in RISKS-17.85. PGN] Actually, tm.tm_year is defined as the number of years since 1900. The real year-keeping problem for UNIX machines isn't the library routines that populate a struct tm; the first is programs that use statements like printf("%02d", tm.tm_year); [which will print ``100'' in the year 2000] instead of printf("%02d", tm.tm_year % 100); and printf("19%02d", tm.tm_year) [which will print ``19100'' in the year 2000] instead of printf("%4d", 1900 + tm.tm_year); And the zeroeth, as mentioned before, is machines that set real time on boot from hardware clocks that will fail near 2000. Keith Neufeld, Prairie View, Inc., 1901 E. 1st, Newton, KS 67114 (316) 284-6375 neufeld@pvi.org neufeld@bethelks.edu neufeld@acm.org ------------------------------ Date: 12 Mar 96 14:04:48 EST From: Owen Leibman <75140.365@compuserve.com> Subject: Re: COBOL Dates (Urlichs, RISKS-17.87) The COBOL standard has been amended twice since the adoption of the 85 StandardIn particular, the first amendment (ANSI X3.23a-1989, ISO 1989/Amendment 1) added numerous functions including date functions which deal with centuries. Many vendors offer COBOL compilers which support these functions. ------------------------------ Date: Tue, 12 Mar 96 08:22 GMT From: richardcox@cix.compulink.co.uk (Richard Cox) Subject: Re: Teen `convicted' by computer > With modern cheap storage media, room for say, a 16-letter string instead > of a single-letter code would make it hard to misconstrue All this "throw hardware at the problem" attitude is a risk in itself. After all never every computer system can have a $200 Gb HDD added to it. I'm sure the disks systems for fault tolerant systems are somewhat more expensive. But more significantly for data collection small hand-held computer systems have very expensive storage: perhaps UKP 100 for 2Mb of FLASH (which has its own problems with rapidly changing data). Coding is here to stay until no computer system has storage limitations. The real problem in the original article (coded data transferred from one system to another had different meanings) is assuming that one code set matches someone else's for the same purpose. The solution: manual checking or a dictionary (which introduces yet more potential problems). Richard Cox SMS United Kingdom Limited richardcox@cix.compulink.co.uk ------------------------------ Date: Wed, 13 Mar 1996 09:59:29 +1100 (EST) From: revdoc@uow.edu.au (Phil Herring) Subject: Re: Teen convicted: a similar example (Jewell, RISKS-17.87) While data normalisation has its place, it also has its limits; in fact, it is often better to denormalise database designs to some extent. Why? Because the values to which codes refer change - departments change their names, products cease to exist, employees come and go. For example, if you just keep a product number, and the product name changes, last year's orders will suddenly start referring to the new product name, which is usually the Wrong Thing. In addition, in this age of end-user access to data warehouses, excessive normalisation imposes a burden on the end user, who will have to grovel all over the place to decode all the values that they want to see. This is precisely the problem that occurred in the current case: namely, people were given the code numbers rather than the values to which they referred. This is a wholly different problem to normalisation, and is related more to presenting data in a human-readable form. Normalisation is fine in theory, but in practise, it should be treated as a useful, but limited, design tool. Phil Herring http://www.ozemail.com.au/~revdoc revdoc@ozemail.com.au ------------------------------ Date: Tue, 12 Mar 1996 18:42:44 +0100 (MET) From: Tim Pietzcker Subject: Lotto computer errors I remember that a few weeks ago somebody in Germany sued the lotto agency because his winning lottery numbers were misread by the computerized lotto ticket scanner. His chances for success were rated quite slim - he should have read the receipt... Tim Pietzcker Turnseestr. 9 D-79102 Freiburg Phone/Fax ++49+761 77345 ------------------------------ Date: Tue, 12 Mar 1996 18:19:16 -0500 From: "jennifer (j.) hunt" Subject: Risks of automatically publishing Risks newsletter to the Web! RISKS-17.88 has an article about the Netscape forms 'feature' that automatically sends e-mail upon loading a document. Risks kindly provides an HTML code fragment which exhibits this behaviour. When I loaded up this newsletter in my browser, that code fragment was executed! Given that this code represented a form of trojan horse, it is hardly appropriate for Risks Newsletter to be perpetuating it! The first risk is that of including 'live' code fragments in a publication, especially one which is subject to several media. The second risk is that of using an automated process to construct and publish information on the Web -- especially if the input to that process is e-mail. Jennifer Hunt Systems Design Engineering University of Waterloo jehunt@zeus.uwaterloo.ca ------------------------------ Date: Tue, 12 Mar 1996 06:26:30 GMT From: Jonathan Kamens Subject: Re: Netscape's too-lenient syntax checking (Baker, RISKS-17.88) > I have nothing against Netscape trying to be smart, What Netscape does isn't merely "smart"; it's also a violation of the HTML specification. That specification defines what is or is not legal in an HTML document. Programs which purport to be HTML viewers are supposed to confirm that the document being viewed conforms to the HTML specification (e.g., not missing "" markers after "" markers) and complain if it doesn't. Unfortunately, Netscape decided, "Why should we write something which checks the HTML for validity, which we can just write a smart interpreter which figures out what the author of a document *wanted* to do, even if they didn't actually say that?" Henry Baker has already pointed out one problem with this -- it allows webmasters who use Netscape to test their HTML to be lazy about ensuring its correctness. Since Netscape is the most popular browser, and therefore more webmasters use it than any other browser to check HTML, users who don't use Netscape are often "shut out" of sites. Worse, Netscape has intentionally implemented numerous features that are not conformant with the HTML specification, that their browser supports but others do not. Instead of working through the process recognized by the HTML-design community for adding functionality to HTML, they just added the functionality they thought was needed. Since many sites take advantage of this additional functionality (it *is* pretty neat, after all), once again, users who do not use Netscape are "shut out". Rectifying the latter problem isn't simply a matter of adding Netscape's functionality to the HTML specification, because they've added functionality which is difficult, if not impossible, to implement in SGML (the Standard Generalized Markup Language, which is the meta-language in which HTML is defined). That doesn't matter to Netscape, since (as I mentioned above) their browser interprets the HTML in a do-what-I-mean fashion, rather than in a "Is this valid HTML?" fashion, but it matters to the rest of the Web community, since browsers which are trying to remain true to what HTML is supposed to be simply may not be able to implement the features which more and more sites are using. {Begin politics.} I find what Netscape has done totally reprehensible. There was a recognized body of people defining the HTML standard, a recognized procedure for implementing changes to that standard, and a recognized "proper" way to parse and display HTML code. Netscape threw that all away, and I believe that they were fully conscious when they did so that they were breaking the standard and causing lots of grief for the other HTML developers in the world. What they're doing is nothing more than an attempt to make Netscape, a commercial product, the only browser that can be used to access the full potential of the Web, which is supposed to be free. The sad thing is that they may very well end up succeeding. {End politics.} (Thanks to Andrew Greene for teaching me most of this and proofreading this message.) ------------------------------ Date: Tue, 12 Mar 96 09:13:27 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Netscape too lenient syntax checking? (Baker, RISKS-17.88) > ... The problem is fixed, although I don't recommend > looking at the site with anything but Netscape 1.1N and higher. That won't always work either. After putting 2.0 on a machine I noticed large chunks of text on one site disappearing. Seens That with Netscape 1.x if it encountered a syntactical mistake such as it would realize that a double quote was missing on the end and, having reached the end of the anchor, "assume" one. Not 2.0. If the double quote is missing, things go wonky. So the *real* risk is to assume that "smarts" will propagate along with versions instead of correcting errors. Padgett ------------------------------ Date: Tue, 12 Mar 96 20:28:38 EST From: tilt+@UX3.SP.CS.CMU.EDU (Eric Tilton) Subject: Re: Netscape's too lenient error checking (Baker, RISKS-17.88) > ... Perhaps Netscape should have a `careful' mode for helping web page > maintainers to provide `squeaky clean' pages. It is for this very reason that I put together "Composing Good HTML," a few years ago (http://www.cs.cmu.edu/~tilt/cgh/). Netscape pays at least token attention to the problem, since they do have a reference to CGH in their own documentation. Also, several HTML syntax checkers exist. The real RISK seems to be that there is a popularly perceived "standard" -- HTML -- which is in reality incredibly balkanized, with each browser choosing to interpret different subsets and supersets of it in slightly (or not so slightly) different ways. And that people's perceptions of that standard are largely influenced by a WYSIWYG mentality that HTML only somewhat incidentally supports. ------------------------------ Date: Tue, 12 Mar 96 20:37:26 -0500 From: Torrey McMahon Subject: Re: Netscape's too-lenient syntax checking (Baker, RISKS-17.88) I recently was involved in a lengthy discussion in comp.infosystems.authoring.html about this very subject. Someone posted to an other mailing list I subscribe to that Netscape allows such sloppy behavior, in this case it was allowing a to be closed by a . The argument given to me in the USENET group was "Netscape is a HTML browser, not a validator. You can't fault it for correcting an author's bad HTML!" Of course most people don't use a validator they just fire up Netscape, load the page, and if it "works" they put it on their server. The compromise we seemed to settle on was the browsers should correct HTML to some extent but should also state that fact in a dialog box similar to the Arena browser. I was also taken back by their "Netscape bigotry". My favorite message was one person stating that since I don't use Netscape I shouldn't be complaining because I'm not using the Internet standard browser!!! (I'm using Omniweb 2.0 on a NeXT machine in case you're wondering. The risks? Taking one person's, or company's, HTML parser as the correct one. Netscape bigotry in use of tags, poor HTML, and attitude is an obvious other. Torrey McMahon American University School of Communication ------------------------------ Date: Tue, 12 Mar 1996 06:54:28 -0800 (PST) From: David@thermoteknix.co.uk Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88) It would be possible to get the unsuspecting reader to make multiple mailings - mail bombing. ISP are shutting down/deleting/revoking/stopping accounts at the moment due to a spate of mail bomb attacks. I hope they know about this. Risk: watch what you download or watch your account close. David Wood david@thermoteknix.co.uk ------------------------------ Date: Mon, 11 Mar 1996 17:21:03 -0800 (PST) From: Stanton McCandlish Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88) >A quick test on my local machine shows that this will send a message to >nasty@secret.org with the subject gotcha and the body "hi=there". Funny thing is, even though this is clearly not meant to be a real mailbox, there really *is* is a secret.org, run by a friend of mine in DC. I don't think there's a user ID of "nasty" there, but anyway, I thought it rather curious. Small world. Small net anyway. I suppose an additional risk inherent is silly cookies like this is that even when done as a joke, it's actually possible to create unintended bad effects, such as revealing user IDs to any actual nasty@secret.org who happened to appear, or inundating poor nasty with a form of "autospam", due to innocent Netscape users playing with the cookie and actually sending the suggested e-mail. Stanton McCandlish Electronic Frontier Foundation Online Activist mech@eff.org ------------------------------ Date: Tue, 12 Mar 1996 12:36:15 -0500 From: Jon Reeves Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88) I've gotten a couple of messages suggesting that altering the e-mail address in my Netscape identity configuration will defeat this trojan. Maybe on some platforms, but certainly not on a UNIX platform. However, I did get a helpful suggestion: setting your outbound mail SMTP server to a nonexistent machine (e.g., mailtrojan) will prevent this attack by disabling all mailto URLs. Of course, this makes Netscape useless as a mail program. [...] ------------------------------ Date: Tue, 12 Mar 1996 18:14:00 -0500 From: "john (j.g.) mainwaring" Subject: Re: Yet another Trojan horse in Netscape 2.0 (Reeves, RISKS-17.88) The problem Jon Reeves points out in RISKS-17.88 certainly is insidious. In my case, I think there's a slightly different risk. I don't use e-mail associated with the internet account I use for Netscape. I am one of three people in the world that use a mail handler written as a learning exercise a few years ago. I get my e-mail from a different dial up connection from the one I use for Netscape. I have a userid on the sytem I connect to through Netscape, and I'm willing to believe that Netscape is clever enough to get e-mail out 'from' that userid, even though I've done nothing to help it. If Netscape is able to send mail purportedly from me, not only would I never see it -- I'd never be aware if anyone replied (perhaps threatening me with some dire consequences of having 'sent' the e-mail?) On the other hand, I may have hidden access to e-mail well enough that even Netscape can't find it on my machine. If so, it would be a way to work around the problem Jon found, but probably not one that most people would find convenient. By the way, this posting is from a completely different machine than the one I described, but I don't run Netscape at all on this one. John Mainwaring ------------------------------ Date: 12 March 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) *** Illustrative Risks document now available in PostScript form. Below. *** The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for unabridged version of RISKS information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Particularly relevant contributions may be adapted for the RISKS sections of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. ***** DRAFT NEW TEXT, IN RESPONSE TO A STICKY SITUATION ***** By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited *noncommercial* public distribution and redistribution in electronic and print form. Other reuses normally require explicit permissions from the author. Anyone redistributing RISKS items for other than personal purposes should indicate that the material is derived from RISKS (the Risks Forum), that it is freely available, and that the author(s), the RISKS moderator, and the ACM have no connection with such reuse. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks ***** NEW ITEM ***** The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 17.89 ************************