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…
Speaking of things not working as expected (see the next three messages), the active RISKS disk on CSL was down from late Thursday until mid-Monday. [The repairman said finally today rather calmly, "The disk motor fell out."] The mail server (Hercules) remained up. Nevertheless, all sorts of incoming mail was rejected. If you got BARFmail, please RETRY. Thanks. PGN
The 10 June 1991 issue of Aviation Week and Space Technology (p.25-26) has another increment on the Dhahran Scud attack. In the four-day siege ending on 25 Feb 91, one of the two batteries was down for radar repairs. The other had endured a clock drift of .36 seconds, which was enough to prevent the radar from tracking the Scud. It seems that the spec called for 22 hours of continuous operation, with the tacit assumption that the system would be shut down each day, maintained, and possibly moved to another location. 100 hours was obviously well beyond spec...
A fiber cable cut, in Annandale, Virginia, knocked out the Associated Press's audio feed for their radio news service. They do have a backup routing system, which switches transmissions to a second cable if the first one fails. However, according to a spokesperson for the AP, ``Somehow, they both ended up being hit by this incident.'' --Steve Bellovin
About 80,000 telephone circuits were accidentally knocked out when a contractor severed two fiber-optic cables in a suburb of Washington, D.C. UPI, AP, the Pentagon, residential, and business phones were cut off for a few hours in the morning of 14 June 91, along with some cellular phone relay stations. [Source: San Francisco Chronicle, 15 June 81, p.A5] The outage lasted from 9:30am until 3:30pm. <<<<<<<<<<<<<<<><><><><><><><> TWO cables in one swell foop! So, as in the 1986 cutoff of New England from the rest of the ARPAnet because one cable held all supposedly-independent 7 circuits, the primary and the backup were knocked out — this time despite the precaution of running them through separate cables. Murphy and his twin brother were both at work. This episode occurred just in time to add another datapoint for my talk at COMPASS '91 on 26 June at NIST in Gaithersburg MD, presenting my annual `risk award' paper, this year's title being "The Computer-Related Risk of the Year: Weak Links and Correlated Events", considering a bunch of outages resulting from single-point failures and other cases in which apparently independent events resulted in disasters. The phone cases discussed include the AT&T long-distance problem on Jan 15 1990, the NY-area cable on 4 Jan 91, and the White Plains ARPAnet 7-link outage 12 Dec 86. The multiple-event cases are also drawn from the RISKS archives. If you are interested in COMPASS '91 (information, proceedings, etc.), please contact Dolores Wallace at NIST. Try email@example.com or mayhaps DWallace@nist.gov if their "standardization" works... Oh, by the way, RISKS will slow down for this week and next. I'll put out an issue only now and then. PGN
An item appeared in yesterday's Mail on Sunday which sent a shiver down my spine. (I don't have the article to hand, so I am summarising from memory.) Apparently, innocent British kids are being corrupted by a tidal wave of filth from the other side of the Atlantic. This is being beamed right into their homes via satellite, and all they have to do is flick a switch on their computers to receive explicit hard-core porno pictures which they can display on screen. The authorities are powerless, since the source is outside the UK, and even the existing laws governing posting of indecent material do not apply. This dire state of affairs has come to the attention of a certain Emma Nicholson, MP (she of the proposed draconian laws against hackers: see RISKS passim), who thinks that someone ought to do something about it. Expect some half-baked attempt to introduce legislation to control UK access to Internet! :-( Peter Mellor, Centre for Software Reliability, City University, Northampton Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 firstname.lastname@example.org(JANET)
The IRS is heavily involved in a Tax Systems Modernization (TSM) program. The following (part of the public record) is from the IRS Commissioner's testimony to congress about the program. Chart 2 Projected Benefits From TSM Eliminate 6-7 million unnecessary contacts with taxpayers each year that are now required to correct name, address, social security number or account information. Eliminates 95 percent of the computer-generated enforcement notices that our current systems mail out after a taxpayer has properly responded to a prior notice. Resolve during the first call 80 percent of all taxpayer questions that are raised by telephone. Assure that in 95 percent of all cases, a taxpayer can resolve an IRS-related matter by dealing with a single IRS employee, and can do so within specified time frames (ranging from minutes to months, depending upon the nature of that matter). Generate all account-related correspondence to a specific taxpayer, not a generic "taxpayer". In all cases, provide IRS front-line employees (and taxpayers) with current, complete and accurate account information. Provide copies of tax returns to IRS employees and taxpayers within one day rather than the current 45-day target. (A goal we presently are unable to meet one-third of the time.) Reduce case processing times by 20-15 percent. Reduce taxpayer, practitioner and IRS caused processing errors by 70-90 percent for electronically filed returns; increase number of taxpayers using electronic filing from 4 milion (1990) to more than 25 million by the mid-1990s. Maintain and enhance the privacy and confidentiality of tax returns and taxpayer information. Generate the information necessary to move from after-the-fact, case-by-case enforcement activities activities to comprehensive strategies designed to enhance voluntary compliance, while minimizing the burden on taxpayers and reducing costs to the government. Generate annual savings of $500-700 million (by reducing systems maintenance costs, reducing staffing in paper intensive processing activities, and eliminating the costs of storing and retrieving paper documents).
The European Commission (CEC) has issued a draft directive on privacy of telecommunications. The idea is to bring the EC natins' laws into harmony, so that the service and privacy are the same throughout the EC. The draft directive is COM(90) 314 final - SYN 288. Some parts may be interesting for comparison with US practices: Article 8: The telecommunications organisation [t.o.] must provide adequate, state-of-the-art protection of personal data against unauthorised access and use. In case of particular risk of a breach of the security of the network, for example in the field mobile radio telephony [sic], the t.o. must inform the subscribers concerning such risk and offer them an end-to-end encryption service. Article 12: [paraphrased]. callers must be able to disable CID per-call, and per-line. Called subscribers must be able to disable incoming display of IDs per call or per line, and must be able to restrict incoming calls to those which transmit IDs. Overrides must be available for tracing nuisance calls and for emergency services, and these must work community-wide. Article 17: [paraphrased] Subscribers must be able to request that unsolicited advertising calls are blocked, and the t.o. must take the necessary steps to prevent such calls. Article 19: "The provisions of this directive relating to the telephone service shall be applied to other public digital telecommunications services to the extent that these services present similar risks for the privacy of the user". Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: email@example.com
The Commission of the European Community (CEC) has issued a proposal for a Directive on data protection [COM(90) 314 final - SYN 287.] It is very detailed and prescriptive. The broad principles are similar to the UK Data Protection Act (which I assume is well-enough known to save me hours of typing!) with two notable extensions: The "data-subject" has to have given informed consent to any processing which goes beyond "correspondence purposes" (subject to exceptions for public authorities and other processing specifically authorised by law). The protection is NOT limited to computer files - it covers all manual files as well. Article 17 is interesting: "The Member States shall prohibit the automatic processing of data revealing ethnic or racial origin, political opinions, religious or philosophical beliefs or trade union membership, and of data concerning health or sexual life, without the express and written consent, freely given, of the data subject. [ ... ... ] Data concerning criminal convictions may only be held in public sector files." Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: firstname.lastname@example.org
Algol lost out to Fortran in part because of imperialism: Algol was superior to Fortran but the United States could not concede that the Europeans had the lead in programming languages. This claim, though (mercifully) tangential from the main thread, is actually quite relevant if viewed differently. Is Algol really superior? By what metric? Fortran was carefully crafted to be as efficient as assembler language. Witness, for example, the restrictions on subscript form — they were imposed so that a comparatively-simple compiler — and today's optimizers didn't exist -- could generate excellent code. Algol, on the other hand, had constructs like call by name, and required a stack for efficient implementation. Today, with the hindsight of 30-odd years, it's easy to see that Algol is better. But the criteria by which we make that judgement didn't even exist then — all there was was the clash of efficiency versus an (obvious) elegance. And even if those making the choice had known of our concerns, it's far from obvious what they would have decided — machine cycles were not seen as a luxury. Sure, cultural NIH played a part. But don't discount the effect of people aiming for different — and equally valid — targets. (I leave the connection as an exercise for the reader.) --Steve Bellovin
I must respectfully disagree with the claim in Risks 11.90 that Algol lost out to Fortran because of an American rejection of a superio — but non-American -- language. There are several other reasons, some of them actually Risks related: -- Algol-60 lacked a usable input-output method, especially one appropriate for the offline tab-equipment (punch cards and line printers) in common use in America in the '50's and early '60's. This was an intentional omission in Algol-60, as many of the computers it was first (in Europe) were one-of-a-kind research computers that used 5-channel paper tape and teletype printers. Magtape was generally unavailable. -- No Algol-60 compiler was available on an IBM-709 series machine until, roughly, 1966. (Well, there was the Algol-58 MAD, but it was a university development that ran on a non-standard executive.) By 1965, however, Fortran was being taught to engineers as an engineering tool (one of my programming courses was in the agriculture department), the IBM 360 was about to replace the 709-series. and PL/I was not yet available. -- IBM *marketed* Fortran to engineers: I learned it from a tiny manual called, as I recall, "An Introduction to Engineering Analysis by Computer" that taught Fortran by example, and used "real" engineering problems for its examples (structural engineers did not see the relevance of the eight queens problem). The above claims are from my own experience: I learned Algol (from Dijkstra's book) before Fortran, gave some minor assistance to the Alcor-Illinois Algol-60 compiler team, and programmed for several years exclusively in Algol-60 on an European 1st-generation computer using a compiler that I believe was written by Dijkstra — and a very good compiler it was, too. Martin Minow email@example.com
John (J.G.) Mainwaring, in response to my recent statements on caller ID (CID), suggests that since 800 calls are essentially a "collect call", that caller number information is appropriate to provide to the callee. He states: "A call to an 800 number is in fact a collect call. A person (or company) has at least a plausible argument that they should know who is calling, and have the right to refuse calls from whomever they please." He also suggests that callers could avoid perceived problems by finding the number of the company via directory assistance and not using the 800 number. Outside of the fact that this would require the caller to pay for the call, it can be difficult, and often impossible, to gather enough information from a quick commercial or even a print ad to dig out the actual name of the parent firm who would be listed and to know where they are listed. Then you end up paying for the directory assistance call, and, assuming you get a number, find yourself talking to a receptionist at corporate headquarters, rather than the sales or info people who answer the 800 number and might be located somewhere else entirely! I would agree that 800 calls, being of a "callee pays" nature, are deserving of special consideration (however, this does not apply to non-800 calls, which are the primary focus of the now appearing general purpose CID systems). One of the problems, however, as has been mentioned here before, is that CID does not tell who is calling, it tells the number of phone from whom the caller is calling! When someone calls you collect, are you told the number they are calling from? No, you are told *who* is calling. As I mentioned in my original article, people make calls from different numbers at different times! Nor should one be required to provide their number in order to "identify" themselves. Telling someone who you are (if they have a "need to know") is one matter--giving them your (possibly unlisted) phone number is something entirely different. While at least one telco is experimenting with a name delivery service in conjunction with CID, this as far as I know is providing the name associated with the phone number account, not a name as provided by the person who is actually making the call (who may have nothing to do with the name on the account). This forum has previously seen discussion of proposals that would allow the caller to individually specify what name would be sent to the callee as an identification on a call from any phone. There is no evidence that the telcos are interested in such systems or that they are moving in that direction. Such systems would of course have various RISKs associated with them as well, and I would consider it important that callers still be able to choose not sending any identification at all if they so desire. Decisions made on the basis of caller telephone numbers will often be incorrect. Even worse, callers may not even realize why they were treated the way they were, since they won't usually know how much (possibly erroneous and often invasive) information was gathered based on their phone number before their call was answered. The ANI magazine I mentioned previously suggested using calling number as a means to determine what language operator to use when answering incoming calls, since, it states, "people who speak different languages tend to live in geographic clumps". While this is one of the less onerous applications of this technology, it gives some insight into the rather bizarre thinking going on among some of the proponents of these systems. Regarding the specific issues of 800 numbers, the legitimate concerns of the firms paying for these numbers can be preserved in other ways. Presumably it could be made possible for them to block calls from particular numbers, without knowing what those numbers are, just as in standard CID systems. There are of course RISKs associated with this, given that you are dealing with a phone number, not the person who might be, for example, making harrassing calls to your firm. You could end up blocking a number that happened to be used for some troublesome calls at one time but that later might represent a potential customer. And people do change their phone numbers! An even better technique would be for the telcos and long distance (LD) carriers to be required to respond to an 800 subscriber's request for dealing with harrassing or troublesome calls. This could be done by the telco or carrier looking at the call pattern information for the subscriber (at their request) to determine the caller numbers, or through the use of a Call Trace system like that which exists as an alternative to CID for conventional calls. In either case, the subscriber themselves would not need to know the caller's phone number. To make it easier for the 800 subscriber to detect abusive calling patterns but avoid the problems associated with full number delivery, it might be reasonable to provide the 800 subscriber with the caller's area code and prefix only, when the caller has specified CID blocking. This would only apply for 800 calls--for all other calls a CID block would result in no number information being provided. Area code and prefix would provide enough data to pick out harrassing or other troublesome 800 call patterns. In conjunction with rules that required the telco or LD carrier to cooperate in such cases to use their full number information that they have for the callers to deal with taking action against such callers, this could solve the problems without revealing the full caller number to the 800 service subscriber. The lack of full number would make most of the more obnoxious applications of CID/ANI delivery on 800 numbers impossible. Of course, the telcos and LD carriers would prefer not to be involved in this process. They'd prefer that the caller and callee just slug it out completely amongst themselves. Their main concern is that if full calling number information is not available to the entity being called, a massive potential revenue stream from business applications that would make (mostly realtime) use of these numbers would be rendered impractical. --Lauren--
Please report problems with the web pages to the maintainer