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…
In RISKS Digest 9.56, Roy Smith talks about delays waiting for computerized card catalogs (and that it was sometimes faster to use the old-fashioned approach). I find that one of the best advantages of electronic self-service is that it usually provides FASTER service than waiting for a human operator; A good example is bank ATM's. (I can usually park my car, go inside the bank, transact my business, and be back in the car and on my way before the FIRST car in the drive-thru line has left). Usually, the speed-up advantage for these cases is offset by a loss in convienience. Two examples: (1) Most Service Merchandise catalog showrooms in the area have one or more "Silent Sam" self-service ordering stations. These are (basically) dumb terminals which can collect your name and address, take orders, and will even tell you if a particular item is out of stock or that only the "display" item remains. (Amazingly, the inventory counts seem to be reasonably accurate!). However, the station does not print a reciept; the receipt gives you, at least, the "guaranteed" time that your order will be filled by. Without the reciept, you have no idea how long you'll be waiting, and if the order is delayed or forgotten, you have nothing with which to claim the "reward" usually offered for these cases. (2) Burger King is experimenting with a self-service ordering system called "Touch and Go": an ATM-like device with the complete Burger King menu on a large touchpad display. Posters and a nearby video player encourage customers to "avoid long lines" and use the "simple" Touch-and-Go system. The machine takes your order, takes your money, and gives you a change and your receipt; you then proceed to the "Touch and Go" area at the counter to pick up the food. (It even takes/gives pennies!!) When I first tried this at the Acton store, I was impressed at the smarts (if you order a "breakfast" item at dinnertime, for example, a voice and CRT display both tell you that "this restaurant is not serving breakfast at this time"). Then I tried to order a double cheeseburger with "ketchup only"; and found it impossible. I mentioned this to one of the employees while placing my MANUAL order, and was told that the software was going to be upgraded shortly to allow special orders. The machine was the only one of its kind and was being market-tested in the Acton, MA store. A few weeks go by, and sure enough, an extra option is added to let you customize individual items. So I order the double cheeseburger again, and press the "Have It Your Way" button. New options appear on the CRT: "Adjust Ketchup" and "Adjust Pickle". Both are set to "normal", so I touch "Adjust Pickle" and set "Pickle" to "None". Great, an electronically-ordered "ketchup only" double cheeseburger at last! What do I actually get? A double cheeseburger with ketchup and mustard. Seems that mustard is normal on a double cheeseburger, and Touch-and-Go offers no way to turn it off. I bring the burger up to the counter where they acknowledge this, and replace the cheeseburger for free. "I'm glad you brought it back," the salesperson tells me. "This has been happening a lot. The machine goes on the road next week; we'll be glad to be rid of it." --- Russ McFatter [russ@alliant.Alliant.COM] "Have It Your Way" and "Touch-and-Go" are (undoubtedly) trademarks of Burger King Corporation, for what it's worth. Std. disclaimer applies.
This somewhat cryptic paragraph is from "Romanians Talk of Life Then and Now"
by Russell W. Baker, in the Christian Science Monitor, December 27th, 1989:
Dragos Vaida, an associate professor of mathematics at the University
of Bucharest, told how he had published a book on computer science,
but was obligated to change the title because it referred to
programming languages. Elena Ceausescu, who was in charge of
technology, was against computer science, he said, because it gave the
people technical knowledge that could be used against the dictatorship.
What I'm curious about is what the new unoffensive title could have been. If
Elena was upset about computer science in general, why wasn't the book simply
banned? Or was she upset that people might learn about "programming
languages", which to her might sound like mind control? Strange story.
Eric Haines - wrath.cs.cornell.edu!eye!erich
The last paragraph suggests the RISKS were the same 700 years ago. [From The Times (London) Saturday, December 23, 1989 by Simon Tait, Arts Correspondent] A seal, which would have been the equivalent of cheque card, passport and credit card rolled into one for the person who lost it more than 700 years ago, has been found by archaeologists working in Oxford. Mr. David Dawson, of the Oxfordshire County Museum, Woodstock, where the seal will go on display, said: "This was a personal seal which would have been carried round everywhere by the owner. He would have been lost without it, and it is a rare thing to find because it would normally have been destroyed on his death." What makes the small, corroded and fragile 13th-century seal unique is that it was found in premises known, through records in the Bodleian Library, to belong to the seal's owner. It bears the legend `S' ROGERUM COMENORE CLICI, indicating that the seal (sigillum) belonged to Roger of Cumnor, clerk or priest, who worker as a lawyer. The site is on the corner of Hollybush Row in Oxford, on which Halls Brewery stood most recently, which is being developed by Grosvenor Square Property Developers. Roger who gave two buildings on it to Oseney Abbey in 1265, during the reign of Henry III, according to the Bodleian Library. The seal was found in a ditch between the two buildings. Mr. Brian Durham, a member of the Oxford Archaeological Unit which made the discovery during excavations last week, said: "The new find could be a forgery but the more likely explanation is that it is his early seal, which he lost when he was actually living in the house. You can picture him hunting unsuccessfully for it." "Since he worked, in effect, as a solicitor, he would have had to alert everyone to the fact that the seal could have been stolen and used for forgeries. Then he would have had to have a different seal made."
Commercial email to fax gateways are beginning to hit the market. I've been faxing email for people for many months, and one problem which recurs is people supplying me with incorrect fax numbers. I usually try a voice call first, to ensure that the destination phone number is indeed answered by a fax machine. Occasionally it is not, and I am forced to confuse the innocent person who answers. Often, the person can supply me with the correct fax number. This problem is compounded with fully automated computerfax systems. Some computerfax hardware is able to detect voice on the line, and hence "do the right thing": don't call again, and return an error. Some computerfax systems do not properly detect voice, and they might redial the phone number N times before returning an error. One solution might be to use computerfax hardware that has the capability to play digitized voice and ask the recipient to press touch tones to indicate his annoyance level! Most computerfax hardware does not have this capability, unfortunately. A risk is that blue network meanies would purposely ask for a fax to be delivered to a non-fax number, in order to cause an "annoyance". Annoyance calls are illegal. I wonder whether the computerfax machine owner is liable for such calls, or whether the sender is responsible? (comp.dcom.telecom cats can probably answer this question.) We've seen the uproar in Washington about junk faxes... Computerfax opens the door for an email user to cause junk fax, intentionally or unintentionally. Steve Elias 508 671 7556
I just happened to be rereading the above cited paper (CACM, 22 11, Nov 1979, pp. 594-7), and stumbled upon Bob Morris' tale about discovering the password file spewing out instead of the message of the day file on each new login, because two people were editing the two files in the same directory and the editor used the same temporary file names for both of them (MIT's CTSS, early 1960s). Yes, it really happened. But since this case is often cited as a piece of apocrypha, I thought it might be worth mentioning here, particularly for the younger folks for whom 1979 (not to mention the early 1960s) is prehistory. [That is the paper that describes preencryptive attacks on the encrypted password file.]
The following appeared in yesterday's (1/2/90) Wall Street Journal in a summary of some of the more absurd events of the past year. The sad part of it is that too many people might take the story as literal truth...while others ignore questions of security as unnecessary makework. WHAT REALLY HAPPENED OCT. 13: Arthur Cashin, a Paine Webber trader at the New York Stock Exchange, writes a daily market letter with a touch of the wacky. The Monday after the Friday-the-13th plunge, when traders were still wondering if the market would crash again, Mr. Cashin explained what really happened Friday: "At about 2:25 (EDT) a nine-year-old named Lance, sitting hunched over his Nintendo machine in Hohokus, N. J., opened the wrong door in a game of "Mario Brothers." Once the door was open the computer virus escaped and immediately began calling in sell orders to the New York Stock Exchange's DOT system. The virus was programmed to enter the orders in alphabetical order based on industry, so it began with airlines and ended with the zoysia grass distributers (which were least affected by the sell-off)." "Is that what happened? Well, no! But that is what you will probably hear from a variety of academics and self-appointed experts as regulators review Friday's events."
During the Fall 1989 semester, I taught a computer security class at a
local college. Most of the students were junior or senior CS majors.
One of the questions on the final exam was "Describe one advantage that
passwords have over biometric devices (e.g., retinal scanners, fingerprint
readers) as an authentication mechanism."
I was expecting answers along the lines of 'passwords are more acceptable
to users in most cases than sticking their eyes up to a slot', since I had
spent a lot of time covering Saltzer and Schroeder's eight design principles,
one of which is 'psychological acceptability' of mechanisms to users. (Other
acceptable answers existed - e.g., with biometrics, one must deal with both
false positives and false negatives - there's a chance the real person will
be rejected.)
One student's answer: "Passwords have the advantage that it's easier to let
my friend use my account. If the system uses biometric devices for user
authentication, I have to be there when he logs in, to get him on to the
system. But, if the system uses passwords, I can just tell him my password,
and don't have to be there - he can login at his leisure."
So much for that one-week unit on 'Individual Accountability'.
Al Arsenault
In RISKS 9.55 it was reported that a local radio news broadcast said that RAND
had been hit with the AIDS virus [sic]. This is not correct. We have not seen
the "AIDS Information Disk" here. There was a flurry of activity from the
press when AP reported that we had warned our researchers to be on the lookout
for the Disk in their incoming mail (true). I talked to several TV stations,
passing on the information that it's not infectious (i.e. isn't a virus), and
that it underlines the fact that everybody should make frequent backups and be
careful what they stick into their computers.
Jim Gillogly
[Also noted by Jim Guyton, guyton@rand.org]
CALL FOR PAPERS:
13th NATIONAL COMPUTER SECURITY CONFERENCE
Sponsored by the National Computer Security Center and
the National Institute of Standards and Technology
Theme: Information Systems Security: Standards - The Key to the Future
Date: OCTOBER 1-4, 1990
Location: WASHINGTON, D.C.
This conference provides a forum for the Government and the private sector to
share current information that is useful and of general interest to the
conference participants on technologies, present and future, that are designed
to meet the ever-growing challenge of telecommunications and automated
information systems security. The conference will offer multiple tracks for
the needs of users, vendors, and the research and development communities. The
focus of the conference will be on: Systems Application Guidance, Awareness,
Training, and Education, Ethics and Issues, Evaluation and Certification,
Innovations and New Products, Management and Administration, and Disaster
Prevention and Recovery. We encourage submission of papers on the following
topics of high interest:
Systems Application Guidance
- Access Control Strategies
- Achieving Network Security
- Building on Trusted Computing Bases
- Integrating INFOSEC into Systems
- Preparing Security Plans
- Secure Architectures
- Securing Heterogeneous Networks
- Small Systems Security
Innovations and New Products
- Approved/Endorsed Products
- Audit Reduction Tools and Techniques
- Biometric Authentication
- Data Base Security
- Personal Identification and Authentication
- Smart Card Applications
- Tools and Technology
Awareness, Training and Education
- Building Security Awareness
- Compusec Training: Curricula, Effectiveness, Media
- Curriculum for Differing Levels of Users
- Keeping Security In Step With Technology
- Policies, Standards, and Guidelines
- Understanding the Threat
Evaluation and Certification
- Assurance and Analytic Techniques
- Conducting Security Evaluations
- Covert Channel Analysis
- Experiences in Applying Verification
- Formal Policy Models
- Techniques
Management and Administration
- Accrediting Information Systems and Networks
- Defining and Specifying Computer Security Requirements
- Life Cycle Management
- Managing Risk
- Role of Standards
- Security Requirements
Disaster Prevention and Recovery
- Assurance of Service
- Computer Viruses
- Contingency Planning
- Disaster Recovery
- Malicious Code
- Survivability
Ethics and Issues
- Computer Abuse/Misuse
- Ethics in the Workplace
- Individual Rights
- Laws
- Relationship of Ethics to Technology
- Standards of Ethics in Information Technology
BY FEBRUARY 16, 1990: Send eight copies of your draft paper* or panel
suggestions to one of the following addresses. Include the topical category
of your submission, author name(s), address, and telephone number on the cover
sheet only.
1. FOR PAPERS SENT VIA National Computer Security Conference
U.S. or Foreign ATTN: NCS Conference Secretary
Government MAIL National Computer Security Center
ONLY: Fort George G. Meade, MD 20755-6000
2. FOR PAPERS SENT VIA National Computer Security Conference
COMMERCIAL COURIER c/o NCS Conference Secretary
SERVICES (e.g.-FEDERAL National Computer Security Center
EXPRESS, EMERY, UPS, 911 Elkridge Landing Road
etc.): Linthicum, MD 21090
3. FOR Electronic Mail: NCS_Conference@DOCKMASTER.NCSC.MIL (1 copy)
BY MAY 4, 1990: Speakers selected to participate in the conference will be
notified.
BY JUNE 22, 1990: Final, camera-ready papers are due.
* Government employees or those under Government sponsorship must so identify
their papers.
For additional information on submissions, please call (301) 850-0272.
To assist the Technical Review Committee, the following is required for
all submissions:
Page 1: Title of paper or submission
Topical Category & keywords
Author(s)
Organization(s)
Phone number(s)
Net address(es), if available
Point of Contact
Additionally, submissions sponsored by the U.S. Government must provide
the following information:
U.S. Government Program Sponsor or Procuring Element
Contract number (if applicable)
U.S. Government Publication Release Authority
(Note: Responsibility for U.S. Government
pre-publication review lies with the author(s).)
Page 2: Title of the paper or submission
-last abstract
The paper (Suggested length: 6 pages, double columns)
A Technical Review Committee, composed of U.S. Government and Industry
Computer Security experts, will referee submissions only for technical merit
for publication and presentation at the National Computer Security (NCS)
Conference. No classified submissions will be accepted for review.
Papers drafted as part of the author's official U.S. Government duties
may not be subject to copyright. Papers submitted that are subject to
copyright must be accompanied by a written assignment to the NCS Conference
Committee or written authorization to publish and release the paper at the
Committee's discretion. Papers selected for presentation at the NCS
Conference requiring U.S. Government pre-publication review must include,
with the submission of the final paper no later than June 22, 1990 to the
committee, a written release from the U.S. Government Department or Agency
responsible for pre-publication review. Failure to comply may result in
rescinding selection for publication and for presentation at the 13th NCS
Conference.
Technical questions can be addressed to the NCS Conference Committee
through the following means:
Phone: (301) 850-0CSC [0272]
Electronic Mail: NCS_Conference@DOCKMASTER.NCSC.MIL
Government Mail: National Computer Security Conference
National Computer Security Center
Fort George G. Meade, MD 20755-6000
Commercial Carriers: National Computer Security Conference
c/o NCS Conference Secretary
National Computer Security Center
911 Elkridge Landing Road
Linthicum, MD 21090
Please report problems with the web pages to the maintainer