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…
An unusual kind of Internet chess game will be held next week in Finland, sponsored by Telecom Finland. Anatoly Karpov will be pitted against the consensus of a collection of on-line participants, estimated to be around 50,000 in number, where after each of Karpov's moves the wannabes get 10 minutes of real time to think, and a Telecom computer will pick the most popular move. Check out http://www.tele.fi/karpov for details. What are the risks? 1. What if 100,000 opponents show up and overwhelm the website? 2. Will a dumbed-down consensus result? Can a few master-level players have any impact over a horde of average players? 3. How can any coherent strategy emerge from such a consensus strategy? 4. Could the resulting somewhat randomized strategy actually be more effective than a more coherent strategy? (Garry Kasparov had an interesting time figuring out IBM's Deep Blue strategy, and beat it with a less coherent approach than he might normally have taken. See RISKS-17.79.) 5. Could Kasparov hack his way into tele.fi and reprogram the software so that only HIS move was tabulated? Certainly the organizers could do that, but it would spoil the fun. 6. Could Karpov use a Finnish anonymizer and then, if he lost, repudiate the results by claiming it was really Kasparov who was playing?
I received a press call this morning asking about Social Security Numbers and database privacy in general, from a journalist covering a story that should have happened years ago. A US Congressman running for Governor of New Hampshire was found to have two SSNs by local journalists, who ran a story on it. (It's illegal to obtain 2 SSNs in most circumstances, so one supposes this seemed newsworthy). After the story ran, it turned out that the other SSN belonged to a teenager, and that the legislator had been assigned the number (presumably in some marketing or DMV or other error-prone database) by mistake. Despite the situation not being the legislator's fault, his chances for election to the Governor post have been damaged by the bad reportage, possibly ruined. At this point, I don't have the name of the legislator, nor of the paper and journalist(s) who reported on this. Many obvious RISKs that have come up before plenty of times in RISKS: 1) SSNs are not a good system - they are neither truly unique identifiers, nor is the system even close to immune from errors or fraud. 2) Even "minor" data entry errors in databases of personally identifiable information can ruin careers and otherwise wreck people's lives, but there's not really any easy way to detect these errors or to fix them until they cause a personal, or sometimes far broader, catastrophe. 3) There is no real accountability, even aside from privacy issues. State laws are scattershot and disparate, affording little privacy protection and even less recourse when negligence wreaks havoc. They are so different from state to state that even an industry-generated code of conduct doesn't arise. At the federal level, it's even worse. 4) Reporting on technical topics, like information held in databases, can be rapidly screwed up if the reporters do not take care to get the facts, but simply report what seems obvious on the surface. (C.f. Time's "Cyberporn" cover story for another infamous example.) 5) Blind trust in technology - "the computer is always right" - can lead to quite harmful mistakes. It appears that the reporters who jumped on this story accepted it as a given that the legislator had obtained two SSNs for some nefarious purpose, and missed the far more likely possibility: data entry error by a third party. [This is based on what I've been told about these events and the reportage of them. I have yet to see the original articles, though I expect to get them shortly. So, some of this criticism is best considered hypothetical, until I do have the articles. I cannot, of course, be certain of the accuracy of the characterization by one journalist of another and his/her work.] As for why I say this should have happened a long time ago, this is the first time I've heard of something like this happening to a policymaker. Hopefully the nature of the problem will sink in and we'll see some action to establish accountability and privacy-protection requirements. At very least, the dismal failure of the SSN may become more apparent to Congress, who have simply not appeared to grasp the nature of the problems to date. The new crypto-awareness on the Hill could use a strong booster shot of general privacy awareness. Stanton McCandlish Electronic Frontier Foundation mech@eff.org "http://www.eff.org/~mech/" [This saga is quite skimpy, but is the best available at the moment. I hope someone can fill in the details for us. PGN]
[Via Dave Farber <farber@central.cis.upenn.edu>] >From: Timothy Barmann <tim@cybertalk.com> Subject: Warning from Family Circle Magazine Got this amusing/disturbing press release from *Family Circle Magazine*, apparently to promote an upcoming article. It reads: >CERTAIN COMPUTER FILE LETTERS INDICATE PORNOGRAPHY: POLICE CHIEF > >New York — Parents can safeguard their children against pornography on >the internet by watching for files stored on a computer's hard drive or >diskettes that end in the letters -PCX, -GIF, -GL, TIF, or -JPG, according >to the current (September 17) issue of Family Circle. "Those are the >graphic image files that may be pornographic, and parents should know what >they illustrate," says Police Chief Alfred Olsen, who monitors online >predators in Pennsylvania. I'm surprise that TXT was left out, which of course is the format used to distribute sexually explicit words as well. Timothy Barmann, *Providence Journal-Bulletin* tim@cybertalk.com 401-277-7369 http://www.ids.net/~tim/ http://www.ids.net/cybertalk/
Two items from the recent news: 1) The August 7th edition of the WSJ has a front page story on the divorce of cellular phone king, Craig McCaw. Here's the salient phrase, "... Mr. McCaw says in an interview via a wire-line phone to which he entrusts all sensitive conversations because he is leery of eavesdropping on his cellular calls." Given that the call was at least partly on the record, I wonder how he handles his truly sensitive calls. 2) The August 20th edition of the NYT describes the effects of the recent settlement between NASDAQ and the SEC. The NASDAQ marketplace is essentially a computer network that links a group of dealers who use the system to make announcements like "I want to buy Microsoft for 92 dollars/share." A brokerage firm will often make a profit on the difference and not pass it on to their customers. If someone breaks the spread, all of the brokers suffer but the customers generally gain a small advantage. The SEC now has audio tapes of some dealers using collusion and social pressure to keep the spreads up between the price the shares are offered to buy and sell. There is also another market ran by Reuters known as "Instinet" and it is anonymous. No one knows who is offering to buy and sell shares. If someone breaks from the pack and starts offering slightly more money for a particular issue, there is no easy way for the dealers to retaliate. It's all anonymous. The article suggests that prices are often fairer for the people who use Instinet. Of course it is only open to big folks like institutional investors. Presumably it is not truly anonymous and the SEC could unwind the trades if it wanted to investigate, say, insider trading.
>We have discovered a security flaw in the current version (3.0) of >Microsoft's Internet Explorer browser running under Windows 95. An >attacker could exploit the flaw to run any DOS command on the machine >of an Explorer user who visits the attacker's page. We now post the virus warning dialog on local files (file: urls). We have always posted it on remote files (http: urls). Note that the root of the problem is not Java or the browser, but in macro-enabled applications. IE3 has a mechanism to warn users about safety of documents when used with common macro-enabled applications. We are have updated Microsoft Word such that by default it will not run macros embedded in documents. -Thomas
People can't tinker with software either these days ... for example, there is no programming language supplied with Windows 95. >From this, a RISK is that a program of any degree of triviality may be seen by a lay person as miraculous. I wrote a Word for Windows macro to generate chess board positions out of sheer necessity - I needed pictures for a magazine article I was writing and no software I had could generate them easily. I then realised that my macro might be useful to other people. So I uploaded it to an archive site - and the response was phenomenal, with emails coming in by the dozen praising what I have done. Yet the macro is made up of about fifty lines of code, there are no devious tricks and the algorithm used to generate the chess board from user input is relatively simple. I am a software engineer; if I was incapable of writing such a macro I would wonder whether I was fit to be called a software engineer. Who was it who wrote that "any sufficiently advanced technology is indistinguishable from magic"? They are right, and they are becoming more than right. Alastair Scott <scotta@logica.com>
Frank Ferguson <ferguson@dmapub.dma.org> notes in RISKS DIGEST 18.36 that the U.S. Department Of Energy has signed a US$94M deal with IBM to develop a new supercomputer designed specifically to simulate nuclear explosions. Frank's conclusions, however, don't follow. The U.S. DOE is almost certainly the worlds' largest consumer of high-speed computers used for simulation, and has in fact been instrumental in the funding and development of these computers. Richard Rhodes' books on the development and construction of the first A and H bombs makes this abundantly clear, as do many other books on the subject, and others on other subjects (e.g., Richard Feynman's book that mentions his activities during WWII). Many U.S. DOE atomic labs already have large supercomputer centers devoted to simulation. While the purpose of the computers is to simulate nuclear events, their intended purpose is not generally to eliminate all nuclear tests. The computer codes are worth discussion. They are, as a former chairman of CDC noted in a speech many years ago, the human race's best understanding of nuclear events. As a result, these codes are highly classified. A great many complex, coupled, and inter-related phenomena occur during an explosion. Among them are radiative, particle, and shock phenomena. The need for models of these phenomena was probably first determined by Hans Bethe, several years before the first A bomb explosion, and it was also he who first developed the idea of Monte Carlo (probabalistic) simulation. While the physics of each individual aspect of a detonation is well understood, their coupling is very complex. E.g., radiative opacity is determined in part by temperature, which is affected by radiative and particle absorption. Many of the constants affecting these phenomena and their couplings cannot be determined accurately by a priori computation, and must be measured or approximated. As a result, the computer models are the only way, other than actually detonating a device, of accurately estimating the yield and efficiency of a new design. In complementary fashion, the only way of reliably improving the accuracy of the simulation codes is fashioning devices and measurement equipment and testing them. This is in fact done. Indeed, I have been given to understand by several knowledgeable people that the purpose of nuclear tests is most often to verify improvements to the computer models. It is a deep-rooted need of humans to understand the universe. The codes modeling the detonation of nuclear devices would appear to be monuments to this (cold-war fear, too, I imagine). The rapid development of the neutron bomb (er, "enhanced radiation device") would appear to be a testament to the reliability and accuracy of these codes. Certainly, the current efficiency of nuclear devices is such that extinction of the human race can be safely assured, if such a goal is considered desirable. It becomes perhaps questionable, then, what additional sophistication in the simulation and design of nuclear devices is intended to accomplish, beyond satisfying this curiosity. The risk is slight that the U.S. will design, build, and deploy nuclear devices that fail to work due to failures of the computer models. Fear that physical/computer models might not be reliable was definitely responsible for tests of cruder-than-necessary bombs (e.g., the USSR's first A and H bombs, and several early U.S. devices (see Rhodes' books)). The risk seems many orders of magnitude greater that, due to test bans, the U.S. will spend large sums of money simulating and designing nuclear devices that it cannot test, manufacture, or deploy. In the absence of test ban treaties, the risk is that the U.S. will detonate additional devices to verify the more complex models that the faster computers will allow (highly probable). Robert Herndon
In RISKS-18.36 Frank C. Ferguson <ferguson@dmapub.dma.org> takes some issue with the idea of relying on computers to design nuclear weapons. He writes in part: >I guess eliminating an actual explosion, or "rapid disassembly" as the Air >Force labels it, would reduce a lot of risks, wouldn't it? Hmmmm. > >I suspect we would soon be building weapons that would never work when the >real trigger was actually squeezed. Computers are useful for many simulations related to nuclear weapons other than designing clever little devices that rapidly disassemble in spectacular ways. A few examples are: a. predicting the destructiveness of a particular device with known characteristics (determined by testing) when used in a particular area. b. predicting the fallout in various geographic areas and weather conditions. c. finding out what happens if a device is accidentally smashed, eg. is unintentionally dropped from a plane (this has happened many times!), does it blow up or is the bomb stuff contained? d. performing fusion energy experiments prior to building the apparatus. e. refining existing designs and exploring completely new concepts. Many tasks involve taking known weapons and exploring their behavior in situations where real testing is impossible. Even if the US stopped all weapons design, there would have to be a lot of simulation just to explore the capabilities, limitations, and safety related issues of the current stockpile. Some WWW references to IBM's and Intel's new machines and their applications are: http://www.austin.ibm.com/Cover/Announce.960726/doepress.html http://www.ssd.intel.com:80/tflop.html It should be noted that weapons work is just a part of what's planned for these next generation supercomputers. Mark Stalzer, mas@acm.org [Other comments on this topic also received from "Christopher Duro" <cduro@softkey.com> nelson@berlioz.nsc.com (Taed Nelson) Jerry Bakin <bakin@haas.berkeley.edu>. PGN]
I recently pointed out how the plot of the movie _The Running Man_ was the same as a something suggested here in RISKS. So I cannot avoid mentioning: <> to use the new computer ... to determine which country wins a war without <> actually fighting the war. The original Star Trek episode "A Taste of Armaggedon" was based on exactly this premise. There is nothing new under the sun... Barry [Noted in greater detail by "Jonathan I. Kamens" <jik@cam.ov.com>. PGN]
[In response to Jonathan Kamens noting Star Trek was 30 years ago.] Actually I think the ancient Chinese were the first. They simply assembled opposing armies on opposite hilltops while the intermediaries met in the valley. They decided which army was most likely to win and then they all returned home. Frank Ferguson
Further to David Holland's comments... Here (at Siemens Nixdorf Informationssysteme) incoming bug-reports are classified 1 through 4 in severity level as perceived by the user. They are also classified according the department responsible for the code (1 through N). For each of these 4*N classes we have the historical statistical distributions of (inter alia) bug fix times and bug densities as well as improvement trends (and some other correlations ;-) Inasmuch as one is able to predict the future statistically from the past, we are able to say something like "There is a (50/90/99%) chance that this bug will be fixed within time T". I don't think you can do much better than this in the long run. I tried training a neural net last year, but the prediction accuracy doesn't seem to be much better (usual statistical test). Dr. Stuart Savory Dept. of Quality & Customer Satisfaction.
We have had a request from a client to rerun the training course on how to start a system we delivered to them. It hasn't stopped for 18 months and they have lost confidence that they can restart it if they need to do so. So, it isn't only systems that get patched and warm-booted that lose the ability to be cold-booted. Is this a risk arising from delivering high-quality software? Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-1225-444700. Email: mct@praxis.co.uk Fax: +44-1225-465205
Call for Participation - Software Engineering Institute (SEI) Conference on Risk Management: Managing Uncertainty in a Changing World Hotel Cavalier, Virginia Beach, Virginia, April 7-9, 1997 Keywords: acquisition, programs, projects, systems, and software Note: this is an abbreviated call for participation [and excerpted for RISKS]. For complete information, please see http://www.sei.cmu.edu/products/risk97 The SEI Conference on Risk Management will provide a forum that brings together representatives of government, industry, and academic managers. Practitioners, change agents, and researchers who use and explore risk management, system development and acquisition will detail the latest methods, tools, and techniques in the field. This conference will provide a unique opportunity to * Increase your awareness * Advance your knowledge and skills * Exchange ideas and experiences with experts * Learn the latest methods, tools, and techniques and best practices of acquisition, systems development, and risk management * Find out what's new, what's going on, and what could be useful for you September 19, 1996: deadline for submitting papers and workshop proposals For more information about the conference, contact-- SEI Customer Relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone 412 / 268-5800 FAX 412 / 268-5758 Email customer-relations@sei.cmu.edu World Wide Web http://www.sei.cmu.edu
Please report problems with the web pages to the maintainer