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…
Insisting that "there's nothing funny about things that aren't funny," Professor Wiley T. Langweile of the Palo Alto (CA.)-based Institute of Internet Reevaluation has written a searing letter to *The New York Times* (1 Apr 1999) protesting that the American media are so bored with the Year 2000 problem that they're mentioning it only once in every 94.5 sentences (by the professor's own hand-count). "Journalists are just not giving enough publicity to this impending crisis. They're either ignoring the problem entirely or making fun of it. Either way, they're acting unconscionably. Y2K irreverence needs to be banned, especially on the Internet." Dr. Langweile further charged in his letter that most reporters fail to include in their stories a detailed explanation of just what exactly the Y2K problem actually is and what it means to everyday people. "The low level of media competence on this issue is just tragic. Of course, there's Edupage. That's the big exception. Those Gehl and Douglas people really know how to get to the point of a story, without wasting words. They're the only ones I can think of who've successfully explained Y2K in terms of the big hand and the little hand. I say God bless them." (Edupage, 1 Apr 1999) [Note to nonGermanophiles: "Langweile" relates to Boredom, not Coyotes. Definitely not the case here. PGN]
Please note the following! Washington DC (Reuters, 1 April 1999), Roger Tempus, News Staff In a sweeping move to alleviate the problems generated by the switch to daylight savings time early on Sunday morning, Congress voted today to move the switch to Monday. There has been a long history of confusion surrounding the switch to daylight savings time, and in a landslide vote this morning members of the house made a decisive move to make daylight savings a more attractive option. This was given wide support amongst the religious groups, concerned that people would be confused as to the timings of church services this Easter Sunday. Congresswoman April Jester (R, CA) confirmed the news this morning and announced that the changeover will now take place at 10am on Monday morning. In a dramatic turnabout, the state of Arizona decided that in light of this decision they too will adopt daylight savings time for 1999. Wall Street reacted angrily to the news, claiming that the lost hour of trading may drop the country back into recession. President Clinton is expected to sign the order confirming the change this afternoon, claiming that bedtime is just as, if not more, important than work time.
While reading several articles on the Y2K problem in the 1 April 1999 issue of RISKS-20-26, I noticed that none addressed the actual problem facing working programmers: there isn't enough time to finish the job before December 31. As we all know from The Mythical Man Month, we can't add more people to the project: the project will just take longer. What we need is another month. I propose Caligua. To honor Roman tradition, this would be added after August. This extra month should give us enough time to fix — and test -- our changes. While it will cause minor disruption to calendar makers and astronomers, they, along with all other citizens, will reap the rewards when the airplanes keep flying on 1 Jan 2000. And, if we need more time, we can always declare a Saturnalia. Martin Minow, minow@pobox.com [Martin drives a Saturnalias for Caligula. PGN]
Browsing the Web this evening (Thursday, March 24, 1999) using the new IE5 under Windows 98, I click a Favourite to load a well-known tech news site (http://www.slashdot.org/), then, with the site still loading, immediately press Control-N to open a new window so that I can load another site as well. A moment later, I'm a bit puzzled to notice that Slashdot hasn't been updated since Sunday the 21st. This is particularly puzzling since I had checked it earlier that day, using my work account, and it was up to date. My confusion is relieved a moment later, when I notice the site loading up in the background window (the one that was already open). I have been looking at the newly-opened window, which appears to have inherited one piece of state from the previous one (i.e., the URL being displayed) but not another (i.e., the crucially important fact that the site needs to be updated, not just redisplayed from the cache). Contrast this with the behaviour of other web browsers (e.g., Netscape Communicator 4.51). In a desultory test, Communicator acted correctly (i.e., displayed up-to-date information in a new client window, even as the previous window was still reloading the site). This was done with Communicator set to load "Last page visited" when opening new client windows. It appears that Communicator 4.51 checks this setting each time a new client window is opened, whereas IE5 checks this setting only once, when launched. There also appears to be no way to change this behaviour. Possible risk (which I have not noticed in previous versions of IE, although it may be present there as well) is that a less-observant or more naive user might assume the outdated information is actually up-to-date and correct. Lorne Beaton <lbeaton@mnsi.net>
I am currently trying to download something from Microsoft--for the eleventh and twelfth time in the past five days. The problem, of course, is probably the recent announcement of IE5. Everybody and his or her dog is trying to download the latest and buggiest browser. (Bob Frankston's problem with his bank is only one of many: Visual Studio 6 and Eudora Pro both have problems with it, and then there is the AutoComplete function ...) However, I am inescapably reminded of the old problem with Ethernet, and Carrier Sense Multiple Access with Collision Detect. As traffic rises collisions grow more common. Therefore, there are more retries on the net, and therefore traffic rises and ... (Anyone who has to commute over a busy bridge knows why network traffic analysis is called "traffic" analysis.) Same thing is probably happening here. More people are trying to download the files from Microsoft. Therefore, more downloads fail, therefore more people try again, therefore ... Yes, I'm contributing to the problem: I'm running two separate downloads in the hopes that one will finally succeed. Probably a lot of net-savvy people are doing the same thing, or better (worse?) Completely beside the point, the program I am trying to download is the new version of MediaPlayer. On Friday it was a 4.8 meg file. Today the same file is 3.4 meg. One of the never-to-be-known mysteries of the net, I guess ... rslade@vcn.bc.ca rslade@sprint.ca robertslade@usa.net p1@canada.com
> Once again we are reminded of the incredible variety of risks of e-mail. Here's a really strange one: Ever heard of PostPet? It's a Japanese computer game that's also an e-mail client. Besides limited capability to deal with normal mail, you can send your "pet" with the message to another PostPet user. Your pet gets sent as an attachment and returned immediately upon delivery with updated status (depending on how your friend treats your pet etc); there is a timeout. (It gets returned in a "Secret Diary" message supposedly written by the pet; the language of this diary depends on that of the destination client.) Pet mail also causes the addition of the sender to the recipient's list of friends. Risks: 1. If too many people use this thing, we may get spamming incidents in which the spammer adds a PostPet attachment to the spam, thus ensuring a personalised delivery, a guaranteed response from valid addresses and an addition to people's personal contact lists. 2. The file format of the attachment can be reverse-engineered, and a response generated artificially, for any social purpose whatsoever. In fact, once someone has sent you their pet, you can keep its ID for use later - all you have to do at any time is send a message with a custom status and arrange for it to arrive while the pet is "out". 3. There is no way of viewing full headers, and hence if someone is abused etc they can't report it. (Many other things can't be done, too.) 4. Games aren't really meant to live in the application world. If they ported it to Unix, it could consume vast amounts of CPU on a shared system and equally vast amounts of network bandwidth updating the display. 5. The buttons for "send pet" and "send normal e-mail" are far too close. 6. This is no way to introduce e-mail to people new to computers, and yet it is (apparently) being used for that in Japan. This could lead to people not learning things properly. The PostPet documentation is full of metaphors that don't really tell you what's going on. 7. It generally increases the amount of pointless e-mail and wasted time. -- Silas S Brown, St John's College Cambridge UK http://epona.ucam.org/~ssb22/
On 21 Mar 1999, 180,000 families in New Jersey receiving food-stamps took advantage of an error by which their April credits were enabled 10 days early. In the 15 hours until the problem was discovered and fixed, the word spread rapidly and shoppers went on a feeding frenzy. Many stores ran out of staples (food, not metallic). A state employee was preparing for the 1 Apr 1999 crediting of food-stamp accounts; discovering that performance was dragging seriously, he off-loaded the processing onto the backup mainframe, and then moved the resulting files back to the main system. Initial blame was placed on a recent Y2K upgrade, but later reports observed that he had input "199" instead of "1999" in making the cutover, and the program coerced a zero on the end to make the year "1990". So, perhaps the problem was indirectly Y2K-related after all. [Source: *The New York Times* 22 Mar 1999, p. B1; *Newark Star Ledger* 22 Mar 1999, p. 13, with revisions to absolve Y2K two days later, *NYT* 24 Mar, B5. PGN-ed, starkly]
Under the headline "Vom Retter erschlagen" (`Slain by the Savior') the German weekly "Der Spiegel" (http://www.spiegel.de) reports on page 226 in its issue 12/1999 on the analysis of an accident in which a baby sitting in a rear facing car seat mounted to the front seat in a Volkswagen Golf was killed by the impact of the deploying air bag in an oncoming traffic collision. The car owners and parents of the killed baby had previously had the air bag disabled in a certified garage. The wreck of the car is currently sealed by the public prosecutor's office and inaccessible to Volkswagen and the manufacturer of the air bag electronics, Siemens. Volkswagen maintains that the deployment of the air bag may either have been caused by a voltage surge in the car's electronic system resulting from the impact on the battery, or by electrostatic discharges. Experts from the Technical University of Munich, working for the public prosecutor's office, consider these explanations implausible and target a systems engineering fault as a more likely causal factor. Deactivation of the airbag in a Golf is a software-controlled function, as opposed to other manufacturers who physically disconnect the air bag from the board electronics for deactivation. As physical circumstances in a car (temperature variations, moisture, vibrations) form a fairly hostile environment for the air bag control hardware, the software system running inside the control performs ongoing self checks using checksum algorithms. If an error has been detected, the current software settings, including the data responsible for the deactivation, will be replaced by backup software read out of a read-only memory. The backup software, however, only knows a simple set of rules, namely that all air bags in the car will be deployed upon impact. Evidently, the backup software is unware of a previous software-controlled deactivation. Stefan Leue
SPAM-L this week contained a description of interesting method being
used to obtain credit-card numbers.
1. Grab e-mail addresses of AOL users in chat rooms.
2. Mail them a forged message from AOL asking them to click on a hyperlink
to verify their billing details. "Click here" takes them to a
forged AOL page on a free web service asking for exact credit card
details, passwords, etc.
3. If they fill out the form, it is POSTed to an innocent cgi script on
another site which accepts a hidden argument specifying an e-mail address
where the credit card information will be mailed to.
4. Finally the cgi script redirects the user to a third throw-away site
("Thank you for changing your account details").
5. The perpetrator can now pick up a list of credit card numbers from
the free e-mail account from anywhere in the world.
The basic risk here is an old one: clicking on a hyperlink may not always
take you where you think. In addition the use of free anonymous e-mail
accounts and web pages makes it far easier for the criminal to avoid a
simple paper trail.
-- Mike --
One thing only a fraction of the popular press coverage has touched upon is that: while spreading itself around the world, Melissa also appears to send the document the victim is dealing with at the time as well. THAT may have consequences that last far past the Denial of Service logjam. If the file in Word was confidential and Melissa leaks [..you name it..] out.... This might draw some attention to other Word problems; such as its propensity to send along both deleted text as well as that from other document windows. It does not show when rendered by Word, but it's still there.... (A friend at a Fortune 500 communications company recently was sent a doc whose distribution was limited to 5 or 6 people. He used the Unix tool 'catdoc' to read it on his workstation & discovered most of an innocuous 2nd doc also in the file. "Suppose it had been the other way around?" he remarked.) Such covert channels have always been a concern some people paid serious attention to [witness IntelLink's physically separate networks for U, S, and TS/SCI; and the recent release of AES material via printer-->scanner-->PDF route]; I hope more people will now do likewise...
As it turns out, the GUID is *not* a reliable identifier of the author for the Melissa virus: http://www.zdnet.com/zdnn/stories/news/0,4586,2234018,00.html Synopsis: If a Word document is passed to another person, modified, and saved, the original GUID is preserved even though none of the actual content may still be extant. In this case, the GUID in question has been discovered in works from other authors. The person currently under the most suspicion (known as VicodinES) says that the virus code in his document that has the same GUID as Melissa (a macro virus named PSD2000.DOC) is actually based on earlier virus code from another author (known as ALT-F11); indeed, the GUID on that earlier work *also* matches Melissa. So does the GUID on other work by ALT-F11, while work that VicodinES claims is original with him does *not* have the Melissa GUID. *Anyone* could have written Melissa and made VicodinES, or any other Word user they want, appear to be the culprit. Here we see the inherent RISK of relying on a non-unique identifier; in this case, the fact that the ID is inherited poses additional risks of misidentification. — Joe Joe Thompson http://kensey.home.mindspring.com/ fbi.gov@orion-com.com [Even if they are unique, such IDs may be easily forged. Once again, the use of digital evidence is tricky. PGN]
--- Forwarded mail from a colleague at Disney ---
FINALLY! A Programmers Drinking Song! Woo! Hoo!
PROGRAMMERS DRINKING SONG:
99 little bugs in the code,
99 bugs in the code,
fix one bug, compile it again,
101 little bugs in the code.
101 little bugs in the code.....
(Repeat until BUGS = 0)
[I think it's appropriate, given the rash of "buggy" animations these days.
Rebecca.] [It's nice that Y2K is also brewing lyrics. PGN]
This is cute: > "We may not get everything right, > but at least we knew the century was going to end." > — Apple Computer, HAL 9000 ad for Macintosh Y2K compliance
> [...] We don't want people going and buying > generators when they should be out buying jeans." There's another *hidden* problem. In Australia, the most common brand of zippers (zip-fasteners) used on manufactured clothing is YKK. I have no idea what sort of compliancy tests to run on my zippers, and, wishing to take *no* risks of the "system" being down at the wrong time, will be wearing either buttons or elastic on 31 December 1999. Gillian Richards, Computer Systems Officer <gillian.richards@tafensw.edu.au> Wenworth Falls TAFE Campus, NSW Australia
Part of the problem is that the definition of e-mail is a bit fuzzy. If you define it to mean any mail-like electronic message, then you can trace it back to 1851, when the New York and Mississippi Valley Printing Telegraph Company (predecessor of Western Union) began sending telegrams. The AUTODIN messaging system may belong in that family tree. If you mean mail-like messages between computer users, then CTSS certainly had a mail command that may be a candidate for first. If Corby [Corbato] searches his attic, he might be able to find a date earlier than the circa January 1965 PSN you identified. A survey of the other time-sharing systems of the time would probably turn up some other mail programs. But that didn't go between machines. If e-mail means that two computers have to be involved, then Kleinrock may well have sent the first piece of e-mail that crossed the net. I don't recall that we ever had mail moving between the two CTSS machines (MAC and Computation Center) at MIT. Jerry
AUTODIN probably counts as one of the "first" e-mail systems. As I remember, there was a BBN project called "Mercury" that was also working on electronic mail. Noel Morris and I knew that both of these existed when we wrote CTSS MAIL, but were not sure whether Mercury was ever deployed. PSN 40 _proposed_ a MAIL command. As I remember, Noel and I, junior energetic programmers, offered to do it while others were busy with Multics design, and were given permission. When I visited Roger Roach about 8 years ago, he still had the CTSS source, and I looked at the source of MAIL, and it was my code. It had Dick Mills's, Bill Bierstadt's, and my programmer numbers baked into the code. We, and M1416 * could send messages to all users. (See my story, quoted in _Wired_, about the first spam, sent by Peter Bos. Remember that? He abused his system programmer privilege to send a message beginning THERE IS NO WAY TO PEACE. PEACE IS THE WAY. When I remonstrated, he said, "But this is *important.* Wired got my name wrong. Peter Bos and Noel are both gone.) >... If e-mail means that two computers have to be involved, ... That definition would of course depend on the meaning of "computer." Would Tandem's multi-node, multi-CPU, single-system-image MAIL qualify? In some senses that system was a 645 with very long buses. Was it one computer or many? Was the 645?
Here is another try at imposing categories and milestones on what looks more and more like continuous evolution: 1. First mail-like communication by electronic means (telegrams): 1851, Mississippi Valley Printing Telegraph Company. 2. First interposition of computers in handling mail-like communication: perhaps 1957, TELEX, and probably also some predecessors of AUTODIN. 3. First mail-like communication within a system used for general-purpose computing: early 1960's, Van Vleck & Morris on CTSS or perhaps BBN Project Mercury. 4. First mail-like communication between two computers operated by different administrative entities: late 1960's, perhaps Kleinrock's anecdote, but it needs some more research. Lenny Kleinrock can probably claim without fear of contradiction that he sent the first e-mail over the ARPANET, because he was standing at one end of the first ARPANET link that was installed. The fact that Kleinrock's anecdote is dated at practically the instant of that installation is pretty compelling evidence that e-mail was already well-known and operating within individual time-sharing systems. Jerry
My son has dyslexia. To help him deal with life, he has some voice-recognition software on his PC. In the early stages of training he found that odd noises, such as laughter, were interpreted by the computer and, at best, produced long strings of random words. Having a normal teenager's sense of humour he found these funny, laughed some more and so on. When his giggles subsided he had to utter the command "delete last four pages". I now recognise the signs of mirth in his e-mails. Even funnier is getting the computer to read back the laughter passages.
> ... It's not enough to have a backup system in place...you need to make > sure it will work when needed. ... and that if it's there you're able to or allowed to connect to it. A colleague maintains a number of Internet Web servers as a commercial venture. Friday he found out that the building that houses these servers was going to be disconnected from the power mains for 8 hours starting at midnight Saturday in order to conduct an annual power audit. The company he was renting space from didn't have enough capacity in their battery backup systems to run his equipment, but would have the system upgraded "next month." The room is sealed, so putting in a small internal-combustion driven generator was out. There is a diesel-powered grid in place, but it only generates 48V DC used by a number of telco switches in the room. And trying to find a sufficiently sized 48VDC to 110VAC inverter for rent was an exercise in futility. A number of vendors were more than willing to sell him one of these ~$4K devices however. The risk here is that even if backup power's available, you may not be able or allowed to use it. Tim Kuehn
The new term "kibibyte" will more accurately describe the number of bytes in a kilobyte — rather than being 1,000, as could be inferred by the prefix "kilo," a kilobyte actually has 1,024 (2 to the 10th power) bytes. Has the 8-bit usage of the term "byte" been internationally standardized? Or is "kibibyte" still ambiguous (for Multics and PDP-10 hackers at least)? "Kibioctets" anyone? Sounds like a cat food. David Henkel-Wallace, Zembu Labs
The Software Engineering Symposium '99 Theme: Improving the State of Software Engineering: Principles, Practices, and Projections August 30--September 2, 1999 David L. Lawrence Convention Center Pittsburgh, Pennsylvania Early Bird Registration: July 28, 1999 For the most up-to-date information, bookmark our Web site at http://www.sei.cmu.edu/products/events/symp/ or contact Symposium '99 Conference Coordinator Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone: 412 / 268-3007 FAX: 412 / 268-5556 E-mail: symposium@sei.cmu.edu
Please report problems with the web pages to the maintainer