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…
On 23 Apr 1997 at 11:14a.m. EDT, Internet service providers lost contact with nearly all of the U.S. Internet backbone operators. As a result, much of the Internet was disconnected, some parts for 20 minutes, some for up to 3 hours. The problem was attributed to MAI Network Services in McLean, Virginia (www.mai.net), which provided Sprint and other backbone providers with incorrect routing tables, the result of which was that MAI was flooded with traffic. In addition, the InterNIC directory incorrectly listed FL Internet Exchange as the owner of the routing tables. A "technical bug" was also blamed for causing one of MAI's Bay Networks routers not to detect the erroneous data. Furthermore, the routing tables Sprint received were designated as optimal, which gave them higher credibility than otherwise. Something like 50,000 routing addresses all pointed to MAI [Missing in Action on the Internet?]. [Source: Inter@ctive Week Online, 25 Apr 1997, article by Randy Barrett, Steven Vonder Haar, and Randy Whitestone.] Once again we are suffering from inadvertigo, illustrating how the effects of a seemingly small inadvertence and other collateral factors can cause widely propagating problems.
California has already spent $300 million on its Statewide Automated Child Support System (SACSS). The projected costs have escalated from the 1991 estimate of $99M. The Assembly Information Technology Committee, chaired by Elaine Alquist (D-SantaClara) has just issued a report suggesting that the system may have to be scrapped: ``Due to significant problems in the SACSS application, many of which could go undetected until the project is fully implemented, it is unclear whether the project will ever fulfill the mandate of the federal government or the child support enforcement needs of California's 58 counties.'' [Source: *San Francisco Chronicle*, 2 May 1997, A22] Some of you may recall Simson Garfinkel's report in RISKS-17.30 (28 August 1995) on the legislation that prompted the development of SACSS. The federal government is paying 90% of the development costs. If that funding were cut off, would they be accused of being a Deadbeat? On the other hand, the rate of failures reported in RISKS on such system developments is extraordinarily high, so we should not be at all surprised if the system is never deployed. Can you hear Grateful DeadBeat Dads singing?
A computer hard-drive was stolen containing personal records for about 20,000 current Levi Strauss employees and 20,000 more former employees. Information included names, addresses, dates of birth, and Social Security Numbers. Bank-account numbers for direct-depositing retirees were also present. It is not clear whether this was a theft for the equipment or an explicit precursor to planned identity theft and credit fraud. Is there a risk? L-S spokesman Gavin Power said, ``The information is written in a complicated computer language that would be very difficult to crack.'' [RISKS readers may chuckle quietly to themselves. Nonreaders might not understand anyway.] Of course, he added the usual peremptory remark, ``We are taking steps to make sure this kind of security breach will not happen again.'' [I suppose they are going to use ``unbreakable'' crypto with the keys stored on the new hard-drive!??] [Source: *San Francisco Chronicle*, 29 Apr 1997, A1, and 30 Apr 1997, B1.] Please pardon my cynicism. I guess in a virtual genetic sense, Levi Strauss *blew genes* all over the place.
Observing the foregoing Levi Strauss case, I note that RISKS has frequently
illustrated computer-related risks involving credit fraud and identity
theft. As a reminder to casual readers, we have recently reported on other
thefts of personal data — the Visa computer containing information on over
300,000 credit-card accounts (RISKS-18.62), and CalTrain's database of
ticket-by-mail commuters (RISKS-19.02). We also had items on risks involved
in the use of Social Security Numbers and PEBES (Simson Garfinkel,
RISKS-19.05) and identity theft (PGN, RISKS-19.05).
To put this all in perspective, I have submitted written testimony to the
U.S. House Ways and Means Committee subcommittee overseeing the Social
Security Administration and its PEBES system, for a hearing on 6 May. You
can find the statement on my Website:
``The Social Security Internet Website: Technology and Privacy Implications''
<http://www.csl.sri.com/neumann/ssa.html>.
You might also check out Chris Hibbert's FAQ, ``What to do when they ask for
your Social Security Number,'' originally reproduced in full in RISKS-14.16
and 17, and updated periodically on various Websites:
http://cpsr.org/cpsr/privacy/ssn/ssn.faq.html
ftp://cpsr.org/ftp/cpsr/privacy/ssn
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/answers/privacy/ssn-faq
or by e-mail to mail-server@rtfm.mit.edu with the sole content line
send usenet-by-hierarchy/news/answers/privacy/ssn-faq
RISKS readers will want to check out James Sander's *The Downing of TWA Flight 800* (Zebra Current Events, $6.99 in paperback, 10% off at www.amazon.com). The book is one of the first serious accounts of the crash, albeit one written by someone convinced that the U.S. Navy was directly responsible for the accident. The strongest part of the narrative is the detailed discussion of the tests the Navy was apparently conducting off of Long Island that evening. The weakest parts may be the analysis of the debris found on the ocean floor and the jump to the conclusion that any missile may have come from the US Navy. The details of the Navy's tests of the Cooperative Engagement Capability (CEC) may be of most interest to RISKS readers. This system is apparently part of the technology used to link several warships together and coordinate their knowledge of all of the targets in the theatre. One of its jobs is to keep track of all of the civilian flights operating and this may be why it was tested so close to civilization. While I know nothing about the Navy's development and can't comment on the accuracy of the description in the book, I can easily imagine that the Navy would be actively interested in developing this capability especially after the Vincennes incident in the Gulf [e.g., see many issues from RISKS-7.16 to 67, and Matt Jaffe in 8.74]. The book goes on to suggest that the Navy was testing the system with a drone equipped with jamming electronics. Its job was supposedly to try and neutralize the system's radar and escape detection. The warship, on the other hand, was trying to shoot down the drone, and it fired a missile to do so. The book says that as the missile was expecting to receive final targeting information from the warship in midflight, but that the jamming prevented this from happening. The missile thus went looking for the target on its own and locked on TWA 800 instead. Again, I know nothing about what the Navy does, but such tests seem quite prudent to me especially after the damage that Exocet missiles did in the Gulf and in the Falklands. In fact, I would insist on such real-world tests to ensure that the system was truly combat ready. The book suggests that there was no real warhead on the missile, which sounds prudent. It also photographically reproduces the Navy's warning to the FAA about the military activity in the region, so perhaps the TWA 800 pilot should have known better. The book goes into greater detail about the pattern of debris on the ocean floor and offers strong theories about what this says about the calamity. While I have no reason to disbelieve anything that is said, I think a disintegrating plane would be very random. But my mind may be prejudiced by the fact that there are no exact solutions for n-body differential equations. The book also discusses the red residue left on seats in rows 17,18 and 19 and concludes that they are a trail left by the missile as it passed through the plane. The author was able to obtain samples of the seat fabric from sources inside the investigation and had them analyzed. He says that they're consistent with a missile. Others say it's just melted adhesive. I'll leave that for the chemists to argue about. The greatest challenge to RISKS readers may be analyzing the evidence themselves. The author gave the seat-cover sample to CBS News, who apparently returned it to the FBI. The FBI also served the author with a subpoena for the radar tape and other data related to their criminal investigation. They even subpoenaed the publisher, who was forced to turn over copies of the book contract and check stubs. These are all now kept secret by the FBI's criminal investigation. This book may be all we have to discuss for some time.
An item from Reuters (1 May 1007) entitled "Drugs Dispensed by Modem" tells about a "telepharmacy system" which consists of "combining computer, modem, and drug-dispensing unit" (yes... you can see it coming, can't you) so patients can have pharmacists in the big city phone them prescriptions - not the paper but the drug itself. The article does say that these machines would presumably be in physician's offices, so I suppose the chance of serious abuse would have at least a filter. The system's safety mechanism consists of a bar-code that will "ensure that the correct drug has been dispensed". The president of the company (called ADDS, Inc.), Brian Hart, said "Basically, it's a fail-safe mechanism. By using the bar coding, we can be absolutely sure the right item is handed out." Did he say "fail-safe"? Did he say "absolutely sure"? Ouch. He does comment that you wouldn't put one in a bus station, but isn't having them at all a step in that direction? Apparently, Mr. Hart's father was killed by a goofed prescription. At least in the states, doctors' handwriting on prescriptions is notoriously poor and I'm sure has led to the mis-prescription of who knows how much medicine, no doubt occasionally resulting in death. But I can't help but wonder what precautions will be taken against hacking this little gem. 1-900-MORPHINE, anybody? $2.99 for the first minute and after that you won't care any more.
In Australia, there's been quite a fuss over claims that cellular phones
cause all manner of disease. Motorola responds:
Phone giant may take legal action over health claims
Australian Associated Press 29 Apr 1997
SYDNEY, April 29 AAP - In the wake of growing fears over mobile
phone safety, industry giant Motorola has hinted it may take legal
action over claims linking its products to brain cell damage,
cancer, Alzheimer's and Parkinson's diseases.
The company's managing director Ron Nissan said today he had
written to fledgling protection device manufacturer Microshield,
seeking that it retract the claims made in its sales brochures.
Key points made in the article:
* Microshield announced its protective cell-phone shield in the third week
of April.
* "The device consists of a woven polyester and nickel casing, a
PVC phone screen ingrained with ultra fine protective mesh and an
adjustable polyester-coated aerial guard."
* Device is described as blocking 90% of harmful emissions from the phones.
* Advertising pamphlet claims that cell phones have been shown to cause
"permanent brain cell damage, cancer cell growth
acceleration and possible promotion of asthma conditions following
exposure to microwave radiation at cellular phone frequencies".
* Also claims that cell phones may cause Alzheimer's and Parkinson's diseases.
* Executive Director of the Australian Mobile Telecommunications
Association (AMTA), Peter Russell, has written to the
Australian Competition and Consumer Commission (ACCC) to demand
removal of this brochure.
* ACCC will test Microshield claims using independent investigators.
* Australian researchers announced yesterday that lab mice show higher
incidence of lymphoma after exposure to cell phone radiation.
M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA) http://www.ncsa.com
Wilson Chan Chi-kong, 29, the former employee of Reuters financial information agency who had sabotaged the dealing-room systems, was apparently motivated by revenge after a dispute with his superior. The damage control took more than 1,700 man-hours, and the estimated cost was HK$1.3 million. He has been jailed. [Source: Reuters Computer Engineer Jailed For Destroying Files, South China Morning Post via Newsbytes News Network, 1 May 1997]
> Mr. Blair, who will become the youngest prime minister since 1812, has > said in recent interviews that he will be "a radical prime minister." > While he hasn't eLabourated, there are indications that he may seek to > address welfare reform, much as President Clinton and the U.S. Congress > are trying to do. [*Wall Street Journal*, 2 May 1997] The *paper* edition used "Labor" throughout; in going to the *electronic* edition, the editor — aware of inappropriate americanisation — apparently ran search-and-replace "Labour" for "labor", which of course the software duly accomplished, with a somewhat Freudian result. The usual risks. [I'll have to add that one to my 1 April 1996 list of e-items for the next chapter in The Hyphenater's Handbook (see RISKS-17.95 for the chapter excerpt ``e is for electronic''). PGN]
I've just noticed on my Solaris machine a file called /var/adm/spellhist. It is a log of all spelling errors found by the Unix spell program. The user, tty, and date are included in the report. The point of the log seems to be that the local organization's "dialect" could be integrated into the system dictionary to make the spell program more accurate, over time. As far as I can tell, the spellhist file is present by default and globally read/write-able under Solaris(es) 2.3 and 2.4. The spell program reports as misspellings any word it doesn't recognize: this includes things like many last names and project code-words. Depending on the skills of the author, there can be enough genuine misspellings in many documents that one can get some idea about the spell-checked document. Also, each spell "session" is logged separately so an interested party could follow the development of the document over time. For example, the spell program distilled this message into: > mikey pts/1 Apr 28 09:34 > Solaris > adm > es > spellhist > trojan > tty > var > writeable The primary RISK is that data meant to be secret could be compromised. The secondary RISK is that any Unix filter program could be modified to behave as a quiet trojan horse in this manner. A quick fix (for Solaris at least) is to set the H_SPELL environment variable to /dev/null in whatever startup file is appropriate for your shell.
In RISKS-19.07, Danny House correctly states the importance of good naming conventions for software identifiers, and the risks of poor identifier names in legacy software. He rightly identifies global name spaces as the cause. They force the invention of contrived naming conventions to avoid name clashes. However, there have been some attempts to help with this problem. For example, three features of C++ reduce name space clutter. The first, shared by all object oriented languages is the class. A class has its own name space, so the same name can be used for member functions in different classes. If this is done carefully then ad hock polymorphism results, where the same operation can be applied to different objects. C++ extends its global and class name space with function overloading. This allows functions of the same name to be distinguished by their parameter lists. So the same function name can be applied to objects of different types without ambiguity. Finally, the latest versions of C++, implementing the draft ANSI standard, also have namespaces. These provide a way of preventing name clashes in larger programs composed of several components. Adrian P Robson
Marc Salverson's note about the interpretation of "zzzz" provided by MS Word's spelling checker reminded me of the behavior of the thesaurus in Lotus Ami Pro 3.0. If you enter the word "secrets" in a document and invoke the thesaurus on that word, the first choice presented in the list of alternatives is "genitalia." [Lotus est Mon Ami?]
The trouble with our legislators isn't so much that they change the rules, but that the changes they make are often subtle enough to go unnoticed until several years afterwards. Some years ago the rule for the end of DST in the UK was changed from "the Sunday after the fourth Saturday in October" to "the fourth Sunday in October". This makes a difference only in years when the first of October is a Sunday, and since this wasn't going to happen until several years after the rule change, no-one bothered to reconfigure their computers. In 1995 many computers changed their clocks a week late. (The risk here is that an inexperienced and harassed Unix system administrator would be tempted to fix the problem on Monday morning by adjusting the system clock - which could have disastrous consequences.) Last year the rule changed from "the fourth Sunday in October" to "the last Sunday in October". Once again, the change has no immediate effect. UK computer users using TZ to program their DST clock changes should change the setting to TZ=GMT0BST,M3.5.0/1,M10.5.0/2 if they don't want to be caught out in 1999.
I have an even stranger story about a double DST adjustment. On my computer, I also run multiple OS's. Last year, I feared what was described above was going to happen, so what I did was wait until the day after the time change and boot each OS in succession. I figured I'd let each one of them set the clock, then I'd set it to the correct time afterwards, and there'd be no surprises waiting later on. Turns out that only Windows 95 adjusted the clock, the others (Linux, OS/2 Warp) didn't. Apparently Linux is smart enough to not adjust the clock unless the changeover happens *while it's running*, the way it should happen. So this year, I had 95 running the day before the changeover. What my plan was to set all the clocks ahead except the computer, and it'd just take care of itself. I also have since installed the After Dark screensaver, and have it set up to display a large digital clock when the PC is not active. Imagine my surprise when I come out at 4am (daylight time) and the computer screen shows it's 2am. The computer had set itself back, not forwards, apparently. Then I go over, press a key to deactivate the screen saver, and Win95 had popped up an window saying it had set the clock ahead and asked me to confirm it. The clock in the corner of the screen read the correct time, 4am. And the next time After Dark came up it, too had the right time. What happened here? Was After Dark trying to be a little too smart and set the clock itself? And got confused? Or is this just another weird bug?
Please report problems with the web pages to the maintainer