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…
As various electronic services are brought by phone lines or cables directly to the home, there will be an increasing need for folks to deal with passwords. And concomitantly there will be ever more lists of passwords for the nefarious to try to crack. RISKS readers may be interested in the following stories about passwords for two electronic services that recently arrived over the wires at my house. From the aspect of security, one story is good and the other bad. 1. Voice Mail. The local Bell company is offering electronic voice mail from the central switch to residential customers. Many advantages over an answering machine. Not only are both capacity and reliability better than for tape machine but there are also some nice features that an answering machine could not have such as answer when busy and a differential ring that lets the caller know he or she is being switched to voice mail with enough warning that he or she can hang up to avoid toll charges. The good story: on first use the system requires you to enter a password (min 4 digits, max 8 digits) of your own choosing. In contrast, my old answering machine had a 1 digit security [sic] code. The password is also easily changed. I wish my multiple ATM cards would let me choose my own passwords so that maybe I could remember some of them. 2. PRODIGY. IBM and Sears have teamed to offer a modem-accessible information and shopping service. I think we are a test market but maybe lots of you have this available. Slick, but slow, graphics, available in either IBM-PC or Mac versions, offer information on sports, weather, etc. and, depending on locale, home banking, grocery shopping, and catalog shopping from places ranging from Sears and Penneys to REI. One particulary nice feature is access to American Airlines' Sabre reservations system through a front-end that although is sometimes tedious is much easier to use than a terminal in a travel agency. This week I received a promotional letter from AA proffering goodies if I booked my own flights and paid for them with a credit card through Sabre. And just in case I had forgotten my password (which they told me never to write down) they had *printed* it at the top of the promotional letter! That clearly means they don't encrypt the passwords they collected from all of us (oh, they also have our credit card numbers and frequent flyer numbers for faster ticket ordering). I wonder how many AA people have access to the password list? Certainly everyone in the mail room! But if someone uses my password and credit card number to order tickets, will I at least get credited for the frequent flyer miles for the flights they steal? Gary McClelland, Univ of Colorado BITNET: mcclella@colorado
From a conversation overheard a few days ago at the Duke University student
center — yes, this is real; I'm not clever enough to make up something like
this — a new version of the "my dog ate the homework" excuse for not getting a
project done:
"I told the professor that with the medication I was taking
it wasn't advisable for me to drive a car, operate heavy
machinery, OR FORMAT FLOPPY DISKS."
My opinions are my own and probably not IBM-compatible.--ehr
Ernest H. Robl (ehr@ecsvax) (919) 684-6269 w; (919) 286-3845 h
Systems Specialist (Tandem System Manager), Library Systems,
027 Perkins Library, Duke University, Durham, NC 27706 U.S.A.
In risks 9.37 Sukumar Rathnam writes
The last thing you expect is a temperature sensitive
behavior for programs.
Actually, I've seen it many times and it is now one of the first things I
expect. And it's easy to test--just turn down the thermostat.
Donald Arseneau
Etak manufactures a device for
keeping track of car movements: a map is displayed on a video screen and
updated frequently as the car moves, showing the driver where he is and
giving him the ability to get information about approaching features.
Nicholas Negroponte of the MIT Media Lab used this very application as an
example of the need for speech interfaces to computers. In his opinion, it's a
terrible idea to have a separate map screen that requires the driver to take
his eyes off the road. It's much better for the map to talk to him: "Turn left
at Elm Street, 1/4 mile ahead." Even a heads-up display isn't good enough --
don't overload one channel of communication, use two channels that don't
overlap.
Paul Fuqua, Texas Instruments Computer Science Center
pf@csc.ti.com {smu,texsun,cs.utexas.edu,rice}!ti-csl!pf
This week's Economist (28 oct - 3 nov issue) has a leader article on computer crime (p18), saying that the rush to define new laws on computer crime is leading to inappropriate suggestions for punishment They say the `real menaces' are not mysterious or new, but `old-fashioned trespass, vandalism and theft', and that laws against the former two are hard to apply because ` the "space" and "property" inside a computer are intangible'. They point out two nonsenses that have been created by the proposal of Britain's Law Commission, note that extra-territoriality is a special problem posed by computer crime, and suggest (platitudinously) that the basic issue of how to protect (rather than how to punish) needs to be addressed further. In the usual Economist style, it is well-written and coherent, apart from the conclusion, which is hardly that. I don't have a scanner, and am unwilling to type it all in. Copies should hit the bookstores wednesday.
I'm a newcomer to risks (not the net) but I've followed the discussion of slow computer vs. fast manual systems. This is a subject which I've some familiarity with, and right now I'm just finishing the installation of a very high-volume POS (point of sale) system implemented on (can you believe it?) a network of Macintoshes, with receipt printers, cash drawers, and bar-code scanners. I have done other systems before which demanded speed, but this job was the most interesting and difficult I have faced. From it I have learned a number of things about the speed that can be achieved with computer systems in the face of real-world problems. Problem #1: Careless and unintelligent employees. Many employees, especially in the kinds of positions that wind up being automated (cashiers, tellers, etc.) are somewhat less than brilliant. If they were smarter they'd be rocket scientists, right? :-) There are many who are not dumb, and they can be worse, because boredom can make them incredibly careless. Solution: Management has to be involved in maintaining a decent workplace, but there are still many things you can do to keep new technology from adding to the trouble (which would exist no matter what). I followed the "spirit" of the Mac interface, which really just means being aware of human factors- I could not use a mouse *at all*, so goodbye menus and icons. In general, _everything_ has to be 100% bulletproofed and idiotproofed. These are not the same thing at all- one protects against illegal values completely, while the other warns against (but usually doesn't forbid) stupid values. Example: After a couple of days, employees become aware of the general flow of events in the program, so they stopped looking at the messages for them on the screen- in fact they often didn't look at all. They were often unaware of conditions that required immediate action (bad price entered, for example). One solution to this particular problem was to create three distinct sounds that notified users of acknowledgement, notification, and error conditions. Problem #2: Forgotten Features (and other training issues) If the system can do so much, how come it's used for so little? Because nobody remembers how to do this, that, and the other thing. So they all do _this_ instead of _that_ and simply keep paper notes, or figure out some other way to do less work and screw up the system. Don't fight it, because you'll lose. Solution: Make sure everything is accessible. Write software that requires a minimum of training. You want specifics? Start with the Apple Human Interface Guidelines, and then there's _lots_ of other literature. But to begin with, don't hide features, don't use cryptic codes when simple english will do, and don't expect your users to know what they're doing- literally. Either tell them where they are at all times (unobtrusively, of course) or failing that, allow them to back out gracefully. *** BE CONSISTENT *** and don't expect users to be the same. Example: My POS system replaces standard cash registers. It does much much more and yet takes one-quarter the time to learn. And the features aren't forgotten. One Mac-ish thing it does is use title bars on all of the windows which aren't instant-response windows (modal dialogs). The title bars say who is logged in and what they're doing at all times. Problem #3: Slow and/or increased data entry Many computer systems require the tracking of much more information than the old manual systems. This can create the illusion of lethargic system speed even if the hardware is quite fast. Users can be frustrated by the extra load, which may well feel like makework to them. The speed of entry itself may be slow if data is validated on-the-fly as it's entered. Solution: First, tune the software. You can acheive remarkable things by using (or, unhappily more often, faking) multi-threading — do the validation, but _don't_ stop data entry while you're validating. Overlap various hard delays- print while you're writing to disk, or calculate while verifying a credit number with a remote machine. After all this helps, but isn't good enough, start buying hardware. This may well be the best part of the system to invest in. Special data-entry hardware can make a _huge_ difference. Example: After tuning the POS software, there was still an inevitable slowdown since the cashiers were entering price and item information instead of just the price (as on the old registers). This was costing up to fifteen seconds _per item_, which was completely intolerable. The solution was to buy bar-code scanners, which could enter both item # and price (both of which are typically on the item to begin with). This dramatically improves the performance of the item-entry process. Problem #4: Lazy programming. Yes, I am as lazy as the next guy. Often, I'd like the real world to fit a neat conceptual model I have developed for it. When a case comes up that I can't handle, I'd rather contort it to fit my code rather than the other way around. Sometimes this is feasible, and once in a while, it can lead to marked improvements- but if so, it just identifies an improvement that should have been realized earlier in the design process. Most of the time, shoehorning real procedures into flowcharts is a recipe for disaster. Solution: In that case, recode. It's as simple and as painful as that. Sometimes you'll wind up with pages and pages of code to deal with a handful of exceptions that won't come up but once a year. Tough luck- that's what being a good programmer is all about. Example: I designed the POS system so that every item sold would already be in the database. I went to great lengths to insure this, since it would make life much easier for both myself and all of the users. Unfortunately this can't always work- at times items may be checked in with faulty item codes, for example. Modifying the system to deal with unexpected item codes was one of the most annoying and inelegant things I have ever had to do, but now it works, and people no longer complain about having to work around a system which is supposed to make their work easier, not harder. There is more, but I think that this is more than enough for my first risks posting. The point of this is that the system I built is not only more capable and useful than the old, but is considerably more efficient up front, as well. I think that this achievement could easily be duplicated elsewheres if programmers were more aware of the real-life processes they are trying to model, and the real-life problems their systems will have to deal with. Alexis Rosen, President, Arete Corp. (Hat #1) Sysadmin/Owner, PANIX public access Unix (Hat #2) cmcl2!panix!alexis -or- alexis@panix.uucp
Please report problems with the web pages to the maintainer