As part of the process to transition our mail server from our old, slow, dusty one to our new, fast and shiny one, we had to move all of our mailing lists to the new server. Of these lists, RISKS is the most heavily used. The list file itself contains over 7000 e-mail addresses (many of which are redistribution addresses). During the process of subscribing all e-mail addresses to the new list, there was unfortunately a short period of time when the list was unmoderated. Inevitably, a SPAM message managed to get through! I managed to catch and stop the message before it was sent to all list members, but unfortunately it was sent to at least 2, but not more than 1949 addresses. [PGN: I heard from about 10 thus far.] During the next few days, we will be tweaking the configuration for the new RISKS list. I would like to take this opportunity to apologize in advance for any hiccups we have during this process. If any RISKS list members notice any problems with the list, please do not hesitate to e-mail me at email@example.com so that I can address these issue promptly. As before, all subscription and unsubscription requests should be sent to firstname.lastname@example.org. For problems regarding subscription and/or unsubscription requests please send e-mail to either email@example.com or firstname.lastname@example.org. Thank you, Michael Hogsett, System Administrator SRI International Computer Science Laboratory [One of the benefits of the new majordomo service is that I will no longer have to wade through the several hundred bounces that I get on each issue. Many thanks to Mike for a major (domo arigato) effort. PGN]
I just received a message about an error from the RISKS Web server saying that the latest edition - named on the front page - was not a valid issue. It would seem that the request was sent through a cache through which someone had previously requested the page *before* it really did exist and so the error reply was cached under the name of the genuine page. The error is generated dynamically so I can't just divert the reply to a fixed page, so I will have to turn caching off on error returns. Obvious? Probably, but I didn't think of it (no surprise there then) and I haven't seen in it any lists of stupid Web programming errors! Lindsay <http://catless.ncl.ac.uk/Lindsay>
There have, for some years, been a number of scams whose victims are tricked into making what they think is an ordinary phone call, but actually incur surprisingly high charges some or all of which go to the scammer. Apparently an urban legend (UL) is now circulating on the Internet saying that these charges can go as high was $2,400 per minute. This is false, but in a current thread in comp.dcom.telecom, John R. Covert says it was reported as fact (due to inadequate checking) by Boston radio station WBZ. Linc Madison now suggests that the origin of this UL is MIME quoted-printable (QP) encoding. We've probably all seen this at some time: any character that "might not get transmitted correctly" turns into an = sign followed by two characters giving its numerical value in hexadecimal; for example, if you spell "role" with a circumflex accent in ISO 8859-1, it becomes "r=f4le". Messages containing QP are supposed to be identified by MIME header lines that say so, and restored transparently to their 8-bit form by one's news or mail reader. But some people use older software that doesn't understand MIME. And sometimes a message gets quoted in QP form with the header lines stripped off. This is especially likely to happen with a repeatedly forwarded message like an Internet ULs -- or in a digest environment like Risks. Now $ is not usually considered a character that might not get transmitted correctly, but it *is* special to UNIX shells, so someone might cautiously configure it to be encoded. And what's $ in hexadecimal, in ASCII and the ISO 8859 character sets? 24. So, as Linc says, "Thus $25/minute turned into =2425/minute, which some helpful human turned into $2425/minute. If you ever see a spam claiming $242,425/minute, just remember you saw it here first." (British pounds have a similar problem to a lesser degree. The pound sign in ISO 8859-1 is hexadecimal A3, so in similar circumstances 25 pounds could turn into 325 pounds. I think a case of this actually has come up in Risks.) Mark Brader, Toronto <email@example.com>
A U.S. Marine commander has admitted falsifying the maintenance records of the tilt-rotor V-22 Osprey squadron, which has long been plagued with problems and whose development has been highly contentious throughout the previous two decades. (See RISKS-11.94, 11.96, 12.13, 12.15, 12.40-42, 12.60, 12.73.) The doctored records include assigning flight-worthy indications to Ospreys that could not fly, presumably in an attempt to justify the viability of the aircraft. This is of particular concern following the two crashes in 2000 (in which 23 marines died). (See RISKS-21.14.) [Source: Article by Elizabeth Becker and Steven Lee Myers, *The New York Times*, 20 Jan 2001, National Edition p.A7; PGN-ed]
A security breach at Travelocity recently exposed the personal information of up to 51,000 online travel company's customers who had participated in a site promotion. Customer names, addresses, phone numbers, and e-mail addresses were revealed because of an inadequately protected directory -- possibly for up to a month. This resulted from new servers cutover from San Francisco to Tulsa. [Source: Troy Wolverton, CNET News.com, 22 Jan 2001 http://news.cnet.com/news/0-1007-200-4564919.html]
You'd think they'd know better. Network Solutions, which issues most .com, etc. domain names, sends promotional mail to the e-mail addresses of domain holders. They include a URL for the recipients to use to remove themselves from that mailing list. If you use that URL, it replies that "<associated email address> has been removed". However, the URL uses a simple "id=NNNNNNN" field to specify the name to remove, apparently with no validation. Not only could someone easily rig up a program to run through all IDs sequentially and remove each one from the Network Solutions mailing list, in the process it would also be possible to gather the e-mail addresses of the accounts involved, which could provide a wonderful mailing list for targeted spams.
Millions of people have been prevented from visiting dozens of Microsoft websites today. [For extensive discussion on this, visit Declan's Web site: http://www.politechbot.com/ with background at http://www.politechbot.com/p-01662.html To subscribe to POLITECH, visit http://www.politechbot.com/info/subscribe.html See also a later report: http://washingtonpost.com/wp-dyn/articles/A40787-2001Jan24.html PGN]
Off by one errors are common. Another one just caused people to get the wrong 401(k) statements, disclosing information like social security numbers, birth dates, and balances to the wrong person. This has occurred before: see RISKS 19.26 for example, with a posting by an anonymous correspondent. See http://washingtonpost.com/wp-dyn/articles/A36460-2001Jan23.html --Jeremy
As owner of the domain "dweeb.org", I find myself receiving more than my share of spam. Upon casual inspection, it seems this is no accident. In the process of registering for various Web sites or software usage, it appears that certain people have been avoiding spam by claiming that their e-mail addresses are "firstname.lastname@example.org", "email@example.com", and similar variants.
A quote from a message sent to a list I am on: >Or HTML being rendered automagically without some restriction of >functionality, even if *that* is done within tcl/Tk instead of an >external program. (Think "Web bugs". When some scientific conference >requested that submissions be sent in HTML, I used a <BODY BACKGROUND=> >pointing to my Webserver and presto, not only did I see in the Web logs >who was refereeing my paper - highly confidential info, as far as >confidentiality goes in academia -, I could even tell how thoroughly >they had read it in the first place!! 8-} ) > >(To add insult to injury, when these guys confirmed receipt of >submissions, they sent Word *.DOC's, which included a list of the last >ten files loaded into Word - and they had chosen to name the files by >submission number *and contact author*. Oooooooops again - the names of >authors whose papers were rejected are the *other* confidential data in >scientific conferences ... Oh, did I mention that the first version of >their Call for Papers read "please send HTML, double spaced, no more >than ... pages"?)
Kamens [RISKS-21.19] in reply to Berman [RISKS-21.18] asked: >>About 4 years of notes and phone numbers lost (yes you can back it up >>to a computer - The backup kit cost about the same as the organizer). > > And what is the "cost" of reconstructing the four years of notes and > phone numbers? I can't imagine that it's less than it would have cost > to buy and use the backup kit. The answer misses the point (I had considered a more forceful formulation of the same assertion). I suffered a disgraceful degradation of my Palm III over, I guess, about 3 months. I'd been using it for about 2 years, had become reliant on it, and backed it up regularly. My backup was purely that, and had no GUI, because it was Linux freeware recompiled for Solaris. I wanted just a backup, not a computer interface to the Palm. The Palm quit one day. Soft reset didn't reset. Hard reset didn't work. Dead. I went home. First problem I had ever seen in two years of operation. Two hours later, I found that indeed my hard reset appeared to have reset the device. I reloaded it from backup. No calendar entries from the last 3 months (disaster: some of them were vital for legal proceedings). None of the recent entries in my address db were there. I looked at the file modification dates on the backup machine. Many had not been modified for months, despite my regular backups; even those which showed more recent modification dates appeared to have older data. The on-screen notifications "<filename> backed up" (or whatever it was) had just been lies, for an indeterminate period of time. This is not hard to understand. But when it happens to you, it is cognitively hard to believe. There is no simple way to duplicate paper-based algorithms. Whatever you have on paper, you can photocopy once a month and keep somewhere else, and you are guaranteed that the original and the copy remain unaltered; if one disappears, you know it right away and can use the other. Try to duplicate that with a computer. Suppose I had had what I missed: a GUI interface to the backup. The GUI shows me a tiny fragment of one largeish database at a time. What would it take for me to tell that something was missing, and that that was not the only thing missing, and that each time I backed up, something more went missing? What would it take for me to notice that the db had remained approximately static, although I had made new entries (maybe the new entries were there, but consider behavior in which new entries were made at the expense of older ones)? Exactly what algorithm would you suggest that I use to ensure my digital organiser plus backup had the same or better trustworthiness properties as my paper version? Much, even most, of the discussion on recovery from failure of computer-based processes assumes that the failure is catastrophic, sudden, and overtly remarked, and that previous states were veracious. In other words, that the computer system breaks just as a tire punctures. Well, that's not the way things always work. Digital systems also fail "live", and that is not just theory. I spent some years seriously trying to develop paper-free work. Now, everything remotely important to me goes on paper, even when written on a machine. For much of it I ensure there are two spatially separated paper copies. I mostly use the paper copies for backup; even on-line backup via scanners. it isn't perfect, but I recommend the practice, and shall continue to do so until someone offers me usable algorithms for digital devices with properties at least as durable as those of the paper-based ones they will replace. PBL
>> ... Meanwhile, a 1999 survey found that Fortune 1000 companies lost >> more than $45 billion in thefts of proprietary information that >> year. [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001] In RISKS-21.19 Mark Hull-Richter writes: > I am HIGHLY skeptical of all claims of losses by large corporations. > How does this $45 billion number come about? How does a company arrive > at the amount of money they actually lost due to theft of proprietary > information? I can give a first hand account of a $2 billion theft of proprietary information to illustrate how these exaggerated figures get manufactured. Back in 1989 I worked at a Toronto software development company that did lots of work with the Unix operating system, and licensed the Unix source code from AT&T for about $60,000 a year. Night after night someone was logging in to the computers from a dialup line to download chunks of the Unix source code. Somebody at the company noticed this, called in the police, who traced the connection to an ex-employee, raided his house and seized his home computer. Apparently the ex-employee, a software development manager, who had recently left the company, missed having access to the Unix source code and wanted to grab a copy of it for personal study. Satisfied that the source code had been recovered, and that this wasn't a case of espionage or sabotage, the company would have been happy to let the matter drop. But the cops insisted on laying charges and it appears that they leaked the story to the media. All three Toronto newspapers (Toronto Sun, Toronto Star, and the Globe & Mail) reported that the police had foiled a $2 billion theft! Why wasn't this as a $60,000 theft of a commercial source code license? Or at the very most a $500 theft of an educational license, since the ex-employee's intended use was only to study it? Well it seems that the police had called up AT&T and asked them "How much is Unix worth?" The answer was $2 billion. AT&T gave Unix an asset value of $2 billion on their books. The police equated a little mischief to the cost of acquiring total ownership of AT&T's Unix System Laboratories and all its intellectual property! In this case, the large corporation gave an accurate estimate to a bogus question. It was law enforcement (and sloppy fact checking by the media) that twisted the story. But you know, even the $2 billion asset value seems suspect to me now because AT&T sold Unix to Novell in 1993 for just $270 million (see http://www.att.com/press/0693/930614.ulb.html). Novell in turn sold it to SCO in 1995 for a paltry $54 million (6M SCO shares at about $9 each is $54M, see http://www.novell.com/company/ir/96annual/mandis.html). But if AT&T overestimated by tenfold, the police still exaggerated by 4 million fold.
The Extreme Ultraviolet Explorer (EUVE) satellite was launched in Jun 1992 to do astronomical observations in the extreme ultraviolet (100 - 1000 angstroms). Its primary mission was planned for something like 18 months, but a series of extensions has kept the satellite running ever since, operated by UC Berkeley and NASA. Money is finally running out, and it's scheduled to shut down on 31 Jan 2001. On 1 Jan 2001, a planning system that checks observing plans against operational constraints suddenly failed. A Y2K+1 bug? Not quite. Many of the constraints are based on the relative positions of the sun, moon, and planets. (e.g. "Don't point the telescopes at the sun.") A solar/lunar/planetary (SLP) ephemeris file which provides this information to the planning system was valid only through 31 Dec 2000. OK, someone forgot to do the annual update, right? Nope. Solar system motions are well-known and predictable over long time periods. The SLP file covered a 10-year period; it was the only one ever used by the mission. No provision was made for updating the file, since at the time EUVE was launched, nobody expected the mission (even with extensions) to last through 2000. So it's a classic problem of legacy software and data. The original programmers are long-gone. Nobody knows quite where the original file came from, and the (binary) format is different from SLP data used on more recent missions operating with similar constraints. At this point it's unlikely that an updated file will be available before the mission shuts down, so the operations team at UC Berkeley is just bypassing the SLP checks. That's a risky choice, but reasonable, given that they have only a couple of more weeks of operations. You have to wonder what they would have done if the mission had been extended for another year, though. George C. Kaplan, Communication & Network Services, University of California at Berkeley 1-510-643-0496 firstname.lastname@example.org
Well, Flex doesn't know about such a rule mainly because there isn't one; the Gregorian leap year rules are just for 4/100/400 years, no 1000-year rule (nor 4000 or 10000, which I have also heard about). In this note at least it's quoted as "something like that", but such errors have also found their way into code, such as the PostScript code quoted in the note by Eric Lindsay which immediately followed the one above in RISKS 20.19; I wouldn't be surprised to find out that such code was responsible for some Y2K bugs (it seems not all of them have been discovered yet). The RISK here of course, that of generating code out of algorithms that the programmer knows at "something like that" level, instead of taking the trouble to check out the facts before coding. Amos Shapir <email@example.com>
The discussion of the Norwegian State Railway (NSB) troubles with the 2000/2001 transition focuses on fairly advanced causes, such as the 54-week situation. The discussants (including our esteemed moderator) seem by this to believe that the NSB is a competent and responsible organization. As recent events (such as a horrible rail accident with 19 dead where it turned out the railroad had a number of Single Point of Failure situations, or the fact that the new high-speed "Signature" trains had been built with axles that cannot tolerate high speeds and turns at the same time) has shown, this organization has completely lost the public's confidence (as witnessed by the recent, forced departure of its CEO), as has its locomotive supplier ADTranz. My hypothesis is that the 2000/2001 bug was a regular millennium bug, found in 1999. The problem was then "fixed" by turning the clock back one year to buy time, and promptly forgotten. Now NSB and ADTranz has turned back the clock back once again. This time, with the newspaper and RISKS interest, they are unlikely to forget. Espen Andersen <firstname.lastname@example.org>, Norwegian School of Management (www.bi.no) +47 6755 7177 European Research Dir., The Concours Group www.concoursgroup.com
Standards are great - but it's RISKy to assume that they are being adhered to just because they're published and sensible. I led a y2k remediation project in 1999. I saw the source code for literally thousands of programs. Some code anticipated a leap year, but never exactly to the standards (IE the code would have accepted 1900 as a leap year). Very seldom were date and time presented in any kind of standard format. I'm willing to bet that if I asked all the programmers at my office what ISO and RFCs are not all of them would know about ISO, and less than half would have heard of RFCs - and nearly all of them wouldn't see the point. This sounds disparaging, I know. I'm a programmer myself, so I do know whereof I speak. I never worked for an employer that stipulated adherence to any ISO standard. I have dealt with 3 "Web design houses" who had no knowledge of RFCs. If standards had been adhered to then why did we have a Y2k problem? And why do we know have systems unable to roll into 2001?
> I've tried to find a year that has 54 weeks using the ISO definition, > but failed. A detailed discussion of the ISO 8601 international date and time notation standard, including a proof for why years can only have either 52 or 53 weeks according to the international standard week numbering scheme, can be found on http://www.cl.cam.ac.uk/~mgk25/iso-time.html ISO 8601 has been adopted as a national standard in quite a number of countries over the past few years and it seems to enjoy rapidly increasing popularity. Computer experts should definitely make themselves familiar with it. Apart from standardizing a consistently bigendian numeric date and time notation, it should also encourage in particular US users to finally give up the awkward, error prone, risky, ambiguous and inefficient am/pm time-of-day notation in favour of the modern and elegant international standard 00:00-23:59 notation. The antique 12h am/pm notation that is still so widely used in the US even in airport time tables has *many* disadvantages like: - It is longer. - It takes somewhat more time for humans to compare two times in 12h notation. - It is not clear, how 00:00, 12:00 and 24:00 are represented. Even encyclopedias and style manuals contain contradicting descriptions and a common quick fix seems to be to avoid "12:00 a.m./p.m." altogether and write "noon", "midnight", or "12:01 a.m./p.m."+ instead, although the word "midnight" still does not distinguish between 00:00 and 24:00 (which are the standard notations for midnight at the start and at the end of a specified day). - It makes people occasionally believe that the next day starts at the overflow from "12:59 a.m." to "1:00 a.m.", which is a quite problem not only when people try to program the timer of VCRs for shortly after midnight. - It is not easily comparable with a string compare operation, so it doesn't automatically sort correctly in alphabetical listings. - It is not immediately obvious for the unaware, whether the time between "12:00 a.m./p.m." and "1:00 a.m./p.m." starts at 00:00 or at 12:00, i.e. the am/pm notation is certainly more difficult to understand. I don't understand, why in the US only the military and computer programmers see the many obvious advantages of the modern standard time notation. Perhaps the somewhat odd way of pronouncing the full hours in US English as "eighteen hundred", which the US military seems to have introduced, as opposed to the more natural "eighteen o'clock" for 18:00 might have scared the civil world from adopting it as well. Those interested in the above might also want to read the neighbour Web page http://www.cl.cam.ac.uk/~mgk25/iso-paper.html It describes another well-established highly elegant global standard that could -- if it were finally also adopted in the US and Canada -- eliminate a long list of risks and inconveniences in international document exchange and in the use of photocopying machines: A4 paper. Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK mkuhn at acm.org <http://www.cl.cam.ac.uk/~mgk25/>
Re: > Doesn't the problem of 54 weeks in a year depend on how week numbers are > calculated? Of course it does! Our modified paper, at http://www.allegro.com/papers/54.html, makes that clearer than the original version. Unfortunately, version 2.0 of the paper never got posted at year2000.com. > The ISO standard for dates and times (ISO 8601) works differently by > starting weeks on a Monday (that's not the important bit) and making Week 1 Yep. But, as we point out, standards don't matter if you're doing it differently. And, some people definitely do it differently. One of our customers uses the "Sunday is first day" logic, and ran into the 54 week problem. Stan Sieler <email@example.com> www.sieler.com
Please report problems with the web pages to the maintainer