Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The Australian Y2K readiness news page
http://203.2.193.77/news-index.cfm.htm
seems to have a clock problem. I was checking it as the time change swept
over Australia, and it "hung" at 23:56:15 for quite a while. I quit
watching it about half an hour later. I just checked it again and it's lost
over 15 days: The "last update" just jumped back to 15 Dec 1999, 00:23.
I wonder what the cause is? One of my co-workers has noted that other web
pages are having similar problems.
The Aukland (N.Z.) International Airport has a web site to keep the public informed on Y2K issues (www.auckland-airport.co.nz/airport_newsflash.html). This morning they issued a "News Flash" stating that "the airport is operating as normal. No Y2K problems have been experienced and all operations are continuing as usual." The News Flash is time-stamped "02:58 1 Jan 100". --John Wharton [Y2Kudos to Dave Farber, whose IP distribution is often full of RISKS items. This time his recent mailings have been chock full of fresh Y2K items. Dave, MANY THANKS, and Happy New Year to all of you! PGN]
I just have to share this... From NZ Herald, December 30 1999: "The Waitakere City Council (West Auckland, New Zealand) has fixed an embarrassing glitch in a millennium clock in Henderson that flashes a message telling people to be Y2K-prepared. In a test run on the clock, donated by a Korean couple, officials discovered that the message would have changed to "GAME OVER" at midnight on New Year's Eve." Do they know something we don't? Shades of that Arthur C Clarke story about the names of God... By the time this appears we will know.
Because central computers doing four-day diagnostic checks were unable to recognize the year 2000 as a valid date, as many as 20,000 credit card machines in England failed to allow merchants to "swipe" the cards through the machines during recent holidays, forcing the data to be entered manually and causing shopper delays. The machines are manufactured by Racal Electronics and supplied to merchants by HSBC, a bank holding company. A Racal executive says, "It is a software and date-related issue, which will be resolved and we're entirely confident that terminals will revert to full functionality at the start of the New Year." [Reuters/*San Jose Mercury News*, 29 Dec 1999; http://www.sjmercury.com/svtech/news/breaking/reuters/docs/35990l.htm NewsScan Daily, 29 Dec 1999, reproduced with permission]
In the UK yesterday 20,000 machines in shops across the UK were reported to be rejecting all credit cards as customers tried to pay for goods. The reason? The settlement date is four days later - January 1, 2000 and so the set of transactions that make up the credit payment crosses the date changeover. The problem may disappear in four days time, when the entire transaction set will be within the new millennium. Like most bugs, it is totally understandable and - given hindsight - totally predictable. As will be all the other Y2K problems that creep out of the woodwork. Let's hope that none of the other bugs are life threatening. john.locke-wheaton@bigfoot.com +44 (0) 7044 011 532
DefenseLINK, the Pentagon's main Web site, ws intended to keep the public assured that Y2K was a nonproblem for DoD. However, the site was accidentally disabled on 30 Dec 1999 when other sites were taken off the Net to guard against cracker activities. The process of restoring service was hindered by admins corrupting the domain name server. [Source: PGN-ed from CNN http://www.cnn.com/1999/TECH/computing/12/31/y2k.reports.roundup.01/index.html]
[This item is retitled and adapted from the IP list of Dave Farber <farber@cis.upenn.edu>.] KCBS radio is reporting this morning that the Oakland 911 Emergency call system has determined its call prioritization algorithm is, well, technically speaking, /not/ fully Y2K compliant yet. Apparently incoming calls are timestamped with just a two-digit year code. Normally the call routing software gives top priority to the oldest (=earliest) calls, as one would expect. Alas, this means that as of the Friday midnight roll-over, all pending calls will instantly be kicked to the bad end of the priority list. As I interpret the news reports, the post-rollover calls will be stamped 1/1/1900, and, naturally, anyone who "just" called — at 11:58 Friday evening, say — is in far less dire straits than people who have been on hold for nearly 100 years. Oakland's solution, the 911 officials say, will be that, starting at 11:50pm or so, all not-yet-dealt-with calls will be transferred to a different phone system to ensure that they don't get lost. Dispatchers can then continue dealing with existing emergencies while newer calls queue up normally until dispatchers again become available. (The moral? It's probably best /not/ to have an emergency in Oakland during those last few minutes before midnight...) >===== My first impression was that this was a terribly embarrassing oversight, for this problem not to have been "fixed" months ago. Date-stamps being processed backwards is /exactly/ the textbook example of what happens when the year field overflows. On the other hand, it /does/ seem the problem will be terribly short-lived, affecting maybe five or ten minutes' worth of calls — ever. After 12:10am or so, then, and for the remainder of the next century, the original call prioritization algorithms should continue to work just fine. Whereas re-opening the program source, rejiggering the code, augmenting the data structures and so forth could quite plausibly introduce new problems and incompatibilities that might bedevil emergency call processing for months. Leading one to wonder: was this just an embarrassing oversight? Or a deliberate, rational cost-benefit decision to leave sleeping codes lay? --John Wharton [Note added later in Dave Farber's IP from John: (If) unchecked, this WOULD have been a most-life-threatening oversight.]
While performing a Y2K check of a client's computers, I discovered a small program, written in BASIC, which suggests an entire class of potential Y2K glitches which has not been publicized and may plague us on or after January 1, 2000. In the client's back office was an older PC attached to a modem. Each time the computer was booted, it ran a simple program which instructed the internal modem to make a brief telephone call to a telephone number somewhere in Colorado. Upon connecting, the computer received the date and time, set its clock accordingly, and then hung up. Inspection of the program revealed that it received and used only two digits for the year. What number was the computer calling? After a bit of snooping on the Internet, I discovered that the number was that of the Automated Computer Time Service (ACTS), provided by NIST (the National Institute of Science and Technology, previously known as the National Bureau of Standards). The time message received by the program, derived from an atomic clock, looks like this: JJJJJ YRMODA HH:MM:SS TT L DUT1 msADV UTC(NIST) OTM where JJJJJ is the Modified Julian Date (MJD); YRMODA is the date (two digits each for year, month, and day); and HH:MM:SS is the time in hours, minutes, and seconds. (The remaining fields are documented online at http://www.bldrdoc.gov/timefreq/service/acts.htm.) What is interesting is that the BASIC program provided by the NIST itself (the same agency, ironically, which distributes the Malcolm Baldridge quality awards and offers Y2K help to small businesses) ignored the Julian date and used only the two-digit year to set the computer's clock. This software was posted on the Internet by the NIST until approximately last October. While ACTS can be used in a Y2K-compliant manner, the way to do this is somewhat arcane (few programmers understand the concept of a Julian date, and conversion is tedious). Perhaps this is why the NIST's own software -- which was doubtless used verbatim or as the basis for other programs — cut corners, as most programmers were likely to do, and used only the two digit "YR" code for the year. According to the NIST's ACTS Web page (http://www.bldrdoc.gov/timefreq/service/acts.htm), more than 10,000 computers call the NIST's number each day. How many are running that old BASIC program, or similar ones published on computer bulletin boards, in magazines, or on the Internet, which have the same flaw? But wait.... It gets worse. Apparently, the time code transmitted by ACTS is similar to that used by the NIST's radio stations --WWV, WWVH, and WWVB -- to transmit time and date information the entire world. WWV's binary coded decimal format, described on the Web at http://www.boulder.nist.gov/timefreq/pubs/sp432/s_appb.htm, also uses only two digits for the year. Worse still, the Julian date is not present, so there is no way, using this code, to distinguish between the years 1900 and 2000. Alas, some digital logic circuits which interpret the codes from WWV, WWVH, and WWVB are literally hard-wired to the existing format. (According to some quick research I've done on the Net, these range from an old Heathkit called "The Most Accurate Clock" to laboratory instruments to traffic signal controllers.) So, the NIST does not have the option of changing the format to include a 4-digit year for fear of breaking this equipment. Unfortunately, it is unclear whether owners of this equipment are aware of the potential problems in these embedded systems — some of which, again, use hard-wired digital logic rather than microprocessors. Will traffic signals in Los Angeles and Orange County, which are said to use WWV as a time standard (http://www.odetics-its.com/showcase/TASK2-2/la.html), fail? Or will they become confused about the day of the week and snarl traffic by using "weekend" timings on a weekday, or vice versa? What other municipal, scientific, or military embedded systems will go awry because they rely on the NIST's 2-digit time codes? Ironically, while the NIST Web site contains an article (http://www.nist.gov/y2k/embeddedarticle.htm) warning users to evaluate embedded systems for Y2K compliance, I have been unable to find any article in which the NIST mentions the format of its own time signals as a potential source of Y2K problems. Today, when I used the "Advanced Search" facility on the NIST's Web site to search for the call sign "WWV" together with the term "Y2K" or "2000," it failed to turn up any hits whatsoever. The NIST's Y2K compliance page, at http://www.nist.gov/y2k/nistcomp.htm, lists both ACTS and the agency's "time synchronization" services as Y2K compliant. Conclusions are left as an exercise for the reader. --Brett Glass
[Source: Bank blames error on printing vendor, Dee DePass, *Minneapolis Star Tribune*, 21 Dec 1999; PGN-ed] Wells Fargo & Co. sends out a batch of renewal notices - dated 1900 Wells Fargo & Co. experienced its first public Y2K glitch last week when it mailed 13,000 certificate-of-deposit renewal notices with the year 1900 on them. The bank said the notices told customers in 10 states that their certificates would expire in January 1900 instead of January 2000. It isn't known if any Minnesota customers received the letters. Wells spokeswoman Teresa Morrow said the error was attributable to a statement-printing vendor who forgot to change the date on its printing machines. Morrow said Wells sent statements to the printer that said 1/15/00 and the vendor mistakenly translated the 00 as the year 1900. The mistake was discovered Dec.13, and officials immediately sent out letters apologizing for the error. Customers were told they would receive revised renewal notices in a few weeks. Morrow said, "We asked [the printer] if it was Y2K related and they said, 'It was just us not setting our date on our printer.'" Morrow said she didn't know if the mistake would alter Wells' relationship with the vendor. She added, "If that is the worst thing that happens to us with Y2K, then we will be set for life." Still, observers called the error an embarrassing blow to a company that just last week declared it and its critical suppliers were ready for Y2K, after having tested all its computer systems three times. Federal regulators and the Minnesota Bankers Association have repeatedly said all banks in Minnesota are ready for Y2K and don't expect any problems. Even so, Wells Fargo and its competitors are staffing technical command centers for four or five days after New Year's Eve, just in case a more serious glitch occurs. While most banks will be closed for the New Year's Day holiday, many will have technical staff in the branches checking on lights, heat and computers. The risks: not testing the low-tech procedures for updating date information — "Well, we never changed that part of the date before."
> Millions of people using older versions of Netscape and Microsoft Web > browsers may not be able to access some personal finance and e-commerce > sites starting January 1. It won't be due to the dreaded Y2K > bug. Instead, it's because electronic credentials embedded in browsers are > set to expire on Dec. 31 at midnight. This is the lead of an article in the *San Jose Mercury News* on 29 Dec 1999, which warns that secure transactions may fail or be blocked because of expiring digital certificates. Many banks are posting warnings to their customers, warning that they need to update their net browsers, and SOON !! Microsoft's Internet Explorer for Macintosh only discovered this problem in the last three weeks and posted a fix on Dec 21. I especially enjoyed this quote: > Ben Golub, VeriSign's director of Internet marketing and sales, said the > Dec. 31 expiration date was chosen about five years ago because at the > time browsers couldn't accept dates beyond 1999. > "In retrospect, maybe we should have chosen December 15," he said. "It's > just an unfortunate timing kind of thing."
There are multiple risks, apparently, involved with multiple types of dates. Experts said early efforts focused on checking dates — typically identified with a heading "mm-dd-yy" or "date" — buried within computer code. But prankster programmers sometimes used unusual nomenclature that can make these date variables nearly impossible to find. Data Integrity said it found a date field called "Shirley" when it reviewed software at a major bank in the Northeast, which it declined to identify. The programmer responsible, it turned out, was dating a woman named Shirley when he wrote the software. [Source: The Year 2000 Challenge, *Wall Street Journal*, 30 Dec 1999]
Jane Garvey, the FAA administrator, was quoted that a late software patch was applied to her agency's critical ``HOCSR'' computers, which process flight plan and radar data for controllers. The repair was completed early on 30 Dec. Garvey said the minor problem turned up during continued testing of the agency's systems, which were declared Y2K-ready in June. ``We're continuing to test right up to the last moment. We erred on the side of caution. The patch is in. It's been fixed. It's a very, very minor issue.'' ["Last Minute Y2K precautions Taken", *The New York Times*, 31 Dec 1999 <http://www.nytimes.com/aponline/w/AP-Y2K-National.html>] Assuming the story is accurate, RISKS readers will undoubtedly wonder whether whatever benefits this fix might convey will be outweighed by the risks of patching a critical system the day before the very event that will trigger the execution of the patched code. Given the combinatorially explosive number of potential interactions in any complex system, it seems strange indeed to conclude that *any* change is just a "very, very minor issue". Pondering this question will certainly give me something to do on my Saturday morning flight... matt
> 1) The generator is in a hastily built wooden hut secured with a padlock. > The hut is located on the outside wall of our data center. 3,500 gallons > of boom. Most large generators are diesel. I don't know if this particular generator is diesel, but if it is, diesel does not go boom, and it doesn't burn very well, either. It's about as stable as cooking oil. Gasoline, in its liquid state, does not go boom either. It does burn pretty well, though. If you had an almost empty tank of gasoline, you could have enough vapor that it might go boom. I'm not a chemical engineer, so check this with other sources if you like. Scott Nicol <snicol@apk.net> [Lots of you commented on this gaffe. PGN]
> All of our upper management is absolutely terrified of the end of this > year. They are convinced that there is going to be a major disaster > at the stroke of midnight. Would it frighten them any more, to know that power companies generally operate on GMT? The risks of failing to understand this necessity of managing a power grid connecting multiple utilities and spanning several time zones, are: + presumption of more time for disaster preparation, than actually exists, should fears be justified; and + hysteria over impending doom, after the possibility of its occurrence has passed, should fears be unjustified. I keep telling people where I live, that they can stop worrying about their electric power, shortly after 7PM. West of here, people can stop worrying even earlier (4PM in California, for example). Even if a few generating facilities did fail, unless they lost station- keeping power, those facilities would remove themselves from the grid, immediately. As far as I know, it's become standard practice to have battery-backed station-keeping power, since a station without it caused a major regional blackout in the Northeastern US, some years ago. (Either their backup generator failed while the others were down for maintenance, or vice versa; I don't remember. The story comes second-hand from a former colleague, who, at the time, worked at a nearby manufacturing plant, whose generators were used to provide the power to bring the station back online.) [...]
Various issues involving leap-seconds have been discussed in RISKS in the past. One of the most creative was "Length of Day & Reservoirs" by Scott Lucero in RISKS-17.87, suggesting that we might avoid future leap-seconds through calibrating the Earth's actual rotation rate by selectively filling reservoirs. (Some mechanism would be needed for recalibrating the Earth once the reservoirs were full...) The time and frequency community is in the early stages of considering a proposal to simply stop issuing leap-seconds. (Alternatives are also being considered.) There has been some rousing discussion of this in comp.protocols.time.ntp and sci.astro.fits (among others). Possible risks include Y2K-style risks of software and firmware relying on |UTC-UT1| < 0.9s. More fundamentally, this would be a change to the original design requirement of UTC that ties clocks around the world to our most visible standard of civil time - the Earth itself. The general risks are similar to other small communities that control technical resources (for instance, utility companies) used by virtually everybody. The effects of overtly minor operational changes are highly non-linear and can be magnified immensely. For a sense of the scale of the change, a century of leap-seconds is about equal to half the width of the sun or the moon on the sky. This is enormous for some purposes, negligible for others. Should we take comfort or dread that the metrologists are debating this issue with Y2K looming? Rob Seaman
A month or so ago, I was trying to order plane tickets via the Travelocity Web site, when I noticed that--though the page I was looking at prominently claimed to be "secure", and even had a link to click on where they explained in detail why it really did protect your privacy--Netscape (4.5 for Windows) didn't agree: the little lock icon on the bottom was open! I asked for Page Info, and that confirmed that the connection was not secure. Needless to say, I didn't go ahead with the purchase. Much more recently, I was trying to order a CD from the U.S. Public Radio Music Source (www.75music.com) when what appeared to be the same thing happened. But this time Page Info showed the connection _was_ secure, and I went ahead and gave them my credit card info. The RISK? Presumably the chance of outsiders seeing your confidential information because what you assumed was a secure connection really wasn't. Of course one should never trust a Web site's statement that the page you're viewing is secure, but if it's an outfit as well-known and reputable (as far as I know) as Travelocity, I'll bet a lot of people will assume it is--especially if they explicitly tell you how they're protecting your confidential information, as this page did. My experience also raises the question as to whether you can even trust the browser to tell you if you have a secure connection; I sure hope so, at least if JavaScript is disabled (I seem to recall the Princeton group pointing out that JavaScript can take over the browser's UI almost completely). Don Byrd, Center for Intelligent Information Retrieval (CIIR), Computer Science Department, UMass, Amherst, MA 01003 dbyrd@cs.umass.edu 413-545-3147
Sanity.com, the Australian company who keen readers will remember as allowing purchases of CDs without payment (RISKS-20.68), have stuffed up again, this time sending all their customers an e-mail that included the e-mail addresses of more than 140 of its customers. This violated their own stated privacy policy. [Source: Fairfax newspapers - *The Age* and *Sydney Morning Herald*, PGN-ed from John McLean, Zurich, Switzerland; http://www.it.fairfax.com.au/e-commerce/19991222/A52132-1999Dec22.html]
A friend recently asked me to join an online "community" which he had created on a service called Intranets.com (http://www.intranets.com/). There was some sort of verification code to enter, then I was asked to create an account, including a username and password. I went ahead and did so. To my utter surprise, I then received an e-mail message from welcome@intranets.com containing the login and password I had provided! The risk is clear. Electronic mail is an inherently insecure medium, both because of the way it is generally stored and because it is transmitted as clear text over TCP/IP networks. Not only is the security of an account on Intranets.com jeopardized by this practice, but if someone should use a password which they already use for other services, then their other accounts are also at risk. Intranets.com does have a privacy statement, including a section on security, but there's nothing there which would lead one to believe that the company would do something like this. The lessons for users? First, when signing up for a service, never use a password which you wish to keep secret. If you wish to have a consistent password across sites (itself a risky practice), you should change the password after you've signed up. And even then, you should probably perform an experiment to make sure the site isn't so daft as to send you a copy of your changed password in the e-mail. The lesson for developers? Security mustn't be so difficult to use that users and website owners are tempted to defeat it by practices such as reusing passwords and sending them over e-mail. The answer may lie in something like the digital keychain which I've read is contained in MacOS 9. However, unless there's a way to take your keychain with you (on a disk, card, etc.) or to access it from a central location (via a trusted keychain storage site), this will only work for people who access the web from one computer.
Please report problems with the web pages to the maintainer