Subject: RISKS DIGEST 15.07 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 6 October 1993 Volume 15 : Issue 07 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: ISDN telephone glitch in Hamburg (Klaus Brunnstein) Japan: IT Security, JCSEC criteria (Klaus Brunnstein) Re: The FBI investigating college pranks (Fredrick B. Cohen) Re: Conditioning and human interfaces (Robert Dorsett) Re: Answers to the mail problem (Fredrick B. Cohen) Trusted portions (Fredrick B. Cohen) Think of it as an opportunity, not a problem (A. Padgett Peterson) Re: Risks of Unverified Driving Records (Robert J Woodhead, Jim Cook, Rex Black) CFP "Ethics" Workshop Cuba Feb.1994 (Klaus Brunnstein) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. There are also alternative repositories, such as bitftp@pucc.Princeton.EDU . If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 17 Sep 1993 14:07:38 +0200 From: Klaus Brunnstein Subject: ISDN telephone glitch in Hamburg On September 16, 1993, about 12,000 Hamburg based customers of Germany's new ISDN digital telephone system were hit by a software bug from which telephone services could be recovered only after almost 12 hours. Mainly commercial users (about 25% of Hamburg's presently 50,000 ISDN customers) were unable to use their telephone, fax and data services until after noon. According to a German Telecom official, the problem arose when a new software was loaded on the ISDN control systems, at 2:00 am. Probably due to a bug, systems crashed and subsequently also refused to load the old software. Only at 1:15 pm, system engineers succeeded to restart the old system version. ISDN is the Integrated Services Digital Network, which allows to transmit all sorts of communication (fax, telex, texts, data, telephone calls) via a digitized network with one type of connector box. At this time, out of 1,2 Mio telephone customers, 50,000 have yet ISDN based system, including the author's faculty, with daily bad experiences about broken calls, false connections, devices beeping for no rationale reason etc. Fortunately, the author's telephone set was operating in the "usual" way during this blackout. Klaus Brunnstein (Uni-Hamburg, September 17, 1993) [By the way, someone PLEASE tell Klaus that his mail addresses --- both d400 and dbp --- no longer work from my system! Something broke. PGN] ------------------------------ Date: Thu, 16 Sep 1993 19:54:42 +0200 From: Klaus Brunnstein Subject: Japan: IT Security, JCSEC criteria It is not well recognized in the current discussions in North America and Europe aimed at harmonizing their different criteria (FC, ITSEC) that Japanese organisations are undertaking major efforts to assess and improve the state of IT and Communications security also in their country. In order to guarantee their IT industries' opportunities in international markets, they are also looking for a minimum harmonized set of criteria (JCSEC) as a basis of universally applicable product evaluation and certification. Among others, Information-technology Promoting Agency (IPA) and Japan Electronic Industry Development Association (JEIDA) have started their respective work with major analyses of the state-of-security in Japan, North America, Europe and Australia. IPA, a MITI funded organisation with interests in AntiVirus measures, sponsored a study which received some attention in 1992. Its basic statement was that the number of hacker-like attacks on systems doubled in recent times while virus infections diminished significantly. It is interesting that IPA's recent statistics about viral events in Japan sharply increased in 1993: from 1990's total 14 events over 1991's total 57 events and 1992's 252 events, the partial figures in 1993 (Jan-July) are 366. While findings in Mac (less than 10 reports) and so far 19 viruses having appeared on the (IBM-incompatible) Japanese PCs (15 reports in 1993) are constant, the very fast growth of IBM compatible PCs is based on 42 different viruses, with 166 Yankee Doodle, 103 Cascade 1701/1704, 24 Anti-Telefonica, 20 Stoned III or Michelangelo and 14 Form reports in 1993. Though IPA's request for reporting virus events is now known in many enterprises, these figures do NOT indicate the exact number of infections but only show the relative development: growth. As its basis for future work, JEIDA has published a "Summary Report on the Worldwide Survey for Information Systems Security in Nine Nations", conducted by Coopers & Lybrand, in March 1993. The survey which is based on 1,059 questionnaires filled from enterprises in Japan (39%), Australia (21%), North America (15%) and Europe (13%) analyses the state of security consciousness (chapter 1), experience with incidents (ch.2: e.g. malfunction of hardware>75%, introduction of viruses >30%, theft of equipment about 10%, disclosure of Passwords: 10%, etc), and IS Security Measures taken (a rather detailed analysis, ch. 3). An analysis of the Cost of IS Security Measures (ch. 4) and IS Risk Analysis (ch. 5), Motivating Factors (ch. 6) and Development Priorities (ch. 7) concludes this study (17 pages). For detailed analysis, it would be helpful to complement the hi-quality color print with a volume containing more details of the raw data, but this "JEIDA Study" is worthwhile to read for worldwide comparison. JEIDA published another study in August 1992 "Japanese Computer Security Evaluation Criteria: Functional Requirements (Draft V1.0)" which has not been recognised so far in the Western discussion (similar to Russia's development, published in December 1992, though in Russian). JEIDA's study (in English), developed after MITI guidelines, describes (ch.1: Introduction) Functionality Requirements, with scope of the "Target of Evaluation" (TOE) and Target Models, and gives detailed "Functional Requirements" (ch.2), including minimum requirements for Identification and Authentication (2.1), Access Control (2.2), Accountability (2.3), Auditing (2.4), Object Reuse (2.5), Integrity (2.6), Reliability of Service (2.7) and Data Exchange (2.8). Though the structure conforms with ITSEC concerning the 8 basic function categories, JCSEC evidently follows US' Minimal System Function Requirements philosophy which is also basic to ECMA's (European Computer Manufacturers Association) and ISO/IEC JTC1 SC 27 works. The report (26 pages) ends with a graph describing the different security criteria in USA, Europe, Japan and ISO, followed by a glossary with informal definitions of essential terms. Though the Assurance part of JCSEC has not been published so far (due end-of-1993), it seems as if ITSEC's Assurance levels may play the role of related "Minimum Assurance Requirements" (rather than the complex Assurance descriptions in US' Federal Criteria). JEIDA officials motivated their work in JCSEC generally with their vendors' experience when having attempted to sell Japanese IT systems in Australia. Following regulations for Australian government installations, which seem also to be applied by major Aussie enterprises, Japanese installations had to undergo a security evaluation process which was partly difficult as most documents were not available in English. When being forced to prepare evaluation and certification of their products in non-Japanese countries, MITI and Japanese vendors evidently concluded that a set of internationally harmonized criteria with minimum requirements would serve their interests best. Moreover, Japanese vendors seem to favour self-evaluation of security functions, as opposed to an evaluation by independent institutions as practiced or prepared in USA and Europe. As some of these ideas are shared also by IT vendors outside Japan (see ECMA's approach), the Japanese involvement may add fresh wind to the international ITSEC discussion which is presently dominated by USA/Canada and Europe (including their preoccupations :-) Klaus Brunnstein (Univ-Hamburg, September 16, 1993) PS: JEIDA's address is: Japan Electronic Industry Development Association, JEIDA, Kikai-Shinko-Bldg., 3-5-8 Shiba-Koen, Minato-ku, Tokyo 105 JAPAN. ------------------------------ Date: Wed, 6 Oct 93 05:00:48 PDT From: Fredrick B. Cohen Subject: Re: The FBI investigating college pranks It's a sad state of affairs when the FBI investigates a college prank but doesn't investigate murder and rape running rampant through the nation. When I was in college, students sent a resignation letter from the Dean of Students to the President on official letterhead. There was no federal investigation, and the most any student would ever get for such a prank would be a stern lecture about being sociable. If they investigated half the pranks the FBI would be forever chasing kids around our college campuses. Lets keep some perspective on things and spend our federal time and money on something more useful. - How about a study of how many times a butterfly flaps its wings before it dies? FC ------------------------------ Date: Wed, 6 Oct 93 19:57:09 CDT From: Robert Dorsett Subject: Re: Conditioning and human interfaces (Sosman, RISKS-15.06) > ... Mr. Dorsett's point (perhaps) should be that there ought to be a > Standard Standard... But are today's interfaces so good that we're > willing to discourage innovation? There's no innovation in these approaches. They are all on the same cognitive level, using similar display and input mechanisms. They are merely different permutations of a theme, often guided by no "philosophy," just GUI extensions of old-fashioned CLI-style prompts. So, in this case, yes, there is only one credible type of solution, and, yes, especially when PC's are trying desperately to turn into Macintoshes, and when huge segments of society are used to standard keyboard formats, some standard heuristics should apply, one way or the other. Robert Dorsett rdd@cactus.org ...cs.utexas.edu!cactus.org!rdd ------------------------------ Date: Wed, 6 Oct 93 10:02:47 PDT From: Fredrick B. Cohen Subject: Answers to the mail problem Three answers came up that I thought might be worth sharing: 1 - Some versions of sendmail have a capability to refuse mail after disk space is reduced to a specified constant. This resolves the flooding problem but does not allow legitimate mail to pass. 2 - Some people think you should have a separate disk partition for mail and News (where this apparently happened regularly to some people by accident), which solves the problem except of course it denies legitimate mail. 3 - Some systems allow user-based quotas under which mail falls, but in many systems this doesn't work because the superuser delivers the mail, and thus the legitimate user is run out of space while the system is also run out of space. Some people mentioned that they hadn't tried limiting quotas to all system user but that it would be necessary to limit the impact of this problem. Most respondents said that they felt this was a fairly common state of affairs. In other words, as delivered, systems don't handle this well, and most systems administrators don't know how to, aren't aware of, don't have the time to, or for whatever reason don't do anything about this problem. I wonder how many things besides mail and news create this possibility. Does anyone know of any other information sent to a system that automatically (by default) consumes disk space? It would be worthwhile to classify these things and keep them in a common place so we know that a particular partition has them all, and know where to look. P.S. I make one partition per disk to get rid of the stupidity of having to keep things in different directory structures just because my computer isn't smart enough to figure it all out. It only hurts under a few circumstances, and it makes life easier in a lot more of them. We received a large amount of mail on this topic, including that from sater@cs.vu.nl (Hans van Staveren) rogerb@x.co.uk (Roger Binns) mathew@mantis.co.uk (mathew) andyc@cappsdv2.fob.ford.com wfg!mdavis@uunet.uu.net (Michael T Davis) taylort@dg-rtp.dg.com (Tad Taylor) . Several suggested that THEIR mailers are not so stupid, and suggested various well-known ways of handling the problem. Thanks. PGN] ------------------------------ Date: Wed, 6 Oct 93 10:02:47 PDT From: Fredrick B. Cohen Subject: Trusted portions Trusted portion should be small, but then there is the problem of the interface between the trusted and untrusted portions of the program. One way to deal with this is via a cryptographic interface between authorized and unauthorized portions of programs. Another alternative is to have the trusted program verify the integrity of the untrusted program. Just a thought. - FC P.S. I have had a small trusted program for separating trusted from untrusted segments of programs for quite some time, and it works well, but it's not all that easy to use correctly. - FC ------------------------------ Date: Wed, 6 Oct 93 08:25:04 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Think of it as an opportunity, not a problem (Re: Willey, RISKS-15.06) [Was: Software Quality vs Staff Size] "The customer is always right". One approach that was inspired by several other RISKS entries would be to split the group into 2 or 3 teams and give each one the same requirements. When each is done feed the same test cases in and see what the results are. Once they always agree, pick the best/ fastest/most elegant one & deliver. Once upon a time, "safety of flight" dictated IV&V (independent verification and validation) of all software. IMHO many of the RISKS postings have indicated that even simple quality control is a thing of the past. Two years ago my wife was in an automobile accident that required removal of the battery from our car. Yesterday I had occasion to disconnect the battery & discovered that Godzilla must have replaced it, probably with an impact wrench. The terminals were screwed on so tight that the attachment post ripped out of the battery before loosening, causing an acid leak (yes, I was turning it the right way 8*(, and ruining the battery. Latent software errors are like that, sometimes taking years to show up, and are caused much the same way -- someone operating without supervision and outside their field of expertise. In my experience with programming, (and that goes back longer than I would care to admit) very few "programmers" really understand the systems they are working on -- certainly very few people worldwide understand the BIOS in a PC yet this is what makes a PC "100% compatible". There are over 150,000,000 PCs worldwide now, probably less than 500 people who have any understanding of the BIOS (and half of them write viruses). Yet what would one expect the architecture for that medical device mentioned in to be ? Would anyone be surprised if there was an Intel iapx 80x86 based system inside ? Maybe it is time for certification, at least for devices that are safety related. Padgett ------------------------------ Date: Wed, 6 Oct 93 20:52:57 JST From: Robert J Woodhead Subject: Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06) In RISKS-15.06, Mich Kabay writes about the Risks of unverified driving records, and the problems of an erroneous record leaving one stranded at the airport sans auto. There is a simple solution that avoids most of the problems; the Car rental companies should be allowed to refuse to accept a reservation, but not cancel one once it has been made. Thus, the client would be asked when he phoned for the reservation for his driver's license number. This would have the side-effect of giving the driver an early warning that there is a problem with his record (either a real problem with his driving, or someone elses typing problem) Robert J. Woodhead, Biar Games / AnimEigo, Incs. trebor@forEtune.co.jp AnimEigo US Office Email (for general questions): 72447.37@compuserve.com ------------------------------ Date: Wed, 6 Oct 93 11:20:38 EDT From: jcook@epoch.com (Jim Cook) Subject: Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06) In commenting on shared driving records, Michel E. Kabay comments: "It will not be good enough to allow just anyone to make ostensible corrections in our records, either. Some method of identification and authentication will have to be devised to prevent nasty people from damaging other people's histories." I really have to comment on this: Suppose you suddenly find yourself with a bad record one day. It only took one person a few minutes to accidentally or deliberately make this erroneous error one day. What level of authorization did that person have? Frequently, very little. Now you want to correct it. What level of authorization do you need? Frequently, you probably have to go through heck and high water to do so. And consider the time factor: the entry was made in a minute. The correction takes weeks. Think about credit records. This has all come up before. And there you often are not allowed to expunge the record, rather, just add a correction below (if at all). I understand Michel's sentiment to prevent wrong-doing. But from everything I read, it's the legitimate that have been losing out. C. James Cook, Epoch Systems, Inc., 8 Technology Drive, Westboro, MA 01581 508-836-4711x385 JCook@Epoch.com ------------------------------ Date: Wed, 6 Oct 93 10:09:45 CDT From: rex@iquery.iqsc.com (Rex Black) Subject: Re: Risks of Unverified Driving Records (Kabay, RISKS 15.06) I think Mich's suggestions are excellent. Certainly the subject should have the right to verify information which directly affects his quality of life. However, I don't think this will entirely resolve the problem, because it doesn't cover some crucial economic issues. Most data collection agencies are for-profit corporations. While they have an interest in selling reasonably accurate data to their clients, their clients value the data most from the point of view of _preventing_ a business decision that results in a major loss. In the car rental example given, the rental agency looks for background data that proves "badness". The risks for both purchasers of the data and the data subjects arise when the purchaser of the data is attempting to use the information to exclude a bad-risk subject. However, note that, while the data purchaser bets a possibly substantial amount of money that the data will identify bad risks, and the subject bets substantial inconvenience and possibly money that the data will not incorrectly finger him/her as a bad risk, the data provider risks virtually nothing in any transaction. I say "virtually" because, if the agency fails to identify bad risks often enough, the data purchaser may choose another data provider. However, the agency may misidentify good risks as a bad ones a number of times without consequence to it, and it is unlikely that the injured party in this circumstance (the subject) will convince the data purchaser to dump the data provider on the basis of his injury. So, we have a situation wherein the data collection agency risks less by keeping negative data on subjects, even if it is questionable, than it does by eliminating negative data. This fact, combined with the relative financial positions of the data collection agency and the data purchaser versus the data subject, puts the subject (i.e., us) at a significant disadvantage. As far as I can see, the only remedy to this aspect of the problem lies in making the data collection agency itself directly liable for all injuries to the data subject arising from errors in its data. If our hypothetical traveller is denied a car and must take a $1,000 round-trip cab ride to Bumbaloosa, east Washington to make his business meeting, then WRT Data Services should legally owe him $1,000 (plus court costs if necessary) for the incident. Additionally, they should be liable for punitive damages if the same erroneous data causes a similar (or worse) injury at a later data. The first liability gives them an incentive to correct the error, and the second liability gives them an even stronger incentive to prevent the error from recurring. While I hate to advocate legislation that will increase litigation, the unfortunate fact is that, without laws and lawyers to level the playing field, those of us on whom others keep and sell data will remain permanently at risk from bad data. It is in our interest to push for such legislation now, before the data collection agencies become immovable by the Congress (c.f., the insurance companies). Rex ------------------------------ Date: Mon, 13 Sep 1993 17:31:54 +0200 From: Klaus Brunnstein Subject: CFP "Ethics" Workshop Cuba Feb.1994 CALL FOR CONTRIBUTIONS for an IFIP WG 9.1 Workshop, from Ina Wagner ETHICS AND SYSTEMS DESIGN: THE POLITICS OF SOCIAL RESPONSIBILITY Havana, Cuba, February 17-19, 1994 IFIP has been for some time analyzing the possibility of developing its own Code of Ethics. Working Group 9.1 Computers and Work is planning to contribute to the discussion on political and ethical problems in systems design, beginning with a small workshop. The main focus of this workshop will be * to discuss grounded scenarios which can provide rich knowledge of the political and ethical problems encountered in a variety of contexts, * to analyze the relationships between ethics and the politics of work in these contexts (including the work environment of systems designers), * to develop practical guidelines that help the professional community of systems designers to identify political and ethical dilemmas and to respond to them. THEMES OF THE WORKSHOP Ethics and the Politics of Systems Design: We think of ethical problems as emerging wherever the values and moral principles on which individuals base their decisions and actions are contested or in conflict. Such conflicts between people's values, norms of conduct and claims for moral ground often point to basic underlying differences between their positions in the organization or in a society, their interests, and, consequently, their assessment of certain situations. In that respect, ethical problems have a strong political content. Real life situations are often characterized by ethical dilemmas involving the co-existence of conflicting or competing values. The ethical problems that emerge in a field are shaped by its conditions and contexts, as are the conflicts that arise between different ethical principles, their different perception and evaluation by different actors in the field, and the solutions that participants look for and finally come to accept. Although high standards of individual responsibility (as represented in an ethical code) are indispensable, these need organizational support in order to unfold and develop. Consequently, the politics of systems design itself need to be a primary focus of all deliberations on professional ethics. Questions of personal morality stand a chance of becoming significant guidelines for action only if the systemic"questions are openly discussed. Among these are the work practices and working conditions of systems designers -- management and development practices as well as the paradigms within which systems designers are working. Learning from ethical scenarios: Ethical scenarios should be grounded in the analysis, development and use of information technology in different contexts. We think that rich descriptions of actual conflicts and of how participants cope with them might sharpen systems designers' awareness of ethical problems in general, support their analytical understanding and help them enter a dialogue with others in the field. As WG9.1 we are particularly interested in exploring the relationships between ethics and the politics of work. Making ethical principles practicable: Generalized "ethical codes" have the advantage that they can act as some basis for a minimal social standard to be taken into account in systems design. They oblige systems designers consciously to connect their technical analysis of a problem with a moral-practical judgement. Two requirements for such general ethical principles are: * Their formulation should make clear the consequences of an adequate, responsible attitude for the relationships between all participants in a design effort. * They should clearly express the difference and tension between the obligation to observe professional norms on one hand and to depart from these norms if other principles or the situation make this necessary". We look for suggestions on how such codes could be developed and made understood and practicable. Institutional frameworks for social responsibility: One particularly difficult task is to set up an institutional framework for implementing an ethical code and to define the legitimate actors in such a framework. Analysis of the composition of ethical committees in the medical area, for example, has brought forward the problems involved in deciding whether some people are more "affected" or more worthy of participation in decision making than others because of their education, social background, specific merits for society or their minority position. Experiments with citizen participation in communal projects often use drawing lots among the general constituency instead of elective procedures. Another question is whether members of such an institutional framework should be representative of particular groups. It could for example be argued that otherwise underrepresented actors should be over represented. This could be justified in a number of ways: A critical mass of members from that group may be necessary to give weight to their perspective; there should be sufficient room for the particular values and interests of this group to be heard. We look for contributions that deal with these issues on a theoretical and practical-empirical level (discussing cases, practices). OUTLINE OF THE WORKSHOP Participants are invited to submit either: a) Ethical scenarios from different types of work organization (from hospitals to industrial sites) and different cultures (including developing countries) which are suitable for an in-depth discussion. An ethical scenario should * be informed by a real case (or cases), * include some temporal/historical/developmental account, * describe ethical/political conflict in relation to the working conditions and professional culture of the different communities of practice involved in the case. or b) a Position Paper which deals with one (or several) of the leading issues of the workshop. Short versions (2-4 pages) should be submitted to: Ina Wagner, Vienna Technical University, Center for CSCW Argentinierstrasse 8, A-1040 Vienna, Austria Tel: +43 1 58801 4439 Fax: +43 1 5042478 Email: iwagner@email.tuwien.ac.at They will be reviewed by the members of the Programme Committee. OUTCOMES OF THE WORKSHOP One main result of this workshop will be a position paper for the Reader on Ethics and Computing edited by Jacques Berleur, Chair of the IFIP Ethics Task Group. An additional possibility is to revise and expand some of the contributions for publication in an international refereed journal. KEY DATES November 1, 1993 Deadline for submission of short version December 1, 1993 Notification of Acceptance Given the short preparation time, authors are not expected to send in full papers before the conference. However, once accepted they will be given instructions on how to prepare their contribution for the conference itself. PRACTICAL INFORMATION This conference will be connected to the WG9.4 Conference "The Impact of Informatics on Society: Key Issue for Developing Countries" (from February 21-23 also in Havana). If you are interested in participating in this event as well, please contact: Prof. Sam Lanfranco Centre for Research on Latin America and the Caribbean (CERLAC) York University (Room 240YL) 4700 Keele Street, North York Ontario, Canada, M3J 1P3 phone: (416) 736-5237 fax: (416) 736-5737 email: lanfran@vm1.yorku.ca Information on the conference site and accommodation will follow. Cuban Airlines as well as Iberia offer moderately priced flight & accommodation arrangements. We will inform you about the possibilities in time. WORKSHOP FEE As we have no funding for this conference, we would appreciate participants to contribute a registration fee (beyond expenses). Full registration fee: US$ 200 Reduced registration fee: US$ 100 PROGRAMME COMMITTEE Andrew Clement (University of Toronto), Vice Chair WG9.1 Mike Robinson (University of Aarhus) Lucy Suchman (Xerox Park, Palo Alto) Ina Wagner (Vienna Technical University), Chair WG9.1 ------------------------------ End of RISKS-FORUM Digest 15.07 ************************