In the New York Times, Sept 4th, there was a blurb titled "Fax Machines Are Getting a Voice". The article describes a product (from Malibu Software Group) that OCRs incoming FAXes and then converts them to speech. So one dictates a message to someone who enters it into a Word Processor and then prints it on paper, sends it as a FAX, it gets scanned into a computer, OCRed and then converts it (or something loosely related to the original) to speech. Computers are wonderful, they allow one to keep layering technology on top of technology. Actually this is nothing new, bureaucracies have been using this kind of approach for many years. There are many risks associated with situations in which the original rationale is lost as layers get added. Technology increases the opportunities and adds new elements of mystery and credibility to these kludges.
On page 1 of the View section of today's (Wednesday, September 4, 1991) LA Times there is an interesting article written by Amy Kuebelbeck entitled: G e t t i n g t h e M e s s a g e E-mail is fast and efficient. But it isn't always private — and that can mean big trouble for users. The article describes the growing use of E-mail in American business and describes how it is raising sobering questions about workplace privacy vs. accountability. It describes the risks of accidentally sending E-mail to the wrong person or to a huge list of people. It quotes several authors and professors. Some important advice was o Be careful about expressing emotion o Assume messages are forever The article describes the lawsuits pending against Epson America and Nissan Motor Corp. USA. There is an interesting section on the LAPD's use of E-mail where the Christopher Commision, investigating the Rodney King beating, deemed about 700 messages improper apparently sexist or racist. Interesting reading considering it was written for the people who have probably never used E-mail. Mike Kimura, Hughes Aircraft Company, firstname.lastname@example.org
In RISKS-12.22, David Parnas writes about the electronic mail problems one incurs when changing jobs. I ran into the problem myself when I left my former employer; they refused to forward electronic mail for reasons that struck me as specious as best. Establishing a location-independent personal communication system could solve the problem; however, I wonder who would be responsible for maintaining such a system, assigning addresses, etc. In any case, I'm not sure it's necessary. When I move my residence, I have many of the same problems with physical mail. The consequences of not forwarding my mail to my new residence can be catastrophic. The primary difference between that arena and the electronic one — at least in the U.S. — is that most physical mail can legally be transported only by a central postal authority. The postal authority currently allows me to instruct my old post office to forward all my mail to my new post office for a few months. Electronic mail "post offices" are typically the property of the owner of the machine; as demonstrated by Mr. Parnas's post, the owner really has no incentive to forward anyone's mail. Some do so as a courtesy; some flatly refuse. If the postal service were to stop forwarding mail (say, because it costs too much), the difference between these two situations would disappear. In the physical world, I have two ways to ensure that I don't lose mail when I move. Each method has its analog in the electronic arena. 1 - I can have my old post office forward the mail during the transition period. In the electronic world, this is analogous to having my old employer forward my mail, which they may or may not do. 2 - Rent a post office box (from the postal service or from a private mail service company) before I move, and notify those who send me mail to use the post office box address instead. In the electronic world, this is analogous to opening an account on a public access computer computer system like CompuServe or The Well and notifying people to use that address instead. In both worlds, #2 has a problem: I may forget to notify someone, and mail from that person will eventually be returned with an indication that the address is invalid. I'm not convinced that this problem is sufficiently serious to warrant restructuring the system. For the professional who needs a dedicated, reliable, permanent electronic mail feed, renting an electronic post office box can be viewed as a cost of doing business, much the way dues in professional societies are viewed. (I wonder what the IRS would do if I tried to write off a CompuServe account as a business expense?) As an aside, the electronic world also provides a third alternative: I can buy a machine, contract with a supplier for a network feed, and establish my own "post office". That's a little hard to do in the real world. The difficulties associated with changing one's address aren't new; changing the message medium doesn't change the problem. The risks that Mr. Parnas outlines don't seem to differ from risks we already accept when we deal with "real" mail. Brian Clapper, Rabbit Software Corporation, Malvern, PA email@example.com
[In response to Brint Cooper] 1) I do keep a mailing list and have notified all who are on it of my move. It is an obvious thing to do. However, I regularly get mail from people who are not on that list. 2) I personally feel no need for the kind of privacy that involves not having a personal net address. I would strongly oppose a requirement that every individual have such a personal address, but those who chose to have one should be able to have one. Dave
This article was taken from the new products section of the July/August issue of ISPNews. This company is apparently marketing a software product that incorporates a database of social security numbers!? "Veris is a computer program designed for the financial institutions that need to verify social security numbers as part of their business. The product will determine if a number is valid for the person using it. Along with a valid number, the product lists the state or territory where it was issued and the year(s) in which that set of number series were issued. In the event of an invalid number, warning and advisory messages are given. The product runs on Macintosh and IBM PC compatibles or networks." Glen Osterhout, Tegra-Varityper, Inc., Billerica, Massachusetts firstname.lastname@example.org
Somehow, I find a contradiction in the last couple Risks Digests. On one hand, we are told to protect our SSN, and that it is a BAD thing to use as a universal ID number. On the other hand, we have a message saying that we need a universal EMail addressing scheme. Why not combine the two and make your SSN the email address? Or if that isn't acceptable, how many 'universal' ids should we have? Jim Anderson, Saylors Software First, 6532 Edenvale Blvd, Eden Prairie, MN 55346 612-636-7451 email@example.com or firstname.lastname@example.org [Of course there is a contradiction. You cannot optimize for privacy and universal accessibility at the same time. If a unique ID is used to link databases universally, that is risky. If a unique ID were used only for identification, then that has some merit. It is the controls on potential use that present the problems, not the unique identifier itself. PGN]
Simple reason for less abuse of SSN's in Sweden? Less diversity and poverty? Be careful about generalizing across societies.
Perhaps it's worth discussing a bit of history here. One of the precursors of ASCII was a military character code called Fieldata. If I remember correctly this was an upper-case-only, and used 6 bits to represent all the printing characters. A seventh bit was part of the code (and there was a parity bit, so 8 bits were transmitted). At any rate a lot of the code combinations were deliberately left unassigned, so that designers of systems using Fieldata had plenty of codes available for control purposes, or for extra printable characters if they so desired. The committee that designed ASCII decided this was not such a good idea, as different systems used different characters for the same purpose, or the same character for different purposes. They therefore took pains to insure that in ASCII every code combination was used for something, leaving no room for expansion. (That's not precisely true; ASCII was standardized in two phases, first upper-case-only and later upper-lower; and the character that prints as dollar sign in the U.S. was designated "currency symbol" so it could print a sterling sign in the U.K., or other signs in other countries; and there were a few others designated for national characters.) When a character set is designed by a committee and ratified by majority vote, as was ASCII, there is naturally a certain amount of pushing and shoving to get various companies' favorite features in there. ASCII includes shift-out and shift-in characters, analogout to the figures and letters characters of Baudot, which could be used to shift to an alternate printable character set. It also includes escape, to mean that the following character(s) is not to be interpreted as ASCII. (There were some truly frightful proposals for getting back to ASCII after an escape, such as using a character with deliberate incorrect parity.) There are Cancel and Substitute; I've never heard anybody able to explain unequivocally exactly what they are supposed to mean. Not that it matters much. Once the computer people got hold of ASCII they made up their own interpretations. Delete, the all 1s character, was intended for erasing mistakes in paper tape. A character deleted this way should be simply ignored altogether; but the computer people gave it the entirely different interpretation of "discard the previous character." Backspace was meant to work exactly like backspace on a typewriter. With a hard copy terminal you could type o backspace / to get an o with a slant through it. But certain computer people decided to use backspace in the same way that others use delete; and few video terminals are able to do backspace and overstrike the way a hard copy terminal can. Control-C was meant to indicate the end of text in a message; but computer people widely use it to mean "interrupt the currently running program, or the program currently attached to the terminal." And so on, so in the end we have exactly what was had with Fieldata. email@example.com firstname.lastname@example.org
Research in computer software validation is not immune to the increasing trend by the US government to fund projects for merits that are political, not technical. Eliot Marshall reports (_Science_, 19 July 1991, p. 257) that a bill passed by the Senate Appropriations Committee on 11 July includes $10 million for a new software validation center at West Virginia University. It is not a coincidence that the committee is chaired by Robert Byrd (D-WV). Regardless of WVU's merits, the public would be at less risk if the government funded software R&D's best technical opportunities instead of succumbing to political opportunists. Paul Eggert <email@example.com> [Yes, this item is over a month old — I was finally trying to catch up with some of the backlog from my three-week absence. But it is still timely. NPR had a rather acerbic piece on 4Sep91 on some of Senator Byrd's successes in getting some substantial chunks of the USGovernment moved to West Virginia. PGN]
An article by Paul Stachour in the v12, n23 issue of RISKS DIGEST, contained several statements that I feel deserve comment. His recollection of the recognized need to filter out control sequences in inter-user messages is essentially correct, although the actual date may be a year or two later. The problem in question arose when Delta Data 4000 terminals capable of "smart answerback" were in use at the University of Southwestern Louisiana, and users were coding their login passwords into those answerbacks. Another issue, which was dealt with even later, was the concern that in a shared-terminal environment, a user could leave the terminal not with a logout, but by executing a malicious program that would issue what appeared to be a standard system logout, appear to respond correctly to a new user, and would record the new user's name and password on behalf of the hacker. (It could then claim the password type-in was in error, issue a logout-with-no-messages, and let the real operating system respond correctly to the user's next attempt to log in.) Paul's comments reflect the hindsight of the intervening years in two ways. First, his comments indicate that "Unix is supposedly an 'improved' derivative of Multics [sic]" is not correct. A tripartite design group consisting of General Electric, M.I.T., and Bell Labs designed the original Multics system; when it came time to start building Bell removed itself from participation in MULTICS, and developed UNIX as what it perceived a more cost-effective and achievable system. By then, Honeywell had acquired GE's large-scale computer division (and in a later acquisition of the rights to MULTICS, was required by M.I.T. to rename their operating system "Multics," for all you trivia fans) and continued with Multics for the next fifteen or so years. UNIX was indeed a derivative of MULTICS, but intended as a cut-down, quicker, less-elegant project better suited to Bell's needs. In later years, of course, UNIX was improved. Second, "The mechanism by which Multics sends its mail and messages ... was well-designed to ..." gives somewhat too much credit to the design. The original Multics mail scheme not only permitted inter-user messages and mail to contain control characters, but used a shared-stored method of holding the messages while they awaited delivery that let message forgeries be as simple as using a text editor. Literally: in the original scheme, you could use a text editor to take a message that was "in transit" and freely change the contents, including sender ID and all other header fields. Security was enhanced, later, to provide for mailboxes that required outer-level operating system intervention to place or retrieve messages. In that development, undertaken in part to satisfy Air Force requirements for a secure, multi-security-level computer utility, the resolution to the smart terminal/control codes problem became feasible and was implemented. (The problem of forgery of the operating system's login sequence turned out to be a great deal more difficult, as it was a much simpler hack.) Finally, the comment that "Multics source has always, to my knowledge, been publically available" requires comment. Paul's belief is not precisely correct, but it is true that Multics source has been available to users of the system and to the research community without major limitation. Within the Multics community, anything less than a complete willingness to hand critical code over to any hacker who asked for it was demeaningly referred to as "security through obscurity," and was avoided at all cost (generally, however, at NO cost, and often with distinct benefit). Edward_Rice@p4124.f716.n109.z1.fidonet.org [By the way, you can probably still get a Multics from Bull, if you hurry. PGN]
C A L L F O R P A P E R S THE IFIP/SEC'92 INTERNATIONAL CONFERENCE on COMPUTER SECURITY May 27-29, 1992 Singapore The purpose of the 1992 International Federation for Information Processing Security Conference [IFIP/Sec'92] is to provide a forum for the interchange of ideas, research results, and development activities and applications among academicians and practitioners in information, computer and systems sciences. IFIP/Sec'92 will consist of advance seminars, tutorials, open forums, distinguished keynote speakers, and the presentation of high-quality accepted papers. A high degree of interaction and discussion among Conference participants is expected, as a workshop-like setting is promoted. IFIP/Sec'92 is co-sponsored by The International Federation for Information Processing, Technical Committee 11 on Security and Protection in Information Processing Systems [IFIP/TC11] and The EDP Auditor's Association. IFIP/Sec'92 is organized by the Singapore Computer Society and IFIP/TC11 and is sponsored by the National Computer Board, Singapore, Singapore Federation of Computer Industry, Microcomputer Trade Association of Singapore and the EDP Auditors Association of Singapore Because IFIP/Sec'92 is a non-profit activity funded primarily by registration fees, all participants and speakers are expected to have their organizations bear the costs of their expenses and registration. Presenters of papers will pay a reduced conference fee. WHO SHOULD ATTEND The conference is intended for computer security researchers, managers, advisors, EDP auditors from government and industry, as well as other information technology professionals interested in computer security. CONFERENCE THEME The Eighth in a series of conferences devoted to advances in data, computer and communication security management, planning and control, this Conference will encompass developments in both theory and practice. Papers are invited in the areas shown and may be theoretical, conceptual, tutorial or descriptive in nature. Submitted papers will be refereed, and those presented at the Conference will be included in the proceedings. Submissions must not have been previously published and must be the original work of the author(s). The theme for IFIP/Sec'92 is "Computer Security and Control: From Small Systems to Large." Possible topics of submissions include, but are not restricted to: o Auditing the Small Systems Environment o Auditing Workstations o PC and Microcomputer Security o Security and Control of LANs and WANs o OSI Security and Management o GOSIP - Government OSI Protocol o Electronic Data Interchange Security o Management and Control of Cryptographic Systems o Security in High Performance Transaction Systems o Data Security in Developing Countries o Software Property Rights o Trans-border Data Flows o ITSEC (IT Security Evaluation Criteria - The Whitebook) o Database Security o Risk Assessment and Management o Legal Responses to Computer Crime/Privacy o Smart Cards for Information Systems Security o Biometric Systems for Access Control THE REFEREEING PROCESS All papers and panel proposals received by the submission deadline will be considered for presentation at the Conference. To ensure acceptance of high-quality papers, each paper submitted will be blind refereed. All papers presented at IFIP/Sec'92 will be included in the Conference proceedings, copies of which will be provided to Conference attendees. All papers presented, will also be included in proceedings to be published by Elsevier Science Publishers B.V. [North-Holland]. INSTRUCTIONS TO AUTHORS  Three (3) copies of the full paper, consisting of 22-26 double-spaced (approximately 5000 words), typewritten pages, including diagrams, must be received no later than 1 December 1991. Diskettes and electronically transmitted papers will not be accepted. Papers must be sent to the Program chairman.  Each paper must have a title page which includes the title of the paper, full name of all authors, and their complete addresses including affiliation(s), telephone number(s) and e-mail address(es). To facilitate the blind review process, these particulars should appear only on a separate title page.  The language of the Conference is English.  The first page of the manuscript should include the title and a 300 word abstract of the paper. IMPORTANT DATES o Full papers to be received by the Program Committee by 1 December 1991. o Notification of accepted papers will be mailed to the author on or before 1 March 1992. o Accepted manuscripts, in camera-ready form, are due no later than 15 April 1992. o Conference: 27-29 May 1992. WHOM TO CONTACT Questions or matters relating to the Conference Program should be directed to the Program chair: Mr. Guy G. Gable Department of Information Systems and Computer Science National University of Singapore Singapore 0511 Telephone: (65) 772-2864 Fax: (65) 777-1296 E-mail: ISCGUYGG@NUSVM For information on any aspect of the Conference other than Program, panel, or paper submissions, contact the Conference Chair: Mr. Wee Tew Lim Organising Chairman c/o Singapore Computer Society 71 Science Park Drive The NCB Building Singapore 0511 Telephone: (65) 778-3901 Fax: (65) 778-8221 Papers should be sent to: The Secretariat IFIP/Sec '92 c/o Singapore Computer Society 71 Science Park Drive The NCB Building Singapore 0511 In the States and Canada, inquiries about the Conference can be sent to: Dr. Harold Joseph Highland, FICS Chairman, IFIP/WG11.8 - Information Security Education and Training 562 Croydon Road Elmont, New York 11003-2814 USA Telephone: 516 488 6868 Telex: 650 406 5012 [MCIUW] Electronic mail: Highland@dockmaster.ncsc.mil X.400: C=US/A=MCI/S=Highland/D=ID=4065012 MCI Mail: 406 5012
Please report problems with the web pages to the maintainer