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…
Distancing the Commerce Department from the position held by the Federal Bureau of Investigation, Commerce Secretary William M. Daley says that the Clinton Administration's controls on encryption technology are hurting America's ability to compete with other countries. "There are solutions out there. Solutions that would meet some of law enforcement's needs without compromising the concerns of the privacy and business communities. But I fear our search has thus far been more symbolic than sincere... The cost of our failure will be high. The ultimate result will be foreign dominance of the market. This means a loss of jobs here, and products that do not meet either our law enforcement or national security needs." (*The New York Times*, 16 Apr 1998; Edupage, 16 April 1998)
[If, as is widely predicted in Y2K circles, the IRS's computers go south, maybe we'll have that national sales tax after all. --Declan] http://cgi.pathfinder.com/netly/opinion/0,1042,1909,00.html The Netly News, April 16, 1998 How is it that millennial fever is focused so far on 30-year-old lines of COBOL code, as opposed to, say, the second coming of a messiah? Yesterday the head of the IRS used his agency's biggest day of the year to proclaim Year 2000 the "most unfortunate but most essential problem" — and one that will cost $1 billion to fix. This is up from $850 million two weeks ago, and $250 million six months ago. "We simply, absolutely must devote all of our resources to fixing the year 2000 problem," Charles Rossotti said at a National Press Club luncheon. If the problem is not solved, he said, the result will be "very dire indeed." Only 625 days to go. [To subscribe: send a message to majordomo@vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ ]
[Time for the government to step in and start licensing programmers! Just kidding, folks — but I know industry lobbyists here who are getting worried. --Declan] >Date: Wed, 15 Apr 1998 15:40:30 -0700 (PDT) >From: Chris Stamper <stamper@stamper.com> >To: declan@well.com By Chris Stamper ABCNEWS.com April 15 - Some Microsoft products used on thousands of computers will have problems after Dec. 31, 1999, and Bill Gates turned the light on the Year 2000 bugs in his software today. Microsoft's new Year 2000 Resource Center is now alive on the Web. There's a picture of Gates on the home page, reassuring millions of customers that "we are committed to providing the information you need." Microsoft Reveals Y2K Problems On New Web Site: http://www.abcnews.com/sections/tech/DailyNews/y2k980415.html [Declan's POLITECH mailing also included an article by Mary Jo Foley <http://www.zdnet.com/sr/breaking/980413/980415a.html> pointing out that MS reports that only 21 of MS's top 60 software products are Y2K compliant, primarily because of MS Internet Explorer 3.X and 4.X. Windows 95, Windows for Workgroups 3.11, NT Server 4.0, NT Workstation 4.0, various versions of Office 95, Visual Basic 5.0 and Visual Studio Enterprise 5.0 and also reported as noncompliant. PGN]
>Date: Wed, 15 Apr 1998 20:18:52 -0400 >From: Josh Rivel <jrivel@dti.net> >To: geeks@umich.edu >Subject: GeeK: interesting implications of Y2K non-compliance I'm on a mailing list related to Eagle Talons/Mitsubishi Eclipses/Galant VR4's anyway, it seems the code in the ECU's for the 1st generation of those cars (1990-1994) has an interesting problem with Y2K compliance. The following excerpt was written by Todd Day <today@dsm.org> who is the list moderator, and ECU (Engine Control Unit, aka car computer) wizard. [All you guys with 1989-1994 DSMs might want to take another car to the parties on Y2K eve... or arrange for a tow truck. 1995-98 ECUs seem to be Y2K compliant, as far as I can tell (an OBDII requirement). If you don't want to be seen at the party without your DSM, for $100, I can fix your ECU so the overflow problem won't happen until 2089. I've set my ECU to the bewitching hour, and the results aren't pretty. The overflow causes a mask bit to be set which prevents the spark plug in cylinder 3 from firing, but doesn't stop the fuel flow. The fuel flow in that cylinder actually doubles due to a side-effect of the spark bug. This creates some pretty spectacular backfires, I must say... One hell of a way to welcome in the new century. Oh yeah - this bug happens at December 31st, 1999 at midnight (or January 1st, 2000, depending on how you look at it) in the CENTRAL time zone. That's because the cars were all built in Illinois. So for you East Coasters, it will occur at 1am, and West Coasters will experience it at 10pm. -talon mgr] Josh Rivel Senior Network Engineer Digital Telemedia, Inc. http://home.dti.net/jrivel
Gas station owners forbid use of mobile phones, claiming EM waves are disrupting their data networks PRAGUE, CZECH REPUBLIC (NBISN, 04Apr1998) — Mobile phones, which used to be an extravagance for the elite, are now cursed by many of the thousands that have adopted them since networks and phones based on the digital mobile standard GSM became available over one year ago. Users have been warned that use of the phones while driving can be dangerous, use in banks is forbidden due to use by robbers to target cash-heavy bank clients, use in hospitals is forbidden because of interference with equipment, use on airplanes is forbidden (and usually useless even if it wasn't), they just plain don't work in the underground, use on ground-bound public transportation is frowned upon by other passengers (or grinned upon by snoops) and now use at many gas stations is forbidden. Gas station chain owners, such as Benzina, are posting signs with a big X over the picture of a mobile phone and claiming that they have a legal right to forbid the use of these devices as the rascals interfere with data transfer over payment card networks such as CCS, Mlada Fronta DNES, a leading Czech newspaper, reported on 04Mar1998. But CCS claims that mobile telephones can in no way affect the operation of the CCS system and that not a single case as such has been reported, MF DNES quoted Hana Sevcikova, business manager at CCS, as saying. A Benzina spokesman, Pavel Schinkmann, however, says that the cases are fresh and thus maybe not everyone has heard about them yet... and that the phones are indeed forbidden at all of its over 400 stations throughout the Czech Republic. Benzina, who holds an ISO certificate, links all its stations via a network, apparently with some wireless connections. MF DNES quoted one Benzina spokesman as saying that "electromagnetic waves can disrupt computers and sometimes can cause an explosion." But MF DNES did cite at least one concrete case: A spokeswoman for the Benzina station in Prostejov, Bozena Hochwaldova, said the mobile telephoning brought down the whole CCS system not long ago. Some Shell stations have also forbidden the use of mobile phones for the first time just days ago but some operators such as OMV say they will tolerate their usage. Tamoil, recently exposed as having Libyan capital behind it by the English language Prague Business Journal, http://www.ceebiz.com, will probably not be one of those to forbid mobile phone usage since they are already starting to lose enough business as is. Maybe the list of where you can actually use mobile telephones should be published — it will soon certainly be much shorter than the list of places where you can't. - Steven Slatem, IntelliTech Media, Inc., http://www.intellitech-media.cz, editorial@intellitech-media.cz
>From <http://www.tribnet.com/news/top/a1/0416a15.htm> "Glitches in a new 911 computer system are slowing critical communications between local emergency dispatchers and officers. "The sporadic problems have become severe enough to jeopardize officer safety and must be fixed immediately, police say." [...] The article goes on to describe how the "windows based" solution by Unisys was one full year behind schedule, was pulled out of service for 18 months of software repair, and is still unusable under heavy load. The contract (US$ 1.4M) seems relatively small to be plagued by such problems. Yet, it is another reminder that poor project execution, no matter with whom the blame lies, can be hazardous to life and safety. Jonathan Clemens, CCP Intel Corp.
Since 1989, some 120 Million (estimated) Deutschmarks (US$ 70 million) have
been wasted trying to design and install a new computer system ("Comvor")
for the police in Hamburg, Germany. The system, designed to ease the load of
paperwork on the police, never worked.
So far nothing new, the reports have going on for month, if not years. Red
tape wasting our money, one thinks. What strikes me are three conclusions of
the whole affair that appeared in Hamburger Abendblatt (April 16th, p. 13)
today:
- 356 jobs have been cut (some of them because they "won't be necessary
after the system starts working", some of them to save money for buying the
computers in the first place), and there are no plans re-employ
people. Instead, police officers do the paperwork that the computer system
was supposed to do, and money has to be found to buy new computers. The old
system (the one "Comvor" was built to replace) sucks in 340.000 Deutschmarks
a month for maintenance. (Lean government is more expensive, in some ways.)
- The consultant firm contracted for designing a new computer system blames
part of the mis (or non-)achievements of Comvor on the fact that police
people were in charge of the development team. "Software design was not one
of their core competences", reads the quote from Uwe Kirchhoff, the boss of
the consultant firm. (And I thought it were the software people who make
computer systems that don't work in the real world.)
- Interior minister Hartmuth Wrocklage blames the misachievements on the
fact that "the complexities (of the whole venture) had been underestimated".
(This one ranks first in the top-ten of "Why our software doesn't work", I
guess).
To me, it looks a bit like a case of "Hey, how can we save money and at the
same time stick to the weird and inefficient way we do our job? By putting
the whole thing into a computer?" Contracting a software firm in a situation
where you should buy advice from a management consultant.
Big risk: "The Computer will solve our problems".
Martin Virtel, DIE ZEIT im Internet (http://www.zeit.de) +49 (0)40-3280-562
Malaysia is getting a state- of-the-art airport for its capital (Kuala Lumpur), but it has been plagued with delays. Portions of an article is from the Far East Economic Review. --- http://www.feer.com/Restricted/98apr_16/projects.html "With the (Malaysian economic) slowdown, demand will come down and we'll have some excess capacity on opening day," admits Clifford Herbert, who heads Kuala Lumpur International Airport, the government-owned company responsible for the 9-billion-ringgit ($2.4 billion) project. But he rejects notions that the airport is too extravagant. "In terms of cost, we have something very functional," Herbert says, pointing out tha the airport was almost completed before the currency crisis struck. "I don't think we wasted anything." Whether airlines and passengers agree will depend on the airport's teething problems in the months ahead. The opening has already been postponed twice: most recently from April to late June. Some of the biggest anxieties centre on the 700-million-ringgit (US $200 million) Total Airport Management System, a computer network that links 16 sub-systems ranging from flight information to baggage handling. The airport will be the first in the world to link all these functions into one set-up. But pioneers often pay a price. Reports say that when the baggage-handling system was tested for the first time, with 200 bags, not one ended up where it should have. "In theory it sounds great, but there are a lot of intricacies in linking so many computers," says a second foreign airline manager in Kuala Lumpur. ( Shades of Denver airport ! - john) Some airline operators fear Malaysia is stressing pizzazz over efficiency. "Kuala Lumpur strikes me as state-of-the-art. They've tried to put all the best things into the airport," says the first foreign airline executive, whose airline lands in both Kuala Lumpur and Hong Kong. "Hong Kong is trying to make an efficient airport," he says. (Hong Kong's new airport is slated to open in early July.) "What we've heard so far about Kuala Lumpur is that it's more grand than functional." -- My comments - John Lim: I was formerly employed by a company heavily involved in bidding for IT systems for the KL International Airport and I can attest to the dream of the politicians approving the project were more grand than functional. In fact when my former company were bidding for the project, most of the big IT companies in Malaysia felt that the ambitions were too great given the tight schedule. But most of these companies, including my former company still went in to bid anyway. PS: we knew about Denver airport back then in 1994/5. The Risks: For companies: Some projects are felt to be too big and prestigious to walk away from; particularly in a small country like Malaysia. For governments: Be very sure you have the resources to implement your ambitious plans; particularly in a small country like Malaysia. John Lim Natsoft Malaysia http://www.natsoft.com.my/natsoft Tel:(60)3 7061216 Fax:(60)3 7061210
The failure earlier this week of AT&T's national high-speed network didn't affect conventional or cellular telephone service, but did manage to disrupt the portion of the network that carries data for transactions involving credit cards, bank accounts, travel reservations and the like. "This sort of thing is going to happen infrequently, but more and more in the future," says the managing director of the Yankee Group. "And it makes you realize how vital to the lifeblood of the economy these complex computer networks have become." There is no way to gauge how many transactions were forfeited as a result of the blackout, but analysts are saying the losses are likely huge, with thousands of businesses affected. (*The New York Times*, 15 Apr 1998; Edupage, 16 April 1998)
Among the many places that felt an immediate and severe impact from the outage was our Access support group, which handles ISDN and modem dialup issues. ISDN and async are both popular backup solutions for FR links, and lots of people found out in a hurry just how good their backup configs were. It hailed high-priority "network down" calls all afternoon here, both from customers who didn't have backup links in place and were scrambling to set them up, and from customers who had something that they thought would work, but didn't. This illustrates an often-overlooked risk. Backup strategies are no good unless they actually work when needed. To be reasonably assured that they will work when needed, you have to test them. And (here's the kicker) your test has to cover the WHOLE THING. But a *complete* test is (almost inevitably) disruptive, and risky in itself. Therefore, the more important the thing being backed up, the less likely it is to be properly tested. For instance, the only REAL test of a backup circuit for frame relay involves shutting down the production FR circuit and seeing if your backup does the right thing. Less drastic tests (e.g., can we dial the backup number) won't tell you if the whole thing will do what you need — which is not just to get two routers talking, but to get packets to the appropriate destinations. That takes more than just a connection between the two routers, though. (You need to make sure that routing updates happen correctly on both sides, to name just one popular failure point.) Management is often reluctant to allow full-scale backup tests of critical links, but those are the ones you want to be especially sure of. Catch-22. An incompletely tested backup may even be worse than no backup at all, because it encourages unwarranted complacency. Similar problems apply for tape backups, by the way. The best test of your backup is a restore, which usually means system downtime. And if your restore fails, then what? You have a scrozzled system, that's what. Ideally, you'd run your test on a spare system, but not everyone has that luxury. (Then there was the customer whose telco turned off their backup ISDN line "because it wasn't being used...." Sigh.) Brian McMahon <bmcmahon@cisco.com>, Customer Support Engineer, Cisco Systems
I just had an amazing conversation with Hewlett Packard's support services. My HP200 lost it's mind this morning and corrupted the content of it's RAM disk. I was able to reboot the computer and get a copy of the data onto a PCMCIA memory card and put it onto other computers at my site. The next step was to try to recover the content, so naturally, I called HP's support line. They told me that the palmtop computers they were selling only a few months ago used formats for their calendar and quicken databases that they did not know how to read. They claimed that they went directly to their own engineers who had designed the products and that these folks did not know what the data formats were - even for their own proprietary file formats! I guess it's the end of an era when a company with a long reputation for high quality and reliability doesn't even know how their own products work. I guess I'll just have to hack their software to get my data back. [Added later:] So I tried to call Intuit to get technical support for data recovery from corrupt pocket quicken data files, and wouldn't you know... The Intuit Web page refers you to HP for support of the HP-based quicken products, but as we already know, HP doesn't know the format information required for file recovery. So next I tried the number for Intuit's corporate headquarters as posted on their Web page - 1-800-446-8848 But lo and behold, the area code for the area I live in recently changed from 510 to 925, so apparently the phone switch at quicken decided I was calling from Canada. Instead of technical support, I got a new telephone number to call that was toll-free from Canada - but of course it doesn't work from the United States. Next I tried the operator (not the quicken operator - no such option on their answering machine and buttins like 0 don't work) and got a number in Mountain View for the real Quicken headquarters - which I called. Naturally, I finally did get an operator - and I found out that there is a number for quicken technical people - it's 520-618-7292 - but the operator told me that it wouldn't help to have the number today (Thursday) since all the employees were having a party today to celebrate that 15th anniversary of the founding of the company. I tried anyway and got a fast busy signal. So my denial of service was caused by: A human design failure in my willingness to trust a computer with my upcoming appointments. A hardware failure in a palmtop computer. A software failure in the inability to read the hardware-corrupted files. A business failure by HP not having the necessary information on their own products. An information failure in the Intuit Web page not leading you to technical support that knows the answer to your questions. An infrastructure failure in the telephone system deciding I am from Canada. A business model failure in my expectation that during normal business hours a company that is supposed to be a major player in a financial industry would be available to support their products. AND A support failure in that they were not available to support their product. The probability of all of this set of events must be astronomically small by the calculations of any competent risk analysis system, but that just goes to show you - tightly coupled systems with interdependencies... yada yada yada As a postscript, by now I have recovered most of my data — using an old fashioned text editor and the normal tools available from Unix. Under DOS or Windows there was no hope. Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:510-454-0171
I do not know if it happens to other www owners, designers and webmasters,
but from time to time some smart fellows, kleptomaniacs, used to come to my
web site to "collect" my animated gifs, although there is a precise and
clear copyright notice at all of my 300+ web pages. The
catch_as_catch_can_minded "webmasters" simply download it and put it on
their web pages. And, of course, they are also claiming copyright for the
entire contents of their web pages...
>From time to time I go to a research expedition throughout the Cyberspace
looking for animated gifs stolen from my web site (Mario's Cyberspace
Station <http://mprofaca.cro.net/mainmenu.html>)
In past few years so I found my little animated red devils at others
web pages in Croatia, Slovenia, U.S.A., Japan, Spain, Australia, and Taiwan.
When discovered, I used to send a kind message to the webmaster asking them
to remove my images (animated gifs) from their web site for it is my
copyright. And they always did. Some of them sent to me a sort of apology,
somebody did not answer to my message but simply remove it.
But this last case is the worst of all. This Australian lady-webmaster did
not answer to my messages, although I was tracking her and saw she received
it. And, "of course", she did not remove my animated gif from her web site.
What makes this case the worst is that she put my animated gif novine.gif,
<http://www.powerup.com.au/~hoile/sjh_an11.htm> my little red devil reading
newspaper ("novine" in Croatian language means "newspaper"), at "her"
animated gifs collection even asking her visitors to feel free to use those
images on their web pages (!)
Hope somebody shall learn something out of this case:
The lesson (or just a question) is:
Is such little theft worth this publicity on Internet?
Mario Profaca, Mario's Cybrspace Station
<http://mprofaca.cro.net/mainmenu.html>
Declan McCullagh <declan@well.com> quotes TIME Magazine, April 20, 1998 as reporting: " Now crooks scanning the airwaves can remotely tap into a call and duplicate the owner's digital ID. "We can clone the phones," brags Marc Briceno, who organized the cracking. His advice: manufacturers should stick to publicly vetted codes that a bunch of geeks can't crack in their spare time." My understanding is that they managed to crack the code on the SIM or smart card, not any radio-transmitted information. They repeatedly asked the card to identify itself, and so cracked it by brute force. The article also says: ``What was even more intriguing than the security threat, however, was that cracking the code yielded a tantalizing hint that a digital key used by GSM may have been intentionally weakened during the design process to permit government agencies to eavesdrop on cellular telephone conversations.'' This has been known for years. The use of GSM in Australia, for instance, was blocked on the day of the official launch because the security and police services wanted an easier code to break. At that time, I understand, they just switched encryption off. This was also widely reported in Europe at the time, and openly admitted. The original A5 encryption was promoted as being "NATO level security" which was a bit of overkill for a mobile phone that is probably going to be used with an insecure wireline link, and often used in public places. Now it appears that they've cut the 64-bit key down to an effective 54-bit by adding trailing zeros to make it easier to crack. It would still be a pretty healthy sort of encryption even at this level however. Stewart Fist, 70 Middle Harbour Road, Lindfield, 2070, N.S.W, Australia +61 2 9416 7458 http://www.theaustralian.com.au/techno/columns/fist.htm
Call for papers: Seventh IFIP International Working Conference on
Dependable Computing for Critical Applications (DCCA-7)
January 6-8, 1999 in San Jose California, USA
Various versions of the CFP, together with additional information and links,
are available from the DCCA-7 Web page at http://www.csl.sri.com/dcca7 .
The paper submission deadline is 3 August 1998.
General Chair
Charles B. Weinstock, SEI, USA
Program Chair
John Rushby, SRI International, USA
Organized by
IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance
In cooperation with (pending approvals)
The Software Engineering Institute, Carnegie Mellon University
IFIP Technical Committee 11 on Security and Protection
IEEE Computer Society Technical Committee on Fault-Tolerant Computing
EWICS Technical Committee 7 on Systems Reliability, Safety and Security
Please report problems with the web pages to the maintainer