| University of Bielefeld - Faculty of technology | |
|---|---|
|
Networks and distributed Systems
Research group of Prof. Peter B. Ladkin, Ph.D. |
|
| Back to Abstracts of References and Incidents | Back to Root |
| This page was copied from: http://catless.ncl.ac.uk/Risks/17.89.html | |
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Graduate Record Examination screwup
"What's new" in web pages is not necessarily reliable
Digital Flight Control Systems help the U.S. Navy
Re: CIA & NSA run remailers
Re: Rail safety controlled by satellite
Re: bleep-year
Re: UNIX struct tm
Re: COBOL Dates
Re: Teen `convicted' by computer
Lotto computer errors
Risks of automatically publishing Risks newsletter to the Web!
Re: Netscape's too-lenient syntax checking
Re: Yet another Trojan horse in Netscape 2.0
Info on RISKS (comp.risks)
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
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
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
>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
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).
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
> ... 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
> 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 alreadyActually, tm.tm_year is defined as the number of years since 1900.
noted by Steve Loughran in RISKS-17.85. PGN]
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.
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.
> 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
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
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
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> 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 "</A>" markers after "<A>" 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.)
> ... 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 <A HREF="foo.gif> instead of
<A HREF="foo.gif"> 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
> ... 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.
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 <b> to be closed by a </i>. 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 CommunicationIt 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
>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.orgI'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. [...]
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
| This page was copied from: | http://catless.ncl.ac.uk/Risks/17.89.html |
| COPY! | |
| COPY! | |
|
by Michael Blume |