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…
Sorry that I do not have much specific information on, or identifiable sources for, this story - it was reported in my local newspaper (San Antonio Express-News), and my copy was recycled before I thought of posting it here (being a new RISKS reader - I promise to do better next time!). Some of the details may be misremembered, but the gist is correct. Seems like a Dallas prisoner was temporarily transferred from one prison to another (from a federal prison to a state prison?) so that he could serve as a witness in somebody else's trial. Apparently, one of the computer systems involved recognized that he was on "temporary assignment" and absent from the original prison - all well and good, except that after 30 days of absence the system defaulted to flagging him as no longer being incarcerated in the original prison. Once the trial in which he was a witness ended, he was released from the "loaning" prison and was released. Although he was eventually put back in prison, since this man was in for a dangerous crime, this episode is pretty alarming. Richard Fahey
This bill, if enacted, would limit recovery in actions for damages resulting from a "computer date failure," i.e., Y2K failures. Under the bill (if passed), in a lawsuit for a Y2K bug, the plaintiff could recover only the reasonable costs of correcting the bug, and damages resulting from bodily injury. As I read this, if, for example, a bug in a money management program caused the system to send out checks in appropriately, you would not be able to sue the software company to recover the money you lost (assuming you couldn't get a refund from the improperly paid parties), and you wouldn't be able to recover for the check-bounce fees imposed by your bank because your balance was not sufficient to cover all the incorrectly-issued checks. The bill seems to apply to contracts as well as to torts (such as negligence), and there's no provision specifically limiting it to contracts entered into after the date of enactment (however, it does permit a contract to override this provision and expressly allow for further damages). I've added the bill to my Copyright Resource Page (a misnomer — I now have a lot of stuff besides copyright, this being one example) at <http://www.aimnet.com/~carroll/copyright/faq-home.html>. I have both a text copy and a PDF version (for those who would like the official printings). Here's the most pertinent part of the bill. For the rest (definitions, clarifications, etc.), please see the above-referenced URL. (a) Notwithstanding any other provision of law, in any action to recover damages resulting directly or indirectly from a computer date failure, including any action based on an alleged failure properly to detect, disclose, prevent, report on, or remediate a computer date failure, the damages that may be recovered shall be limited to either or both of the following, according to proof: (1) Any damages resulting from bodily injury, excluding emotional injury, to the plaintiff proximately caused by the defendant's conduct. (2) Any costs reasonably incurred to reprogram or replace and internally test the relevant computer system, computer program or software, or internal hardware timer, to the extent those costs are incurred as a proximate and direct result of the defendant's conduct. Terry Carroll Santa Clara, CA carroll@tjc.com
Outages (complete failures, a distinct from degradation of service due to partial failures) of air traffic control computer systems, particularly those at the U.S. Air Route Traffic Control Centers (ARTCCs) have been a subject of continuing interest in RISKS (a keyword search on the archive showed well over a hundred references, many of which refer to partial failures or outages). The U.S. National Transportation Safety Board (NTSB) prepared a report in January 1996 (NTSB/SIR-96-01) on ATC system outages, dealing with incidents between September 12 1994 and September 12 1995 and assessing the FAA's modernisation program. There is a significant `legacy' problem with some of the systems, and the scope of the FAA's Advanced Automation System (AAS), which has been in development since 1981, was significantly revised downwards when the contract for the `be all to end all' system was cancelled by the FAA in mid-1994 because of continual schedule slippage and cost overruns. The NTSB report discusses the architecture of the display systems in the ARTCCs, the nature of the outages (4 power failures, 7 computer problems), and the FAA's upgrade plans (which crudely amount to replacement of legacy systems in an evolutionary manner, rather than a redesign). In the 11 incidents, only one operational error (loss of separation) was reported, although all involved degradation of service (i.e. delays) ranging from the trivial (1) to the extreme (485). The report also notes that many controllers do not appear to be aware of the full range of functions still available to them during partial degradation. The board concludes that the system remains `very safe', even though the failures have a significant economic impact, but is concerned about the safety implications of the increasing number of failures of the older equipment. The AAS is considered a `high-risk program' by the U.S. General Accounting Office (GAO), which has produced a series of reports, the latest from 1997 being on the WWW. A `high-risk program' is one at `high risk for waste, fraud, abuse and mismanagement' (!). The NTSB report is now available on the WWW in the compendium `Computer-Related Incidents with Commercial Aircraft', which also contains links to the GAO reports: http://www.rvs.uni-bielefeld.de --> `Computer-Related Incidents..' --> `U.S. Air Traffic Control Center Outages and the Advanced Automation System'. Other recent additions to the compendium include the Rapport Preliminaire of the French DGA on the A330 test flight accident in Toulouse (Mellor, RISKS-16.19; Jackson, Ladkin, 16.22, Ladkin, 16.23; Hollnagel, 16.31; Ladkin, 16.39); the final report on the Lauda Air B767 accident (Leyland, 11.78; Grodberg, Kopetz, Morris, Philipson, 11.82; Neumann, 11.84; Mellor, 11.95; Leveson, 12.16; Leveson, 12.69); the 1985 China Air B747 accident (Trei, 3.79); and the 1983 Eastern Airlines L1011 Common Mode Failure incident (not itself computer-related, but I believe relevant for understanding common mode failures resulting from imperfect maintenance, as in the 1996 Aeroperu B757 accident, Ladkin, 18.51; Neumann, 18.57; Ladkin, 18.59). I am very grateful to Hiroshi Sogame of the Safety Promotion Committee of All-Nippon Airways for his public service in preparing various of these and other reports for the compendium. Peter Ladkin ladkin@rvs.uni-bielefeld.de http://www.rvs.uni-bielefeld.de
An interesting article on "Software Tempest" — here's a short notice posted by Peter Gutmann to the Cryptography e-mail list: > There's a fascinating paper on software anti-TEMPEST (and, in general, > TEMPEST-related) measures by Markus Kuhn and Ross Anderson available > from http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf. It describes > both how to make TEMPEST eavesdropping difficult using only software, > and how to build TEMPEST-friendly software. A much longer and more detailed announcement (with some background notes by one of the authors) was posted by John Young to the Cypherpunks e-mail list. > To: ukcrypto@maillist.ox.ac.uk > Subject: It is really me - the story of Soft Tempest > Date: Sun, 08 Feb 1998 15:09:40 +0000 > From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk> $The Washington Post$ gives a highly distorted account of some very important scientific work we have done. I suggest that list members read our paper - <www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf> - for themselves before getting carried away. The story is as follows. Bill G gave our department $20m for a new building, and his people said that what they really wanted from our group was a better way to control software copying. So it would have been rather churlish of us not to at least look at their `problem'. Now the `final solution' being peddled by the smartcard industry (and others) is to make software copying physically impossible, by tying program execution to a unique tamper-resistant hardware token. We wouldn't like to see this happen, and we have already done a lot to undermine confidence in the claims of tamper-proofness made by smartcard salesmen. So Markus and I sat down and tried to figure out what we could do for the Evil Empire. We concluded that (1) large companies generally pay for their software; (2) if you try to coerce private individuals, the political backlash would be too much; so (3) if the Evil Empire is to increase its revenue by cracking down on piracy, the people to go after are medium-sized companies. So the design goal we set ourselves was a technology that would enable software vendors to catch the medium-sized offender - the dodgy freight company that runs 70 copies of Office 97 but only paid for one - while being ineffective against private individuals. We succeeded. In the process we have made some fundamental discoveries about Tempest. Army signals officers, defence contractors and spooks have been visibly flabberghasted to hear our ideas or see our demo. In the old days, Tempest was about expensive hardware - custom equipment to monitor the enemy's emissions and very tricky shielding to stop him doing the same to you. It was all classified and strictly off-limits to the open research community. We have ended that era. You can now use software to cause the eavesdropper in the van outside your house to see a completely different image from the one that you see on your screen. In its simplest form, our technique uses specially designed `Tempest fonts' to make the text on your screen invisible to the spooks. Our paper tells you how to design and code your own. There are many opportunities for camouflage, deception and misconduct. For example, you could write a Tempest virus to snarf your enemy's PGP private key and radiate it without his knowledge by manipulating the dither patterns in his screen saver. You could even pick up the signal on a $100 short wave radio. The implications for people trying to build secure computer systems are non-trivial. Anyway, we offered Bill G the prospect that instead of Word radiating the text you're working on to every spook on the block, it would only radiate a one-way function of its licence serial number. This would let an observer tell whether two machines were simultaneously running the same copy of Word, but nothing more. Surely a win-win situation, for Bill and for privacy. But Microsoft turned down our offer. I won't breach confidences, but the high order bit is that their hearts are set on the kind of technology the smartcard people are promising - one that will definitively prevent all copying, even by private individuals. We don't plan to help them on that, and I expect that if they field anything that works, the net result will be to get Microsoft dismembered by the Department of Justice. Meantime we want our Soft Tempest technology to be incorporated in as many products as possible - and not just security products! So to Rainier Fahs, who asked: > If these rumors are true, I guess we will face a similar discussion on > free availability in the area of TEMPEST equipment. Does privacy > protection also include the free choice of protection mechanism? I say this: our discovery, that Tempest protection can be done in software as well as hardware, puts it beyond the reach of effective export control. So yes, you now have a choice. You didn't before, Ross Anderson [Tempest foo-gets! PGN]
>From the $London Evening Standard$ of 18 Jan 1998: Drivers are defeated by clever cars Breakdowns caused by lost keys and confusion over sophisticated car security systems overtook flat tyres for the first time in an analysis of calls to the AA. Of the 4.5 million call-outs last year, the most, 825,424, were due to flat or faulty batteries, followed by 269,070 because alarm systems or locks failed. Peter Mellor, Centre for Software Reliability, City University, London, p.mellor@csr.city.ac.uk [In Britain, AA is presumably the Automobile Association. PGN]
Is this a joke? If so, how did it get past our trusty moderator? (Book now and avoid the April 1st rush! :-) The crash of the A320 on final approach to Strasbourg in 1992 was most probably due to the fact that the crew were using the "vertical speed" mode of the autopilot to control their descent instead of the "flight path angle" mode, and somehow failed to notice this. The result of this "mode confusion" was that they descended three times as fast as was shown for the approach path on the plates for Strasbourg. This is only the "most probable" cause, since there are still uncertainties about the last moments of the flight. I summarised the findings of the accident report (and included some speculations of my own) in my paper:- ``CAD: Computer-Aided Disaster'', High Integrity Systems, Vol. 1, Iss. 2 (Oxford University Press: 1994) pp 101-156 I will leave it to others who have studied the relevant accidents to comment upon the relevance of the "resonance characteristics of both the solar system and outer space" to those. Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 (171) 477-8422 p.mellor@csr.city.ac.uk [Ah, yes, thanks to all of you who responded so strongly to this item. PGN]
I continue to receive mail on my robots.txt comments. Those who disagree with my criticism are (I must say) the majority, but not by far unanimity, and there are interesting nuances in the disagreements. I found all the contributions very enlightening. I will continue to add all messages received (unless contributors specify otherwise) to the Web page, which is now in place: http://www.eiffel.com/private/meyer/robots.html Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel <Bertrand.Meyer@eiffel.com>, http://www.eiffel.com
> The treatment of null values is arguably reasonable once it is > understood - null values simply fail all comparisons with non-null > variables. ... Nowhere does it tell us which language. Java, VB, what? I think it's rather important to know. In all the languages I know there is no genuine null value, just something along the lines of "equate null to 0" Anthony W. Youngman wol@thewolery.demon.co.uk [Lots of other messages on this topic. TNX. PGN]
John Wilson <jowilson@mtu.edu> worried about what unscrupulous folk, unwilling to acknowledge or respect interests other than their own, might inflict on the public now that Netscape has decided to release the source code for the Netscape 5.0 browser. What Mr. Wilson overlooks, perhaps, is what some unscrupulous folk, unwilling to acknowledge or respect interests other than their own, have already done to tens of millions of Internet users — and what they were able to get away with largely because Netscape's source code was unavailable. By forbidding the export of web servers and browsers with strong crypto to non-American users (with a few narrow and humiliating exceptions,) US policymakers have left the commercial, professional, and personal correspondence and web-based transactions of millions of non-American citizens all but naked to eavesdropping by criminals (petty and organized,) industrial spies, gossip-mongers, aggressive office-pols, wannabe blackmailers, rogue cops, managers with feudal delusions, and curious 14 year-olds with access to a contemporary PC (or — if they they want to pop secrets free within hours — the computational resources of a typical college computer lab.) The image and reputation of the US, and of American engineering and technology, has suffered grievous harm so as to allow the NSA to gain what transient enlightenment it could from it's world-wide "Echelon" sweeps of the data lines and communications spectrum. Reaction to the scheduled release, today, of a report by the Civil Liberties and Interior Committee of the European Parliament on the NSA's systematic snooping on all European telephone, fax, and digital communications may indicate how bitter that resentment has become. (Swedish parliamentarians were outraged recently to discover that the confidentiality of encrypted traffic on their Lotus Notes system was apparently dependent on the self-restraint of the NSA — which demanded partial access to the Notes crypto-key before the product was shipped abroad.) The web — and in particular, Netscape's browser, due to its popular success and widespread use — has become the focus of much concern and attention from those who believe that privacy and optional confidentiality are fundamental to the dignity and liberty of any man or woman, anywhere. SSL, the encrypted channel built into the WWW spec, offered the first encryption systems that was universally available, to the far reaches of the global Internet. The problem was, only Americans got strong (128-bit) crypto. US export policy allowed vendors to ship only weak easily-broken 40-bit crypto in browsers exported to non-Americans, so the browsers freely downloaded off the Microsoft and Netscape ftp sites world-wide were almost always insecure, providing security of poor quality by design and government fiat. Non-American webservers can offer strong-crypto alternatives to the innovative American products which paced the technology — and even the crippled export-level American webservers can have their weak SSL encryption enhanced by java applets (Brokat's Xpresso <www.brokat.de>) or proxy/translators (C2's SafePassage <www.c2.net>) — but it was only a few months ago that Farrell McKay's remarkable freeware product, Fortify, became widely available. <http://www.fortify.net> Fortify allows anyone anywhere to upgrade a Netscape browser (Navigator v3 or Communicator v4) with weak or export-strength crypto into one with the 128-bit SSL capabilities for confidentiality (and secure e-commerce) that Americans take for granted when they do business on the web. An executive with one of the big international auditing firms told me a month ago that Fortify is "all over Africa," particularly in banking. "It's free, and it's legally available from its British website. They'd be idiots not to use it! I recommend it to all my international clients." McKay's program installs itself directly in the Netscape browser to upgrade it's SSL code, so that anyone with a export-quality browser can get a 128-bit strong-crypto link when he connects to a webserver that is itself capable of establishing a strong SSL connection. Unfortunately, McKay's magic did not extend to strengthening the S/MIME crypto has added encryption for electronic mail to recent versions of both the Netscape and the Microsoft browsers. McKay gave international users of Netscape a secure 128-bit SSL channel, but neither he — nor, apparently, anyone else — has been able to do the same with the S/MIME routines which were also crippled and weakened to 40-bit crypto, by government order, before export. The web is popular, but e-mail is still the "killer app." Strong SSL, now universally available, enables many types of form-based transactions on the Web — but freely-available strong S/MIME for private mail will break the dam. Some dream it could change the world. Farrell McKay fervently believes that getting the Netscape source in circulation among those who can pick it apart is the gateway to a future in which everyone can expect their mail to be confidential (at least until some local lawmen shows up, with proper authority to demand access from one of the correspondents.) "I live in the hope that there will be entire armies of enthusiastic programmers all busily building strong crypto facilities into the v5.x releases," he exulted in a note he sent me yesterday from Australia. "This move really opens up a huge number of possibilities for the international community." Many American think that's just great, on balance. ("All men are created equal," and stuff like that.) Virtually all non-Americans have no doubt. Much of the world is hoping that electronic commerce will be the backbone of the 21st Century economy — and you practically have to rate a limousine in Washington, D.C., before you can believe that international finance and trade will go online if the merchants, bankers, and businessmen believe that American spooks have rigged a party-line, and may or may not be listening. Having Netscape browser source-code in circulation won't change much overnight, of course. Given US restrictions on the export of privacy products, the release of the Netscape source code will doubtless be restricted too. Netscape's cryptographic modules will either not be released in source, or will be forbidden for export. Still, with all _but_ the Netscape privacy code accessible to clever programmers world-wide, it becomes all but certain that — as Netscape cryptographer Tom Weinstein suggested yesterday — "some enterprising individuals outside the US (will) replace the missing pieces." Odd what Americans have to do to get a quality product to the world market, huh?
Actually, the moment I started playing with McKay's wonderful program, I noticed that it didn't activate strong S/MIME, so I fixed it. Although I am (currently) in the US, I use Fortify because (at least the last I checked) there was no strong-crypto version of 4.04 for Linux. Now, I don't actually _use_ S/MIME, so I can't say for sure if it works, but the option to encrypt email with strong crypto is certainly presented to the user in my version. When I told McKay about this, he said that he had done a similar thing, and it was in testing. Another interesting point about Fortify: Fortify contains _no crypto_. The version of Netscape that is internationally available actually has _full-strength_ crypto in it. I believe this has something to do with the deal that was made that will allow full-strength crypto to be exported, but only if it is used with special servers (like some banks). The Netscape binary contains a table that lists all the available crypto routines, and along with each is a flag that indicates whether it should always be available (for the 40-bit stuff) or only available when talking to the special servers (for the good stuff). There is also some sort of integrity check to make sure you don't mess with the table. All Fortify does (as far as I can tell) is disable the integrity check, and then set all the SSL crypto routines in the table to "always available". It is straightforward to make it set the S/MIME routines in the same way. Now, of course, I can't _send you_ my version of Netscape with the strong S/MIME. It's very unclear to me whether I can send you my patched version of Fortify (all it does is set some bits in a table, remember). And, of course, I'm not 100% positive the S/MIME is working. On the other hand, if someone who uses Linux (though the fix should be trivial to port to other systems) wants to email me, and can convince me that he is a U.S. or Canadian citizen, understands the EAR regs, will not violate them, and will report on the usability of strong S/MIME, then I'll send my patches to Fortify along. - Ian
Risks readers may be interested in a new book on the politics of privacy: Whitfield Diffie and Susan Landau Privacy on the Line - The Politics of Wiretapping and Encryption Cambridge: The MIT Press ISBN 0-262-04167-7 This book provides an overview of cryptographic history, particularly as it has influenced — and been effected by — public policy, national security, and law enforcement. It not a technical book but, specifically, a book about the politics of cryptography. From the book jacket: Whitfield Diffie and Susan Landau argue that if we are to retain the privacy that characterized face-to-face relationships in the past, we must build the means of protecting that privacy into our communication systems. This has not proved simple, however. The development of such protection has been delayed — and may be prevented — by powerful elements of society that intercept communications in the name of protecting public safety, intelligence and law-enforcement agencies see the availability of strong cryptography as a threat to their functions. Martin Minow minow@apple.com [Excellent book. I read it cover to cover, and it held my attention better than many spy novels. PGN]
1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM March 11-13, 1998, Catamaran Resort Hotel, San Diego, California Sponsored by the Internet Society Program Chairs: Matt Bishop and Steve Kent ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss98 EARLY REGISTRATION DISCOUNT DEADLINE: ==> 13 Feb 1998 <== KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security Products Group at Bell Laboratories, Lucent Technologies THIS YEAR'S TOPICS INCLUDE: - Internet and Intranet security - Implementation issues for electronic commerce - All-optical networks security - Secure single login - Timestamping protocols - Remote password protocols - Mobile agent systems security - Java security - Trust management - Traffic analysis of TCP gateways - Secure bootstrapping - Firewalls and IP security NEW THIS YEAR! PRE-CONFERENCE TECHNICAL TUTORIALS FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1 703 648 9888 Fax: + 1 703 648 9887 E-mail: ndss98reg@isoc.org URL: http://www.isoc.org/ndss98/
Please report problems with the web pages to the maintainer