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…
A followup on the Nintendo Lottery noted in RISKS-12.41 is contained in an AP item from 28Sep91 regarding a Minnesota law forbidding minors from gambling: Lottery officials and lottery vendor Control Data Corp. of Bloomington say the game will have safeguards to prevent children from gambling, including personal passwords for users. I'm glad that solves the problem so easily. By the way, I will be East for a week for the National Computer Security Conference, where I expect to see quite a few of you. Among other things, Ken van Wyk (VIRUS-L and SEI.CMU) and I will be on a panel Tuesday on the risks of distributing security information electronically. That should be amusing, at least for the two of us. A few of you have commented on some funny spellings in the masthead first line. Please recall that on two-digit Wednesdays and Saturdays in September we have a line longer than 80 characters — resulting in the issue number getting TRUNCATED unless I foreshorten the line a little.
In the Fall 1991 issue of Graduate Computerworld ( A free publication consisting of promo articles on prospective employers ), there is an interview with Julius Gabriel, manager of software engineering at Spar Aerospace. Spar is doing the software for the Mobile Servicing Station; essentially a mobile version of the Canada-Arm. Gabriel notes that "The entire space station will be highly computerized, with a software program in excess of 10 million lines of code". Apparently the MSS will be a rather small fraction of the whole, about "half a million lines of code". Master of understatement, Gabriel notes that "Once its up there it's difficult to fix the software". The article notes that "Naturally, the entire software process adheres to rigorous standards such as the military 2167A standard". Gabriel makes some good points about the importance of software development methodology, but what worries me is the attitude that writing ( working ! ) 10 million line programs is a solved problem, that all we have to do is use Ada (TM AJPO) and mil-std 2167A, and everything will work fine. David References: Page 14, Fall 1991 _Graduate Computer World_ bremner@cs.sfu.ca ubc-cs!fornax!bremner
>consider the case in which the triple sensors are not "reverse-wired" but cross-wired (e.g. sensor 2 is connected to input 1 & vs). In this case, with "all good" everything is fine. If 3 fails all is ok. However if 1 or 2 fails, the other is reported failed, voted out... Things can get even more interesting if there is more than one set of wires to the sensors, e.g. for feedback control of some kind. The second Saturn V test launch had a double engine failure in the second stage that was traced to such a problem: one engine did indeed develop problems, but the "shut down" command from the control computer went to the neighboring engine instead. Henry Spencer at U of Toronto Zoology utzoo!henry
This is a classic case where technology can render traditional publication proofing useless if the technology is used inappropriately without proper checks and balances. In the traditional publishing environment, the galley proof usually has a photographic relationship to the final product. "Blue line" proofs for books are normally made from the same negatives that are then used to create the actual printing plates. The whole point of the galley or blue line proof is to give the author(s) an accurate representation of the final appearance of their work for their approval. When authors are placed in the position of approving a "proof" that does *not* represent that actual output that will be used to create the final plates, much of the point behind having the proof in the first place is lost. In the case where a font happens to vary in an unexpected manner (as in the case under discussion) this can be a rather serious problem. Authors should refuse to sign off on their works until their publishers supply them with a physical proof (not just an online representation unless it is a direct scan of the actual proof itself) that accurately shows the final output from the correct output device, complete with all fonts in their final forms. --Lauren--
As reported in RISKS-12.41, Simson Garfinkel described how a non-standard font set-up on a phototypesetter caused some problems with the printing of our book. What follows is the announcement O'Reilly & Associates (the publisher) has made about this error. No word yet on what they are going to do with (or to!) the shop that did the printing! We breathlessly await the third printing to see what goes wrong there. :-) O'Reilly & Associates has discovered that in the first printing of _Practical_UNIX_Security_ by Simson Garfinkel and Gene Spafford (June, 1991) a formatting error caused the grave quotes (`) in the shell scripts in our final PostScript files to be printed as forward quotes ('). Of course, this breaks the scripts and is certainly not what the authors, editor, or publisher intended. An errata sheet is available from the publisher that corrects these shell script examples and other minor technical errors found in the first printing. Please telephone O'Reilly & Associates at 800-338-6887 (US & Canada) to obtain a copy of this sheet. Alternatively, you may send email to steph@ora.com, to request a copy of the errata sheet — be sure to include your surface mail address. We apologize for any difficulties these errors may have caused!
Joseph Poirer writes about getting a receipt with someone else's name on it when he declined to identify himself at Radio Shack, and wonders if their computer system can't handle a transaction without a name. It turns out that this isn't a computer problem, it is simply a management problem. Radio Shack employees get a bonus if they capture more than 95% of their customer names, and the employees are reacting in a locally rational way to anonymous customers. Rat Shack has severe penalties for employees who make up names, but apparently using the wrong real name is so far OK. It is easy to ring up a sale with no name, I get them to do it all the time. Rat Shack claims they use the names only for their own mailing list which they do not sell, but at least one person has reported getting junk mail from other parties with the same distinctive misspelling as Rat Shack has. Personally, if they hassle me when I decline to give my name, I make one up. Sometimes when I'm in a bad mood, I make one up unprompted. Phooey. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl [This incentive to capture your vita was also noted by a bunch of other contributors, several of whom noted this discussion went on earlier for some time in comp.dcom.telecom. I therefore omit a whole slew of similar responses. You will understand if I do not enumerate you all! PGN]
Kraig Meyer [in RISKS 12.41]: "USC security also claims that keeping the card in an eel-skin wallet will erase the magnetic strip (anyone have any idea why this would be?)" This is an old Urban Legend, about eelskin (or snake, alligator, etc) purses and wallets. The explanation isn't some strange electro-magnetic effect of reptile skin. It is that such things often (usually?) have magnetic clasps! Apparently this has to do with the skin not having the mechanical strength of (e.g.) leather; where a mechanical clasp would tear the eelskin under stress, the magnetic clasp simply opens. — Robert Ullmann [Not surprisingly, we have slithered down this path before, WAY BACK IN RISKS-6.25 and RISKS-8.04 (Jane Dunlop Smith)!!! However, we have some alert contributors who again noted the mag clasp. This time * trebor@foretune.co.jp (Robert J Woodhead) * dplatt@ntg.com (Dave Platt) * mauxci!eci386!drk@apple.com (David King) and * kent@sunfs3.bos.camex.com (Kent Borg) all had puns on electric-eel-skins. * Al Stangenberger <forags@nature.Berkeley.Edu> noted the version that several women who carried magnetically encoded BART (subway) tickets in their eel-skin wallets noticed that the magnetic strips had been erased. Also noting the bogosity of the magnetic clasp effects were * henry@zoo.toronto.edu (Henry Spencer) and * richg@prodnet.la.locus.com (Rich Greenberg)
The fact that division by zero does not generate a fatal error but gives a special value is a property of IEEE 754. Likewise with 0/0 == ``Nan'' (Not a Number), etc. I won't repeat the arguments as to why this may or may not be appropriate, but if you'd look at the ``See Also'' section of the math(3M) man page, you'd see references to several papers that address the design — Kahan (the principle designer of 754) is quite compelling as to why 754's behavior is most reasonable. Is this a risk of coding without being cognizant of industry standards? Coding to an internal model of the machine that doesn't match reality? >Also if you notice on the output that the results are different depending on if you optimize or not. The fact that your code outputs ``Nan'' when it should have given ``+Infinity'' or ``-Infinity'' is probably a compiler bug. From the excerpt of the output, it appears that the behavior *with* optimization turned on is correct. This is actually a little surprising, since typically the optimizer introduces bugs, not the other way around. A risk of testing/debugging only that which we think is hard/bug-prone and skimping on the rest? Complaining about the compiler/floating point hardware to your vendor would be quite appropriate; complaints about IEEE 754 should probably go to Kahan instead. :) Risks of blame misattribution? Bennet S. Yee Phone: +1 412 268-7571 Email: bsy+@cs.cmu.edu School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
>We have an Alliant fx/800 computer... ... By default no action is taken on many of the exceptions. ... I do not know the exact reasons for this decision, it might have to do with performance, but who cares if the machine is fast if the answers are wrong? Very probably it's a performance issue. I don't have any detailed knowledge of the Alliant, but I do know that this is a generic problem with attempts to build seriously fast computers: if you want to move fast, you have to go pretty much in a straight line. Any situation where a departure from sequential flow might occur, *and where it has to occur in a predictable way*, incurs major complexity and potentially serious delays to make sure everything is synchronized just in case. Folks interested in such things should read "Putting UNIX on Very Fast Computers", by Mike O'Dell, in the Proceedings of the Summer 1990 USENIX Conference. Mike was Chief Computer Scientist at now-defunct Prisma, which was trying to build a Cray-class SPARC. (USENIX can be reached, e.g. about availability of proceedings, at office@usenix.org.) Henry Spencer
Please report problems with the web pages to the maintainer