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…
Dave Parnas in a private note to me has raised a set of concerns involving the actions and inactions of a particular system. Those concerns seem very important to RISKS, and so I quote him here (with his permission). "What about the difference between risks of commission and risks of omission? Whenever we speak of a risk it is shorthand for the risk of some specific danger. I consider a risk to be one one of commission if the danger is that the system will perform some action from a finite set of "bad" things. A risk is one of omission if the danger is that the system does not perform the task that it was built to perform. I think risks of commission are less difficult to deal with than risks of omission for two reasons: (1) for risks of commission one can do specific "backward" analysis to look for ways that that danger could occur, (2) for risks of commission one can include checks and hardware to prevent the danger. Risks of omission are often insurmountable because confidence that they will not occur requires a proof of "correctness" or at least a proof of certain aspects of correctness. Do the readers of the forum agree with this distinction and evaluation? Can they site save examples of successful software with a severe risk of the omission type?" [Dave Parnas] There are several comments that I would like to make, and then I'll turn this open to the Forum. The finite set of "bad" things may be incomplete. An example in the security community is the multilevel security property — NO FLOW of information downward to a lower level of security or laterally to another compartment at the same security level. This is the property upon which various security kernels are based. However, it represents only a portion of the "bad things" that must be prevented. Furthermore, proving the NO FLOW property for a few dozen kernel functions is not enough if the entire machine language is accessible via assembly language! Yes, the former may seem easier to deal with — at least superficially. However, the errors of commission are insidious in that it is very hard to GUARANTEE their absence. In many cases the set of properties ("bad things") is already stated negatively ("X MAY NOT HAPPEN", as in the case of the NO FLOW property), and applies only abstractly. Even even if you can demonstrate that a particular interface (e.g.,a security kernel) satisfies the desired set of properties (that is, the design satisfies the properties and the code and hardware together are consistent with the design), the set of properties may incomplete. Thus, "correctness" arguments are relevant in the errors of commission as well — down to and including the hardware. Dave reminds us of Martin Moore's example of the range safety shuttle destruct system. "Here there are risks of both kinds. There is a risk that the system may destroy a shuttle that performs properly. There is also a risk that it may not destroy a shot that should be destroyed because it is about to crash in Miami's heavily populated area. Martin described how many measures could be taken to make the commission risk less likely. Physical control of data paths was one of those measures. However, it is much harder to see how we can make sure that the destruct system will perform. We would need some correctness arguments or extensive testing to have faith that it would perform when it should." [Dave Parnas] The risks of omission are also insidious in that the model of what must be done may be incomplete. While the distinction between errors of commission and omission is valuable, I suspect that there are essentially equivalent problems with each, but this is probably of little help in practice. Both types of risks must be considered. Furthermore, in some cases, a given problem may involve both types of errors. Peter [Perhaps a survey of the disaster list (e.g., RISKS-2.1) might be in order, but I want to get this issue out without further delay. PGN]
MORE LIKE Mon 14 Mar 7:50AM PST] Somehow the time-of-date clock on my system got reset to 7 Dec 1984 last night around 10:40 PM PST, while I was logged in. I was apparently the only user on the system at the time, but I was doing nothing unusual. Could it have been a dropped bit (despite parity) (I haven't had the patience to do the calculation of the time difference)? or a time-dependent software glitch? At any rate, it is something I had never seen before, and it seems quite relevant to RISKS. The side-effects of such a clock burp could be very painful. (1) A delete-by-date of older-dated versions of a file results in deletion of the newest versions actually created. (2) All of the messages in my mailboxes were marked as UNSEEN. In a mailbox with hundreds of messages, that is a nuisance. (3) In clock-dependent asynchronous systems, all hell could break loose. (Recall the first shuttle launch delay.) (4) All sorts of other things might stop working. (I wonder if anyone ever runs a system in the virtual past in order to keep the SCRIBE time-bomb from going off, to avoid paying UNILOGIC for another year!) PGN] [I waited to send this issue out until the clock had been corrected, in order to minimize further side-effects, notably confusion.] Peter
Comment: Found this in my mailbox. Something appears to have gone awry!! Taylor Landrum Forwarded message: ----------------------------------------------------- Date: Thu 6 Mar 86 22:27:50-PST From: RISKS @ SRI-CSL.ARPA Subject: RISKS-2.23 Sender: NEUMANN@SRI-CSL.ARPA cc: Text: LTC Elderd, I just got another issue of Bar Code News in the mail, and it had an insert on something called "ID EXPO", which is sponsored by Bar Code News, and is billed as "the conference and exposition of automatic identification and keyless data entry". It will be held at the civic auditorium/Brooks Hall in San Francisco, 19-21 May. ... - Jim Jack -------------END OF FORWARDED MESSAGE(S)------------- [I omit the rest of the message, and hope that Jim Jack does not mind my including this here. I hope you see that someone's mailer has committed A MONSTROUS SCREW-UP. The header information is precisely that of RISKS-2.23, and Landrum@DDN1 was on the list to receive that issue. But it is clear that the message received was truncated after some of the header stuff (notice the TO: field is missing!) and the text of another message concatenated. PGN]
The following article appeared in the Vancouver Sun (Vancouver, B.C.), Saturday, March 15th: New bills will prove that money can talk OTTAWA - It costs six cents to make, wears out in about a year, and is an oddball in the U.S., where today it's only worth $1.43. Someday it will even be able to talk - in both offical languages. It's the new Canadian $2 bill, announced today by the Bank of Canada, which has redesigned the deuce - and its $5 pal - for introduction later this year. ... The new bills will also have a feature to assist the visually-impaired distinguish denominations. Don Bennett, a spokeman for the Bank of Canada, said the new bills will have a code printed into them which, when inserted into an electronic device, will activate a synthesized "voice" which will speak the denomination. Bennett said the bank is continuing development work on the device, but field tests, which included Vancouver, were recently completed. Bennett said it will be the end of the decade before the devices are in wide-spread use although some may be available by 1987. The target cost is below $50. ... My curiousity is how "fool-proof" are these codes (I have not seen what the codes look like but I suspect something similar to that imprinted on personal checks) and devices. Does anyone know of something similar? Will money not only "talk" but "lie" too? [I am reminded of the BART and METRO fare cards. Although the remaining fare is encrypted, the magnetic stripe is trivial to copy. Since the encoded signature of the $2 bill will be identical for all $2 bills, in principle it should be easy to copy — perhaps onto an OLD $1 that has no such markings, although that is not such a great loss. What about higher denominations? (Holograms embedded in the bill to prevent forgeries (as in credit cards) would not help the blind much.) If you were blind, would you have any confidence in a machine that tells you that the bill you have just been given by a well-known shyster is a perfectly good $1000 bill? PGN]
The other day, someone finally reached me who had been trying for several days. I have a second phone line into my house that I use only for data — no telephone attached — and it seems she had gotten that phone number instead of the one I always use for voice. Usually I am either using the data line or the modem is turned off, so she kept getting a busy signal or no answer. Once, though, someone — my modem, left on for once — answered. It beeped, so she left a message, taking it for an answering machine. Took me for the sort who never returns phone calls.
Peter, I suggest that if you are as tired of modem stuff as you sound, you just redirect anybody who wants to talk further to TELECOM@XX. Lag time to the various parts of the net is bad enough that you will still be getting this crud for weeks if you don't put a lid on it. --Rob [I'm not tired of the topic itself, but I think our readers may grow a little weary of the seemingly endless variations on the theme. However, I think I may turn up my REJECT RATIO a little more. PGN]
Please report problems with the web pages to the maintainer